Wednesday, December 10, 2008

Two X servers and a microphone

Oh, ok, so getting X.org running under Wayland was easier than expected. Or I guess, it was as easy as expected, which is usually never the case.

What's running here are two X.org servers, side by side under Wayland. It's not Xnest or Xephyr, it's the full X server with DRI2, GLX, Xv and UXA acceleration. The only difference is that the server passes its front buffer handle to Wayland instead of passing it to kernel modesetting and it receives input events from Wayland instead of evdev. And Whenever the Intel DDX driver flushes its batchbuffer it now also sends a damage event to Wayland.

There's some weird transparency going on, and the reason is that the X servers window pixmap doesn't have a well-defined alpha channel. Which doesn't matter when the hardware is scanning it out to a display, but in this setup it causes some unintended transparency.

The Wayland server transforms the input events to the surface coordinate system of the client surfaces, which means that the X servers are fully functional, and you can click the icons and move the tiny windows around. It's all very cute. Keyboard input isn't working yet, but it shouldn't be too hard, since I think can get away with just passing the scan codes to the X server.

Monday, December 8, 2008

Wayland gets a terminal

Still hacking on the Wayland project. I've spent some time getting the repaint loop and repaint notifications right, which is surprisingly tricky if you want to sync to vblank and make sure every client gets a chance to paint every frame. But I think I got it right and it looks beautiful when everything is synced to vblank and animating every frame. I've started looking into getting a fullscreen X server running under Wayland, which should be a matter of just passing the front buffer handle to Wayland instead of setting the mode. So far though, it's only crashing or locking up, so I wrote a terminal for Wayland as a small diversion

This is not a long term solution though, it has very limited ANSI support and I don't expect to extend it much (maybe enough to run emacs and irssi). The plan is to add a Wayland backend to GTK+, which should be a lot easier when Alex's client-side window work lands, and then just use VTE. For now, this goes a long way and the resizing is smooooth...

Thursday, December 4, 2008

Git is better than X

I found this link over on the github.com blog:

http://whygitisbetterthanx.com/

Of course, git is awesome and doesn't need selling, but if it did, that page does a pretty good job at it.

Monday, November 3, 2008

Premature publicity is better than no publicity

I guess. Maybe. At any rate, my latest secret project, is no longer secret: Phoronix ran an article about Wayland and slashdot in turn picked it up. They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager. And it's a very young project with a lot of FIXMEs and hand waving.

The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the NOTES file of the project.

Sunday, July 6, 2008

Ugh

Ok, I went through my old post and deleted blog spam and closing old post for comments and now all these posts appear brand new. Sorry about the noise.

Monday, March 31, 2008

DRI2 Direct Rendering

I just committed the last bit of DRI2 work for now to the xserver, mesa and xf86-video-intel repos. This work enables direct rendering to redirected windows:

So what's going on in this screenshot? Totem is playing the trailer from the new blender open movie project, Big Buck Bunny. While this looks to be a great follow-up to their previous movie, Elephants Dream, the interesting thing here is that it's playing using textured video under the batchbuffer branch of the intel driver, backed by the kernel video memory manager (TTM). Traditionally the X video extension (Xv) has been implemented by an overlay mechanism that lets the driver configure the hardware to scan out the pixels in the video area from a different buffer, doing color conversion and scaling on the fly. In other words, as the hardware scans through video memory to send the pixels to the monitor, it flips to read from a different buffer as it enters the window that shows the video. It's a fairly simple mechanism and it's cheap to implement in hardware, but it doesn't work for redirected windows. Textured video uses the 3D hardware to do scaling and color conversion, and since that is just regular 3D rendering, it can be redirected just fine, as seen in the screenshot. The textured video work was done by Eric Anholt and it's been in the intel driver for a while now - what's new here is that it runs under DRI2.

Also in this screenshot we have good old glxgears and MacSlows cool RGBA GLX demo. Both of these GLX applications are doing direct rendering to redirected windows. The main motivation behind the DRI2 work was to get redirected, accelerated rendering working. The first step got AIGLX (indirect rendering) working, and with this last bit, direct rendering now also works. The RGBA demo further demonstrates that we can now create a window with an RGBA visual and render to it from OpenGL and the compositing manager (in this case compiz) will composite it and blend it correctly with the rest of the desktop contents.

