[NITPICKER] Porting X.org 1.1.1 to use NitPicker
nf2 at inf.tu-dresden.de
Mon May 14 21:50:40 CEST 2007
> 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
> 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
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
> 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.
More information about the l4-hackers