[Question]How you create a xorg server inside a chrome desktop

[buddhi-deep]

Hi,I'm making a new project which has the same goal of yours,but i don't understand how you guys create a xorg server inside a chrome desktop then let xclients inside the chroot container connect to it.

[supechicken]

Correct me if I am wrong :)

Assuming that the user is now starting an X desktop (for example, xfce4) by running startxfce4 in the Chrome OS shell. The startxfce4 command is actually a script that calls enter-chroot and executes the real startxfce4 in the chroot. Now the real startxfce4 command (in the chroot) calls the xinit command, attempting to start an X server, the xinit wrapper script located at /usr/local/bin/xinit will be called instead (as the priority of /usr/local/bin/xinit is higher than /usr/bin/xinit, which is the real xinit binary locates)

After that, some wrapper scripts in /usr/local/bin were called respectively, finally the real xinit command was called. However, xinit will not call Xorg directly. Instead, it will execute the /etc/X11/xinit/xserverrc script. This script called /etc/crouton/xserverrc-${XMETHOD} then (based on the X method specified, xserverrc-xorg in this case). In xserverrc-xorg, a variable called LD_PRELOAD is set with value /usr/local/lib/croutonfreon.so (the croutonfreon.so file is the key for starting an X server alongside the Chrome OS UI). Then the Xorg command will be called.

So what does croutonfreon.so do? It is a shared library compiled from freon.c (source). It tells the Chrome OS UI to release the display by sending a D-bus command to org.chromium.DisplayService so that the X server can use the display later. Also, it prevents the X server to access the /dev/tty0 device by redirecting to /dev/null, as these devices do not exist in Chrome OS. (Chrome OS don't use TTYs)

An X server should be started now, with croutonfreon.so loaded. (any libraries specified in LD_PRELOAD will be loaded before the command run)

[dnschneid]

Fantastic summary of the xorg approach.

For xiwi (X in a window), we do even worse hacks. Everything's the same until xserverrc-${XMETHOD}, at which point the xiwi version is run. It launches an X.org server with a dummy framebuffer backend (with some code patches to enable dynamic resizing). The croutonxinitrc-wrapper, which runs once the X.org server has launched, in turn launches both a websockets server (croutonwebsocket) and croutonfbserver for this X.org instance.

Crouton extension eventually connects to the websocket server (it polls for connection every few seconds). The crouton extension uses pnacl to create a canvas. It writes a nonce to the start of the canvas, which is actually backed by a shared memory region accessible via /proc on the filesystem. It hands this nonce off to croutonfbserver, which uses it to figure out which shared memory file contains the canvas framebuffer. It has to repeat this whenever the framebuffer gets reallocated, which is usually just when you resize or hide the window.

When the X server updates the framebuffer, croutonfbserver copies the framebuffer contents over to the shared memory region, then uses the websocket server to poke the extension to trigger a redraw of the window.

Cycling is achieved by a lot of hacks involving server root window properties, scripting, dbus messages, and so on...it runs pretty deep.

Basically, crouton is hacks on hacks on hacks and it's amazing it works as well as it does, as long as it has.

[DennisLfromGA]

@happyeggchen,

We got close to having a sommelier target with a wayland display, you might find the pull request interesting:

• Add a new target sommelier (changed from somm) #4410

-DennisLfromGA