With Xv and Open GL finally working under composite, the intel driver is in pretty good shape. We're getting closer to a point where we can ship with a compositing manager enabled by default. In Fedora 9, we're shipping all this as a technology preview kind-of thing. DRI2 still has a number of crashers that I'm chasing and it's very new code. There will be an xorg.conf option or similar that will enable the batchbuffer branch of the intel driver and the DRI2 infrastructure. Hopefully by the time Fedora 10 comes out, it will be on by default.

Monday, February 11, 2008

Building and installing the DRM/DRI/X stack

When I work on the X stack I typically compile and install all the packages into an install prefix in my home directory, typically $HOME/install. That way I can keep my system packages intact and even have multiple versions or branches of the stack installed. This recently got a lot easier with the autoconfiscation of mesa so I decided to write up a short tutorial on how to do this. I like to first uninstall my distributions development packages for the projects involved just to make sure the configure scripts don't pick up a wrong version. For Fedora this is something like

rpm -e libdrm-devel xorg-x11-server-devel
In previous Fedora releases, the xorg-x11-server-devel package was called xorg-x11-server-sdk.

To bring up an X server with DRI, we'll need to clone the drm, mesa, xserver, xf86-input-evdev and a video driver repository. By default, git will check out the master branch when you clone, but if you want to try a different branch of a repository you have to say

git checkout -b intel-batchbuffer origin/intel-batchbuffer

after cloning to check out the intel-batchbuffer branch

First step is building drm

git clone git://git.freedesktop.org/git/mesa/drm
cd drm
./autogen.sh --prefix=$HOME/install
make
make -C linux-core
make install

The make -C linux-core step will build the DRM modules for the current kernel and needs the kernel-devel package on Fedora.

For the rest of the builds, we'll need this environment variable set:

export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig

Now that we have libdrm built and installed we can build mesa. Mesa doesn't use automake and doesn't come with an autogen.sh script so we have to bootstrap it a little differently:

git clone git://git.freedesktop.org/git/mesa/mesa
cd mesa
aclocal
autoconf
./configure --prefix=$HOME/install --with-driver=dri --with-dri-driverdir=$HOME/install/lib/dri
make
make install

Optionally, pass --disable-glu --disable-glw to the configure script to cut down build time a bit if you don't need these libraries (who does?).

Now we can build the X server. The configure script doesn't pick a good default for the font path, and the X server is going to bitch about this when we try to start it. I find that it's easiest just to built in the couple of core fonts the X server needs:

git clone git://git.freedesktop.org/git/xorg/xserver
cd xserver
./autogen.sh --enable-builtin-fonts --prefix=$HOME/install --with-mesa-source=$HOME/src/mesa
make
make install

With the X server installed in the prefix, we can start building drivers. The X server installs a couple of autoconf macros that aclocal needs to be pointed to, so for building drivers we need to set the ACLOCAL variable to:

export ACLOCAL="aclocal -I$HOME/install/share/aclocal"
Having set this, building the intel and evdev drivers is easy:

git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
cd xf86-video-intel
./autogen.sh --prefix=$HOME/install
make
make install

To run the new server I usually just cd to $HOME/src/xserver/hw/xfree86 as root and run the Xorg binary there, but first load the DRM modules we compiled above. You typically need to unload the old versions first and then load the ones you compiled (assuming intel hardware):

rmmod i915
rmmod drm
insmod $HOME/src/drm/linux-core/drm.ko
insmod $HOME/src/drm/linux-core/i915.ko

Second, remember to set

export LD_LIBRARY_PATH=$HOME/install/lib
after changing to root so the X server picks up the right libdrm. The X server will use the system xorg.conf from /etc/X11 by default, but that can be changed by passing an option to the X server configure script or passing the -config option to the server.

To actually launch applications under the server I typically just use a lame hack such as

./Xorg && gnome-terminal --display=:0

or more often I just run the X server and applications from a remote login. Before running direct rendering OpenGL applications, you need to the path to the DRI drivers:

export LIBGL_DRIVERS_PATH=$HOME/install/lib/dri

and voila, you can now run OpenGL applications on your very own, hand-built X/DRI/DRM stack. It's not terribly useful for daily use, but I find that it's the best set up for developing and tracking upstream development.

Tuesday, January 8, 2008

Awesome prize of the day...

goes to Dan Nicholson for adding autoconf support to mesa. For the first time, mesa can now pick up libdrm from a non-standard location (say, ~krh/install/lib/libdrm.so) automatically through pkg-config. With that, it's possible to build the entire X/DRI/OpenGL stack in a non-standard prefix, so you can work on the stack, without having to overwrite system libraries. And it's a simple and clean solution that can co-exist with the old hand-rolled config system. Good work!