Hi everybody,
We are working on L4, currently especially on the graphical aspect. As we love NitPicker (NitPicker is cool ;)), we want to use it to run L4Linux on top on it.
So we have started with a Linux installation (Gentoo Linux), after what we have installed Fiasco, L4Env and L4Linux (2.6.20, next 2.6.21, on top on our recently installed Gentoo, reusing its filesystem). To test our installation, we first use L4Con, but the mouse moves were extremely slow; so next we use DOpE, and it was cool, all worked (network and hard disk via L4Linux, not Ore... Oh is there exist a multiplexer, as Ore, for hard disk ?). But of course, the desktop-in-window aproach does not fully satisfied us, we want a fullscreen aproach so we start investigating on NitPicker.
The problem is that all tutorials related to NitPicker + X.org are based on a quite-old version of X.org, before the X.org team adopted the modular approach. So we decide to port the last X.org (1.1.1) to use NitPicker, following instructions found at http://os.inf.tu-dresden.de/pipermail/l4-hackers/2007/002774.html http://os.inf.tu-dresden.de/pipermail/l4-hackers/2007/002774.html
First we compiled the nitpicker-client ovlwm server, nitovlwm. Then we install into the L4Linux the lxevent program, started after Linux kernel boot, with creation of /dev/lxevent, and the ovltrack program, started via .xinitrc. We had to change a little the Makefile of ovltrack by adding the -Bdynamic option in LIBS. We compiled and generated lxevent_drv.o (X.org mouse driver in xorg.conf). The last step was generating the X.org screen driver, ovlscreen_drv.o. The changes toward previous versions occurs at this step, as now X.org is modular and consists in several small packages. But after resolving a lot of include path problems, importing the needed X.org package to compile the driver, we got the driver ovlscreen_drv.o compiled and copy it into the L4Linux filesystem, modifying xorg.conf to use this driver. Also we use NitDope, so L4fb driver in L4Linux that creates /dev/fb0.
Then we boot our L4-based system, NitPicker, NitDOpE and L4Linux, all start, all was right. The problems come when starting X.org. Indeed, X.org started, the window manager also (WindowMaker), in fact all works... excepts refresh ! Indeed when moving the mouse on a L4Linux window, the window content is not refreshed, resulting in an unusable window. But clicking outside the window forces the refresh.
We know that with DOpE, the refresh is automatic, periodic and so it was working for us. But with NitPicker, we know that the refresh only occurs if a change is made in the client. What we don't know is how this refresh is done, who is responsible for it (ovlscreen, ovltrack, nitovlwm ?), and which are the impacts of using a modular X.org in this process....
Is someone can give us some tips on how to make the refresh to occur ? Or details about event forwarding ? Is there other changes to be made that we missed ?
Any help will be grateful appreciated. Thanks.
Hi Nicolas,
We are working on L4, currently especially on the graphical aspect. As we love NitPicker (NitPicker is cool ;)), we want to use it to run L4Linux on top on it.
Great to hear that you are giving Nitpicker a try!
So we have started with a Linux installation (Gentoo Linux), after what we have installed Fiasco, L4Env and L4Linux (2.6.20, next 2.6.21, on top on our recently installed Gentoo, reusing its filesystem). To test our installation, we first use L4Con, but the mouse moves were extremely slow; so next we use DOpE, and it was cool, all worked (network and hard disk via L4Linux, not Ore... Oh is there exist a multiplexer, as Ore, for hard disk ?). But of course, the desktop-in-window aproach does not fully satisfied us, we want a fullscreen aproach so we start investigating on NitPicker.
The problem is that all tutorials related to NitPicker + X.org are based on a quite-old version of X.org, before the X.org team adopted the modular approach. So we decide to port the last X.org (1.1.1) to use NitPicker, following instructions found at http://os.inf.tu-dresden.de/pipermail/l4-hackers/2007/002774.html
First we compiled the nitpicker-client ovlwm server, nitovlwm. Then we install into the L4Linux the lxevent program, started after Linux kernel boot, with creation of /dev/lxevent, and the ovltrack program, started via .xinitrc. We had to change a little the Makefile of ovltrack by adding the -Bdynamic option in LIBS. We compiled and generated lxevent_drv.o (X.org mouse driver in xorg.conf). The last step was generating the X.org screen driver, ovlscreen_drv.o. The changes toward previous versions occurs at this step, as now X.org is modular and consists in several small packages. But after resolving a lot of include path problems, importing the needed X.org package to compile the driver, we got the driver ovlscreen_drv.o compiled and copy it into the L4Linux filesystem, modifying xorg.conf to use this driver. Also we use NitDope, so L4fb driver in L4Linux that creates /dev/fb0.
Then we boot our L4-based system, NitPicker, NitDOpE and L4Linux, all start, all was right. The problems come when starting X.org. Indeed, X.org started, the window manager also (WindowMaker), in fact all works... excepts refresh ! Indeed when moving the mouse on a L4Linux window, the window content is not refreshed, resulting in an unusable window. But clicking outside the window forces the refresh.
We know that with DOpE, the refresh is automatic, periodic and so it was working for us. But with NitPicker, we know that the refresh only occurs if a change is made in the client. What we don't know is how this refresh is done, who is responsible for it (ovlscreen, ovltrack, nitovlwm ?), and which are the impacts of using a modular X.org in this process....
The refresh mechanism is controlled by the ovlscreen_drv driver that uses the shadow-fb module of X.org. The ovlscreen driver passes a buffer to the X-Server to which the X-Server performs all drawing operations. This buffer is shared with Nitpicker. After each completed redraw onto this buffer, the X Server calls a callback function ('update_screenarea' in ovlscreen.c) and passes a list of rectangles describing the screen regions to update. For each such screen region, ovlscreen makes an IPC call of
refresh_screen([in] int x, [in] int y, [in] int w, [in] int h);
to NitOvlWM (defined in overlay_wm/idl/overlay.idl), which essentially forward this information to Nitpicker via another IPC.
For finding the reason for your problem, you might do some of the following steps:
* Check the output of OvlScreen in the X.org log file /var/log/Xorg.0.log and see if the messages indicate any anomaly. If you are uncertain, feel free to send me your log via email and I take a look.
* Check if the shadow-fb mechanism is working by instrumenting the 'update_screenarea' with a bit of log output and observing the result in the Xorg log.
* Check if the IPC from ovlscreen_drv to nitovlwm got properly delivered by instrumenting the function 'overlay_refresh_screen_component' of the file nitpicker/examples/nitovlwm/l4/main.c
Or details about event forwarding ? Is there other changes to be made that we missed ?
As far as I can see, you did everything correctly.
Regards, Norman
Hi Nicolas,
I managed to reproduce your issue with the non-working refresh of the X11 windows with Xorg of the latest Debian unstable. The problem was an API change of the shadowfb Module of Xorg from version 7.0 to the current version. I updated the drivers ovlscreen_drv.so and lxevent_drv.so in:
overlay_wm/examples/xf86screen/ and overlay_wm/examples/xf86input/
Frank Mehnert's up-to-date PSLIM driver in 'l4con/examples/xf86_stub' was a very good reference for finding the problem. The updated drivers should be available at our public SVN repository soon.
For your convenience, I have also compiled a bootable ISO image based on the latest Fiasco version (from SVN head), the latest L4env components and Nitpicker, L4Linux 2.6.21-l4, and a Linux RAM disk generated from yesterday's Debian unstable (e.g., X.Org version 1.3.0):
http://os.inf.tu-dresden.de/~nf2/tmp/l4lx26-nitpicker-xorg71.iso.gz
You can try out the image using Qemu:
qemu -m 256 -serial stdio -cdrom l4lx26-nitpicker-xorg71.iso
This provides you with working and current binaries to start with. Note that the image is quickly put together and I have not tested everything in detail - but the X11 refresh works.
So we have started with a Linux installation (Gentoo Linux), after what we have installed Fiasco, L4Env and L4Linux (2.6.20, next 2.6.21, on top on our recently installed Gentoo, reusing its filesystem). To test our installation, we first use L4Con, but the mouse moves were extremely slow; so next we use DOpE, and it was cool, all worked (network and hard disk via L4Linux, not Ore... Oh is there exist a multiplexer, as Ore, for hard disk ?). But of course, the desktop-in-window aproach does
To my knowledge, there is no hard-disk multiplexer available.
not fully satisfied us, we want a fullscreen aproach so we start investigating on NitPicker.
The problem is that all tutorials related to NitPicker + X.org are based on a quite-old version of X.org, before the X.org team adopted the modular approach. So we decide to port the last X.org (1.1.1) to use NitPicker, following instructions found at http://os.inf.tu-dresden.de/pipermail/l4-hackers/2007/002774.html
First we compiled the nitpicker-client ovlwm server, nitovlwm. Then we install into the L4Linux the lxevent program, started after Linux kernel boot, with creation of /dev/lxevent, and the ovltrack program, started via .xinitrc. We had to change a little the Makefile of ovltrack by adding the -Bdynamic option in LIBS. We compiled and generated lxevent_drv.o (X.org mouse driver in xorg.conf). The last step was generating the X.org screen driver, ovlscreen_drv.o. The changes toward previous versions occurs at this step, as now X.org is modular and consists in several small packages. But after resolving a lot of include path problems, importing the needed X.org package to compile the driver, we got the driver ovlscreen_drv.o compiled and copy it into the L4Linux filesystem, modifying xorg.conf to use this driver. Also we use NitDope, so L4fb driver in L4Linux that creates /dev/fb0.
I am amazed of how far you went on your own without even asking one question. Respect! :-) Good luck with the updated drivers.
Best regards Norman
l4-hackers@os.inf.tu-dresden.de