urn:lj:livejournal.com:atom1:bgoglin Brice Goglin Brice Goglin 2009-11-05T17:58:25Z urn:lj:livejournal.com:atom1:bgoglin:18689 2009-10-31T12:23:33Z 2009-11-05T17:58:25Z <p> We have a SuperMicro machine with a X8DAH motherboard at work. It contains 2 Intel Xeon Nehalem X5550 (8 cores, 16 threads total) with 3 GPUs. As several Nehalem motherboards, there are actually 2 IO hubs, one near each socket. </p> <pre> --------- ------------ ------------ --------- | Mem#0 |===| Socket#0 |===| Socket#1 |===| Mem#1 | --------- ------------ ------------ --------- || || ----------- ----------- | IOHub#0 |===| IOHub#1 | ----------- ----------- || || GPU#0 GPU#1+2 </pre> <p> So PCI devices behind one IO Hub are closer to one socket than to the other one. So DMA performance depends on where the target memory is located: in the memory near one socket, or in the other memory node. The motherboard manual tells us which PCI slots are actually behind which IO hub (and thus near which socket/memory). And benchmarking our GPUs confirms the actual position of each PCI devices in the above picture. But we want to find out such information automatically to ease deployment and portability of applications. Linux may report such information through sysfs: </p> <pre> $ cat /sys/bus/pci/devices/0000:{02:00.0,84:00.0,85:00.0}/local_cpulist 0,2,4,6,8,10,12,14 0,2,4,6,8,10,12,14 0,2,4,6,8,10,12,14 </pre> <p> However, this is wrong since 0,2,4,6,8,10,12,14 means <em>near socket #0</em> while 2 GPUs are actually near socket #1 (CPUs 1,3,5,7,9,11,13,15). This could have been a bug in the Linux kernel, but it's actually a bug in the BIOS (Linux just needs to report what the BIOS tells). So we talked to SuperMicro about it and tried upgrading the BIOS. </p> <br /> <p> The first BIOS upgrade (from 1.0 to 1.0b) went kind of bad: the machine didn't boot anymore at all, not even any BIOS message on screen. Fortunately, we removed the GPUs and it booted again. But Linux didn't have any NUMA information at all. It was just saying there was a single NUMA node instead of 2. So we just forgot about all this mess and downgraded back to the older BIOS. </p> <p> Another BIOS update came out recently (1.0c) so I contacted SuperMicro to know if it was worth upgrading. At some point, they asked me to try disabling NUMA in the current BIOS. The machine didn't boot anymore... except after removing some GPUs. Exactly as above. It seems that there is an incompatibility between disabling NUMA in the BIOS and having multiple GPUs in the machine. And the first BIOS upgrade apparently disabled NUMA by default, causing all the above problems with BIOS 1.0b. </p> <br /> <p> So we had to try upgrading again, and make sure NUMA wasn't left disabled by default again. Instead of going back to 1.0b, I upgraded the BIOS to the latest release (1.0c) directly. And now the machine finally reports the right PCI-NUMA information! </p> <pre> $ cat /sys/bus/pci/devices/0000:{02:00.0,84:00.0,85:00.0}/local_cpulist 0-3,8-11 4-7,12-15 4-7,12-15 </pre> <p> You might have noticed that CPU numbering changed in the meantime (CPU number interleaving is different), but I don't care since we have hwloc (<a href="http://www.open-mpi.org/projects/hwloc/">Hardware Locality</a>) to deal with it. Now the development version of our lstopo tool reports the whole machine topology, including PCI, as expected: </p> <div align="center"> <a href="http://pics.livejournal.com/bgoglin/pic/00002zb7"> <img src="http://pics.livejournal.com/bgoglin/pic/00002zb7" width="326" /> </a> </div> <br /> <p> In short, if you have a X8DAH motherboard, don't disable NUMA in the BIOS (why would you do that anyway?) since it causes boot failures in some cases (when 3 GPUs are connected here), and upgrade to 1.0c if you care about memory/PCI locality/performance (which is probably the case anyway). </p> <div align="right">(<a href="http://bgoglin.livejournal.com/18689.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:18559 2009-09-13T00:02:15Z 2009-09-13T18:28:21Z <p> No Xorg update entered testing since Lenny was released. The last big remaining bug in unstable was the Intel driver locking up on i865 when the UXA/GEM acceleration is used (and 2.8.x only supports UXA so there is no work around). See <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541307">#541307</a>. </p> <p> Fortunately, Eric Anholt found out that it was caused by a kernel bug in the intel-agp driver. The fix is not in vanilla 2.6.31, so you'll have to apply the <a href="http://lists.freedesktop.org/archives/intel-gfx/2009-September/004122.html">patch</a> or wait for an updated 2.6.31.x kernel to be released. </p> <p> Anyway, the Intel driver 2.8.1 as well as Xserver 1.6 and Mesa 7.5 will enter testing soon. If you have a i865, make sure your kernel contains the above fix or you'll likely experience lockups soon after X startup. </p> <p> <b>Update:</b> If building the intel-agp driver as a module, you will also need <a href="http://lists.freedesktop.org/archives/intel-gfx/2009-September/004128.html">another small patch</a> to export the <tt>clflush_cache_range()</tt> function to modules. </p> <p> <b>Update:</b> Everything just entered testing of real. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/18559.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:18277 2009-07-27T07:29:34Z 2009-07-27T07:32:05Z <p> Another round of quick notes about X in unstable while the XSF team is on vacation. </p> <p><i><u> <b>Intel Driver and PAE kernels</b> </u></i></p> <p> If upgrading to xserver-xorg-video-intel broke X or made it very slow, make sure you are not using a PAE/bigmem kernel. The Intel driver now enforces UXA for acceleration. But UXA requires GEM support in the kernel, and GEM is not compatible with PAE before 2.6.31. So if you have PAE in your kernel (CONFIG_HIGHMEM64), i.e. for instance if you are using a -bigmem kernel, your Xorg.0.log will say: </p> <pre> (EE) intel(0): [drm] Failed to detect GEM. Kernel 2.6.28 required. (EE) intel(0): Failed to become DRM master. </pre> <p> Obviously, 2.6.30 should be enough when 2.6.28 is required. But 2.6.30 with PAE is not. </p> <p><i><u> <b>Return of the DRI2 breakage</b> </u></i></p> <p> It looks like the DRI2 breakage in Xserver 1.6.1.901-3 wasn't enterily fixed in 1.6.2. According to <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538637">#538637</a>, Xserver 1.6.2 didn't work with KDE4.2 effects when built against Mesa 7.4.4. Fortunately, Mesa 7.5 is in unstable now, and the new Xserver 1.6.2.901-1 was built against it. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/18277.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:17951 2009-07-21T14:48:55Z 2009-07-21T14:49:07Z <p> The Intel driver 2.8.0 has been uploaded to unstable. The biggest changes in there is that support for DRI1, XAA and EXA has been dropped. It means that the driver now always uses UXA and DRI2 now. </p> <p> KMS (Kernel Modesetting) is still optional (and the non-KMS crash from 2.7.99.902 has been fixed in 2.8.0). But you might want to use a recent kernel, which means 2.6.30 or 2.6.31-rc. </p> <p> There are still some problems with UXA/DRI2 on old boards such as my i865. So if you encounter any big problem, you might want to downgrade to driver 2.7.1 (some old packages are available at <a href="http://people.debian.org/~bgoglin/rebuilds/Xserver1.6/">here</a>) and switch away from UXA. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/17951.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:17871 2009-07-13T23:02:01Z 2009-07-14T22:13:22Z <p> A couple news from the mostly-offline X Strike Force team: </p> <p> The previous upload of xserver-xorg-core (2:1.6.1.901-3) severely broke DRI2 and more. 2:1.6.2-1 has been uploaded, it should hopefully fix all this. </p> <p> Intel driver 2.7.99.902 has landed in experimental as well. </p> <p> As expected, the arrival of Linux kernel 2.6.30 helped a lot. So if you had problems, especially performance problems with 2.6.29, make sure you try 2.6.30. If you're playing with kernel modesetting, upgrading to kernel 2.6.31 and latest intel driver in experimental is probably a good idea as well. </p> <p> <b>Update:</b> Intel driver 2.7.99.902 is broken when NOT using Kernel Modesetting, see <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537052">#537052</a>. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/17871.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:17612 2009-05-11T07:08:41Z 2009-05-11T07:11:51Z <p> We got many bug reports about X being slow. Many of them are caused by some MTRR/PAT problems in kernel 2.6.29. But some are not. </p> <p> It appears to be caused by Debian 2.6.29 kernels not containing ugly binary graphics firmware anymore. Indeed, radeon, r128 and mga driver need a firmware for 3D, but also for some 2D and Xv features (basically everything that's hardware accelerated). So if you use one of these X drivers and you have some problems, a quick look in the kernel logs might tell you that a firmware is missing. Installing the firmware-linux package may help then. We are adding the corresponding Suggests line to X drivers. </p> <p> Moreover, some people are upgrading to 2.6.30 pre-release because it contains DRM support for R600 boards. A ugly binary firmware is needed as well and it has obviously been removed from Debian 2.6.30 experimental packages. But firmware-linux does not seem to contain this firmware yet. So if you want 2.6.30 for R600 DRM, you want to either build your own 2.6.30 kernel, or wait for an updated firmware-linux package to be available with R600 firmware. See <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523467#88">bug#523467</a> for an example. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/17612.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:17395 2009-02-14T09:45:45Z 2009-02-25T08:40:51Z <p> Now that the final Mesa 7.3 is available in experimental (and built on most architectures), it is actually easy to get DRI2 in Debian if you have an Intel board. </p> <p> First, make sure you have a recent kernel, otherwise it may fail miserably. I am running 2.6.29-rc here, and I am not even sure 2.6.28 would be enough. Hopefully, one day the driver/server will properly detect and report problems when it runs on a old kernel :) </p> <p> Enable the new UXA acceleration architecture with <tt>Option "AccelMethod" "UXA"</tt> in the device section of your xorg.conf. Restart X. You should see DRI2 enabled in the log. Now start Compiz and it works. You can see a wobbly glxgears! </p> <p> Well, on my i945, Compiz was very slow by default. I add to disable <i>Sync to-VBlank</i> in the display settings in Compiz' general options. If you don't want Compiz, you may also try running <tt>xcompmgr</tt> and then play with <tt>transset</tt> to put transparency on 3D applications. </p> <p> <b>Update:</b> Added kernel requirements, added how to make Compiz not slow, removed -a from xcompmgr. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/17395.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:16916 2009-02-14T09:34:28Z 2009-02-14T09:35:13Z <p> Apart from interesting features such as DRI2, KMS or input-hotplug, there are some minor changes in X in experimental that actually appear to disturb many users. </p> <p> The first one is that Ctrl-Alt-Backspace does not kill X anymore. There is no easy consensus here, but many people were annoyed of killing X by mistake, so it's disabled by default now. To reenable it, add to the ServerFlags section of your xorg.conf: <pre> Option "DontZap" "off" </pre> </p> <p> Another one is the background during X startup. Say goodbye to the old well-known grey background. Now you get a black background by default. To revert to the old behavior, pass -retro on the server command line (for instance in /etc/X11/xinit/xserverrc). Note that this option also reenables Ctrl-Alt-Backspace killing the server. </p> <p> Finally, you might also see <tt>glxgears</tt> reporting very low frame rates (60) on some hardware. Well, please remember that it is not a benchmark, the output basically means nothing. This is why some distros even removed the fps output by default. The thing is that recent DRM stacks will just synchronize frame rendering on vertical blanks (can anybody here see 1000fps with human eye?). So if you have a 60Hz refresh rate, glxgears will report 60fps, that's it. But it has nothing to do with DRI or 3D being slow. Please try some relevant 3D programs or benchmarks before complaining :) </p> <div align="right">(<a href="http://bgoglin.livejournal.com/16916.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:16734 2009-01-24T21:07:16Z 2009-02-01T11:44:51Z <p> I have been wondering for a while how to get X.org "input-hotplug" to work, but I never actually tried before today. It is actually fairly easy, once you know what to do. </p> <p><b><u>Requirements</u></b></p> <p> First, make sure you have the evdev X driver installed (xserver-xorg-input-evdev). You might want to use X packages from experimental since things are much more recent than in Lenny or Sid these days, and upstream improved input management in the meantime. Then, if you are not running a pre-packaged kernel, check the the evdev driver is enabled and loaded in your kernel (CONFIG_INPUT_EVDEV). </p> <p><b><u>Telling hal what to do with input devices</u></b></p> <p> Now, you need to tell hal how to configure your input devices. Actually, you do not have much to do since latest <tt>xserver-xorg-input-evdev</tt> packages bring what you need. hal reads all <em>fdi</em> files under <tt>/usr/share/hal/fdi/policy</tt> to find out how devices should be configured. If you run <tt>lshal</tt> and look for <em>input</em>, you should see that the evdev is planned to drive your input devices. </p> <p> However, if you look at keyboard devices in lshal (look for <em>input.keys</em>), you will see that the US layout is used. To switch to another layout, you can add some overriding rules as a new <tt>*.fdi</tt> file in <tt>/etc/hal/fdi/policy/</tt>. For instance, to get French layout: <pre style="margin-left: 24px; font-size: 80%;"> &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;deviceinfo version="0.2"&gt; &lt;device&gt; &lt;match key="info.capabilities" contains="input.keys"&gt; &lt;-- Enforce XkbLayout=fr and XkbVariant empty --&gt; &lt;merge key="input.xkb.layout" type="string"&gt;fr&lt;/merge&gt; &lt;merge key="input.xkb.variant" type="string" /&gt; &lt;/match&gt; &lt;/device&gt; &lt;/deviceinfo&gt; </pre> </p> <p> Thanks to this, you can enforce XkbLayout, XkbVariant and friends as usual in <tt>/etc/X11/xorg.conf</tt>. Don't forget to restart hal after modifying some fdi files. Then run <tt>lshal</tt>, and look for Xkb, you should find your setup there. Note that you can add some matching rules to configure some devices with different setups if needed. Just need to read the output of <tt>lshal</tt> and find something like a hardware identifier to match on. </p> <p> You can find some documentation about these rules by looking at the existing fdi files in <tt>/usr/share/hal/fdi/policy/20thirdparty/</tt>, and in the upstream <a href="http://cgit.freedesktop.org/xorg/xserver/plain/config/x11-input.fdi">x11-input.fdi</a> (note that <tt>input.xkb.foo</tt> is the actual recommended syntax instead of <tt>input.x11_options.XkbFoo</tt>). </p> <p><b><u>Touchpads</u></b></p> <p> If you have a touchpad and want to use the synaptics driver, installing the <tt>xserver-xorg-input-synaptics</tt> will bring another fdi file. <tt>/usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi</tt> matches <em>input.touchpad</em> in the device capabilities in hal. Now the synaptics driver will be automagically loaded for your touchpad (instead of evdev for regular mice). Again, you can override this rule in <tt>/etc/hal/fdi/policy/</tt> and you can add many configuration options for synaptics as well. See <tt>/usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi</tt> to get an example. </p> <p> Fortunately, you will not have to manually take care of the above <tt>/etc/hal/fdi/policy/</tt> file for ever. The plan is to have hal look at the Debian console configuration and get at least the keyboard layout from there automatically. </p> <p><b><u>Telling the Xserver to talk to hal</u></b></p> <p> Now, you need to tell the Xserver to use what hal wants. Basically, you want to remove everything about keyboard, mouse and other input devices from your xorg.conf. Just drop all <tt>InputDevice</tt> sections and all references to them within other sections. With recent Xserver versions, options <tt>AllowEmptyInput</tt> and <tt>AutoAddDevices</tt> are enabled by default (otherwise, you might have to add them in the <tt>ServerFlags</tt> section). </p> <p><b><u>Ignoring a device</u></b></p> <p> If you do not want Xorg to use one of your input device, in the past you would just have not talked about it in xorg.conf. Now, hal notifies the server of all devices, and all of them are enabled by default. To disable it, you can use something like: <pre style="margin-left: 24px; font-size: 80%;"> &lt;match key="info.product" contains="myname"&gt; &lt;remove key="input.x11_driver"/&gt; &lt;/match&gt; </pre> </p> <p><b><u>For more information</u></b></p> <p> For more documentation, you want to read <a href="http://who-t.blogspot.com/">Peter Hutterer's blog</a>, especially <a href="http://who-t.blogspot.com/2008/07/input-configuration-in-nutshell.html">this post</a> and <a href="http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html">this one</a>. </p> <p> By the way, if you don't want this input-hotplug thing and you want to run a recent Xserver anyway, you should set <tt>AllowEmptyInput</tt> and <tt>AutoAddDevices</tt> to off in the <tt>ServerFlags</tt> section. </p> <p><b><u>Update:</u></b> Fixed the way to manage fdi files, fixed the syntax of input.xkb.foo rules, added a paragraph about synaptics, added a way to ignore a device, and organized things in sections. Thanks to everybody's comments. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/16734.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:16547 2009-01-24T20:59:53Z 2009-01-24T21:00:12Z <p> It has been a while since my last post here. Not because nothing happened, but mostly because I did not have time to do much for X. Fortunately, Julien is taking good care of X in Debian so we are still close to latest upstream bits. Obviously, due to Lenny's freeze, everything is happening in experimental these days. </p> <p><b><u>Xserver 1.6</u></b></p> <p> The release Xserver 1.6 is expected in the near future. 1.6-rc1 (1.5.99.901) entered experimental recently. Both video and input driver ABIs changed and very few drivers have been rebuilt so far. So if you're not running Intel or Radeon, you might not be able to upgrade yet. Please be patient :) You might have heard that many things are happening in X.org these days: DRI2, kernel-modesetting (KMS), RandR 1.3, ... Everything is not ready yet, but it's getting close for real. </p> <p><b><u>Radeon 6.10.0 and Intel 2.6.1</u></b></p> <p> Radeon driver 6.10.0 was released in early 2009. As usual, it brings many fixes, and improvements for modern boards (see <a href="http://www.botchco.com/agd5f/?p=34">Alex Deucher's blog</a> for details). However, Radeon is not ready for above DRI2 and KMS yet. Most of the development for these new features is first done in the Intel driver, which got recently bumped to 2.6.1 as well. </p> <p><b><u>DRI2</u></b></p> <p> DRI2 is the new Direct Rendering Infrastructure. The most noticeable change from the user point of view is support for <em>Redirect Direct Rendering</em>, which basically means that your 3D application can be wobbly/transparent in Compiz. See <a href="http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html">Kristian Høgsberg's blog</a> for details. </p> <p> If you want to try DRI2 on Intel, you have to enable UXA as the acceleration architecture in xorg.conf (<tt>Option "AccelMethod" "UXA"</tt> in the Device section). DRI2 will then be enabled automatically. Then, it may or may not work, depending for instance on the hardware. I get a black screen at startup on i865 while i945 works fine until I start Compiz (the server suddenly exits for some reason then). Note that you probably want to upgrade your Mesa packages to experimental as well here (7.3 has been released recently). Of course, running git snapshot of various components (Mesa, libdrm, kernel drm, Intel driver, ...) may help since the released versions seem to not be entirely ready yet. But, things should may be ready to use for everybody in the near future. </p> <p><b><u>Kernel Modesetting</u></b></p> <p> The other nice feature that makes a lot of noise in X.org these days is Kernel modesetting (KMS). It moves the management of mode (aka resolution+rate) into the kernel. It helps support for switching between different users' sessions, enables reporting of kernel messages (oops, panics, ...) while X is running, and reduces the need to blank the screen during boot (since the kernel can setup the display early and X doesn't have to change it later independently). </p> <p> KMS testing requires a bleeding-edge kernel (2.6.29). Using a git snapshot of the drm stack is probably a good idea as well since I couldn't get KMS to work on 2.6.29-rc2 here. Again only Intel will support KMS soon, but other drivers will follow. </p> <p><b><u>Panning is back (aka RandR 1.3)</u></b></p> <p> Xserver 1.6 brings support for the 1.3 version of the RandR X extension. Among other improvements, it reintroduces one feature that many users miss since it was removed back in Xserver 1.3 or so. "Panning" (often referred to as "Virtual Desktop") gives the ability to move the display within a larger screen when the mouse approaches from the border. Instead of being configured with the Virtual option in xorg.conf (this option means something else nowadays), it may now be enabled/tuned with xrandr --panning. You'll need the latest libxrandr2 and xrandr utilities to do so (the latter is not uploaded yet). </p> <div align="right">(<a href="http://bgoglin.livejournal.com/16547.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:16319 2008-07-29T17:29:05Z 2008-07-29T17:29:23Z <p> After the addition of ioremap_wc() in 2.6.26, MMU notifiers have now been merged in 2.6.27-rc1. It means that everything we have been wanting in the past to help HPC support is finally available upstream. We thought IB being merged (back in 2.6.11) would make things go fast, but it looks like these important features were not that obvious to people that did not work on HPC for a long time. </p> <p> Back in 2004, I was trying to get a safe registration cache working in the kernel for distributed storage over Myrinet. User-space regcaches are known to be a mess because they need to intercept malloc/free/munmap to invalidate cached segments. It works sometimes, but it is often a mess. In the kernel, you just can't intercept anything. So I wrote a patch called VMASpy which allowed other subsystems to be notified when part of a "registered" VMA is unmapped or forked. I never submitted it since it couldn't be accepted unless somebody in the kernel (i.e. IB) used it. Given <a href="http://lists.linuxcoding.com/kernel/2005-q2/msg10051.html">posts like this</a>, we see that IB people weren't conscious of the problem (nowadays they are interested but something in the IB specs apparently prevents them from using this). </p> <p> KVM needed some kernel support for its shadow pages, so MMU notifiers were written by Andrea Arcangeli (thanks a lot to him for keeping working on this despite many people not liking it). After a couple months of trolls, here we go with 2.6.27-rc1, we can now register a notifier per mm_struct and get a callback when part of the address space is unmapped. The implementation is very different from my VMASpy and of course much better :) But the final API provides similar features, so it should be great news for people working on registration caches or so. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/16319.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:16043 2008-07-29T16:55:32Z 2008-07-29T16:55:43Z <p> The myri10ge driver (Ethernet driver for Myri-10G boards) is broken in 2.6.26. It may not do anything at startup. It may also oops when opening the interface. The breakage appeared because the big pile of updates sent for 2.6.26 has been only partially applied (multislice RX is only applied in 2.6.27), and I did not test it intensively enough. Apologies. </p> <p> 2.6.27-rc1 is not affected by the breakage. And 2.6.25 works fine as well. Two patches have been sent to the stable release team for inclusion in 2.6.26.1. In the meantime, you may use Myricom's tarball, take the driver from 2.6.27-rc1 or from 2.6.25, ... or just not use 2.6.26 :) </p> <div align="right">(<a href="http://bgoglin.livejournal.com/16043.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:15638 2008-06-22T12:52:05Z 2008-06-22T13:25:15Z <p> As you may now, the r128 and mach64 drivers were split out of ati recently. However, for Etch-&gt;Lenny transitional reasons, xserver-xorg-video-ati still depends on xserver-xorg-video-r128 and -mach64. If you're bored of having to install these packages on your Radeon machine, beware that there is now xserver-xorg-video-radeon for you in unstable. It just contains the radeon driver and does not depend on any other driver. </p> <p> xserver-xorg-video-ati still exists, for transitional reasons. It also provides the "ati" meta-driver which takes care of loading "mach64", "r128" or "radeon" depending on your hardware. If you actually remove xserver-xorg-video-ati, don't forget to update your xorg.conf into Driver "radeon". </p> <p> <b>Update:</b> And of course, right after posting this, I get a bug report about the missing Replaces: ati. It will be fixed in 1:6.8.191-3. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/15638.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:15598 2008-06-14T11:36:16Z 2008-06-14T11:43:35Z <p><b><u>Xserver 1.4.2 for Lenny</u></b></p> <p> We originally planned to ship Xorg 7.4 and Xserver 1.5 since they were expected in February. However, Xserver 1.5 (and Mesa 7.1) are not released yet, so we are going to keep some updated X.org 7.3 for Lenny. A new Xserver 1.4 snapshot with some security fixes will enter testing soon. Once this is done, the final Xserver 1.4.2 will be uploaded. It is not perfect but it is the one you will get for Lenny. Many people suffered from Xserver 1.4 bugs in the last months, especially on the input side. Fortunately, many of them have been fixed. Lots of them were also caused by obsolete config files (that have to be manually fixes unfortunately). So we hope this Xserver 1.4.2 will be good enough for Lenny. </p> <p><b><u>XaaNoOffscreenPixmaps by default</u></b></p> <p> It is worth noting that XaaNoOffscreenPixmaps will now be the default (when XAA is enabled, i.e. by default for all drivers but Intel). It helps Compiz and seems to prevent various rendering problems from happening. Ubuntu and Fedora have been running such a patch for a while, so it looks like we are going to do the same for Lenny. To revert to the old behavior, use Option XaaOffscreenPixmaps in the Device section of your xorg.conf. </p> <p><b><u>ATI 6.8.191, Intel 2.3.2, Mesa 7.0.3++</u></b></p> <p> Apart from the server, some big components are getting updated these days: </p> <p> A new Mesa has been uploaded so that it enters testing before the libs are frozen. It contains the latest Mesa 7.0.x git snapshot, including lots of bugfixes, especially for Intel hardware. Mesa 7.0.3 was already pretty solid, this new one (7.0.3-2) will be even better. </p> <p> ATI is still getting a lot of work upstream as usual. 6.8.191 (aka 6.9-rc1) has been released this week. It brings r6xx support, acceleration for r5xx, EXA Composite for r3xx/r4xx/r500, textured video support, ... It also fixes many bugs everywhere. Given the big testing that we had in experimental in the last months, I consider it much better than 6.8.0, so I decided to put it in unstable even if it's only a release candidate. </p> <p> This new ATI does not include the r128 and mach64 drivers anymore. So the new xserver-xorg-video-r128 and -mach64 packages finally entered unstable as well. Due to unexpected upstream version numbers for mach64 and r128 and me messing up with epochs, they have a lower version number (6.8.0-1) than the previous snapshots from experimental (1:6.8.1~git...). There's almost no code difference though, but people might want to install the unstable packages anyway. The old snapshots will be removed from experimental soon. </p> <p> On the Intel side, a new 2.3.2 is expected soon, without many big improvements from what I have seen. </p> <p><b><u>X.org post-Lenny Future</u></b></p> <p> Xorg 7.4/Xserver 1.5 prereleases should arrive in experimental soon. It requires Mesa 7.1, which still needs some build fix and requires a new yet-to-be-released libdrm. Once all these are properly fixed and released, you should for instance be able to experience some interesting improvement in EXA. It may finally make XAA useless for real. Also, Xorg 7.4 will simplify the Xserver package maintenance since its build won't need the whole Mesa source anymore (the GLcore module that AIGLX uses will be built/shipped within Mesa). </p> <p><b><u>Stop build-depending on xutils!</u></b></p> <p> Also, we've been trying to cleanup the dependency mess in many X packages for a while. We removed the obsolete dependency from xutils to xutils-dev which was only needed for Sarge-&gt;Etch upgrade (xutils-dev was split out of xutils). However, many packages still wrongly build-depend on xutils. Lucas reported that removing this useless dependency in the latest Xorg upload caused 84 FTBFS. So, we're going to revert the change to avoid adding 84 RC bugs. However, everybody build-depending on xutils, please check whether you actually need xutils or xutils-dev so that we can quickly fix this after Lenny. <p> <div align="right">(<a href="http://bgoglin.livejournal.com/15598.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:15162 2008-03-02T14:57:00Z 2008-03-02T16:34:01Z <p> After xf86-video-ati 6.8.0 got released, George Sapountzis split the old r128 and mach64 subdrivers out of the common ati wrapper. So, starting from 6.8.1, the <tt>xserver-xorg-video-ati</tt> package only contains the <tt>radeon</tt> subdriver. The other subdrivers have been moved to their own <tt>xserver-xorg-video-r128</tt> and <tt>-mach64</tt> packages. All of them just landed in experimental. </p> <p> Your existing xorg.conf should work as before. I don't have any Mach or Rage board, so please test these new packages and report back if they don't work. Note that if your xorg.conf contains <tt>Driver "ati"</tt>, you'll need to keep <tt>xserver-xorg-video-ati</tt> installed. If you only have the <tt>mach64</tt> or <tt>r128</tt> package installed, you need switch to <tt>Driver "mach64"</tt> or <tt>"r128"</tt> in xorg.conf. </p> <p> On the <tt>radeon</tt> side, the upstream developers are still very active. The last feature that has been added is <em>Textured Xvideo</em>. The Xvideo extension is usually implemented using the hardware overlay, which basically inserts the video on screen at the very end of the rendering. While working very well, this feature conflicts with compositing managers such as Compiz which cannot transform the Xvideo image. </p> <p> The radeon driver now exposes a Texture Xvideo adaptor which is composite-aware, which means you can have wobbly Xvideo players in Compiz. The Overlay adaptor is still the default since the Textured video isn't considered stable enough yet. To enable it, you can use something like: <pre> mplayer -vo xv:port=74 foo.avi </pre> </p> <p> Where do I get this port 74 from? Just look at the output of <tt>xvattr</tt> or <tt>xvinfo</tt>: <pre> $ xvattr Found Xv 2.2 Adaptor: 0 Name: ATI Radeon Video Overlay Port: 73 [...] Adaptor: 1 Name: Radeon Textured Video Port: 74 Port: 75 [...] $ xvinfo X-Video Extension version 2.2 screen #0 Adaptor #0: "ATI Radeon Video Overlay" number of ports: 1 port base: 73 [...] Adaptor #1: "Radeon Textured Video" number of ports: 16 port base: 74 [...] </pre> </p> <div align="right">(<a href="http://bgoglin.livejournal.com/15162.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:15063 2008-01-19T10:15:38Z 2008-01-19T10:18:52Z <p> We are getting many bugs about wrong DPI configuration and DisplaySize not working. In most of the cases, it is actually caused by a confusion between Monitor sections in xorg.conf and RandR 1.2 outputs. </p> <p> With a default config, RandR 1.2 drivers will basically associate the unique Monitor section with their first output, even if not enabled. Bug <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461501">#461501</a> is a good example of this issue. </p> <p> RandR 1.2 drivers (intel, ati, nv for G80, mga in experimental, radeonhd so far) require that you specify which output is attached to which monitor. If you have a Monitor section with identifier "Foo" connected on output "BAR", then you want the following in your Device section: <pre> Option "Monitor-BAR" "Foo" </pre> </p> <p> Or (easier), just rename identifier "Foo" into "BAR". You need to add such a section for each output that you want to tweak (DisplaySize, ModeLine, PreferredMode). Then your tweaks will be applied to the right monitor/output. See the <a href="http://wiki.debian.org/XStrikeForce/HowToRandR12">HowToRandR12</a> sections III.1 and III.3 for details. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/15063.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:14593 2008-01-06T12:28:24Z 2008-01-06T16:08:02Z <p> One year ago, I started triaging the X.org BTS (by replying to #163057 iirc). I closed almost 1600 bugs since then, bringing the remaining ones to about 900 today. I am kind of proud of <a href="http://ftp.es.debian.org/~ender/XSF_bugs/graphs/total-year.png">Ender's graph</a> (when the URL works...). Even if the actual BTS triaging is done now, I still try to take care of X.org bugs. And it's not that easy unfortunately... </p> <p> Almost 650 new bugs were opened this year against X.org packages. 250 of them are already fixed, more than one hundred have been forwarded upstream. It doesn't mean that 300 bugs still apply to our packaging. Most of our X packages are simple (apart from the xserver-xorg postinst mess that David is cleaning). But, there are lots of problems that we have no clue about, or that miss some info because people can't upgrade to unstable, ... </p> <p> I am sometimes tired of getting so many bugs without being able to do much about them. Maybe because upstream doesn't care enough about some problems (lots of drivers are unmaintained and get broken more and more when new features are added for a couple more important drivers). So, I sometimes tend to concentrate my work on what I like and trust. Some people noticed that xserver-xorg-video-ati get very often updated these days (6 uploads in the last 20 days). Of course, the reason is that I own a r300 board :) But also because its upstream devs are very good, it's very nice and easy to work with them. </p> <p> Of course, we have a lot of work and few people to do it. That's kind of sad since playing with X is very interesting. Most users are very happy when discovering things like RandR 1.2 or Compiz. Getting a chance to test them early and understand their internals is very cool. But, as said in some other posts, hacking on X.org doesn't seem to look fun. If you're interested anyway, taking care of the bugs is a very easy way to learn a lot. I had no clue about X one year ago and I learned a lot by taking care of the BTS. I would be glad to get some help now :) </p> <div align="right">(<a href="http://bgoglin.livejournal.com/14593.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:14265 2007-12-21T08:13:10Z 2007-12-21T17:05:27Z <p> I finally uploaded the ATI RandR 1.2 driver to unstable. This is xserver-xorg-video-ati 1:6.7.197-1. Lots of people were already using the experimental packages to get the RandR 1.2 support. And it looks pretty good, at least not worse than the obsolete 1:6.6.193-3 that has been in unstable during the last months or the prehistoric 1:6.6.3-2 still in testing. </p> <p> Things are (again) moving fast upstream. Right after the 6.7.197 released, they merged 2 important branches in master: <ul> <li> <b>atombios-support</b> brings support for r500 and r600 boards using AtomBIOS. Yes, this is for the same boards as the ones supported by the old avivo and the recent radeonhd driver, but the implementation differs a lot. See <a href="http://airlied.livejournal.com/53129.html">Dave Airlie's blog entry</a>. </li> <li> <b>zaphod-lolz</b> brings back support for the old Zaphod mode that lots of people have been missing. If you like having two screens (:0.0 and :0.1), you might like this. See <a href="http://airlied.livejournal.com/54069.html">Dave Airlie's blog entry</a> for some details. </li> </ul> <p> <p> Given how important all this is, I also uploaded a new snapshot of upstream master into experimental. This is xserver-xorg-video-ati 1:6.7.198~git20071221.be7f8fd3-1. Merry Christmas! </p> <p> <b>Update:</b> Looks like this is Radeon day. A new version (1.1.0) of the radeonhd driver has been released, so I just uploaded it to unstable too. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/14265.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:13886 2007-11-11T13:12:45Z 2007-11-11T17:06:49Z <p> Once ftp-master is back, several important X updates should arrive. The first one is a Xserver pre-1.4.1 snapshot (the official 1.4.1 is expected soon). It will bring many input fixes, for instance for broken LEDs (reported 12 times). Unfortunately, there are still some input bugs in there, for instance <a href="https://bugs.freedesktop.org/show_bug.cgi?id=13114">upstream bug #13114</a> which is kind of annoying (I can't play xmoto anymore). </p> <p> A new release of the Intel driver is coming soon. The first release candidate, 2.1.99, has been uploaded to experimental. The most noticable changes include some fix for VT switch and the support for some rare LVDS chipsets (ch701x). Also EXA is now enabled by default, which is good news since XAA had some bugs that won't ever be fixed (for instance when using XV in Compiz, see <a href="https://bugs.freedesktop.org/show_bug.cgi?id=10912">upstream bug #10912</a>). Before 2.2 is released, we might get a fix for backlight support which got fixed on some boards while broken again on some others in the past (see <a href="https://bugs.freedesktop.org/show_bug.cgi?id=11527">upstream bug #11527</a>). </p> <p> The new Mesa 7.0.2 release might be worth taking a look too since it brings many fixes, including a working <tt>__gluInvertMatrix()</tt> which should solve many GLU-related problems that have been reported, and some fixes for several Blender crashes. </p> <p> Not much activity on the xserver-xorg-video-ati side recently. But given how well it works these days, I am seriously thinking of uploading the next snapshot to unstable (1:6.6.193-3 didn't help a lot there). </p> <div align="right">(<a href="http://bgoglin.livejournal.com/13886.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:13803 2007-10-14T11:12:44Z 2007-10-14T20:23:20Z <p> Given the massive changes implied by multiple RandR 1.2 drivers being available, and looking at how many bugs were reported because of wrong X configuration, I wrote a <a href="http://wiki.debian.org/XStrikeForce/HowToRandR12">RandR 1.2 guide</a> on the wiki. It should at least be useful for people upgrading from old drivers... </p> <div align="right">(<a href="http://bgoglin.livejournal.com/13803.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:13317 2007-10-14T10:41:21Z 2007-10-14T10:42:22Z <p> I have been installing several Dell 2950 boxes recently and managed to configure <i>Remote Console Access</i> through IPMI 2.0. Since there are no nice/complete how-to in Google, here's one. </p> <p> You should first choose a new sub-network for IPMI. Although the IPMI network traffic uses the same physical network than the <b>first</b> interfaces of the boxes (make sure this one is connected), it has different MAC addresses and should use different IP addresses. If your boxes have 10.0.0.x regular IP addresses, you may for instance use <b>10.0.99.x</b> for IPMI. Adding corresponding hostnames (for instance <b>xxx-ipmi</b> for host xxx) in your DNS or <tt>/etc/hosts</tt> file might be good too. </p> <p> At the end of the BIOS boot, press <b>Ctrl-e</b> to enter the <b>Remote Access Setup</b> and enable actual IPMI Remote Access (note that all this may also be configured from Linux using ipmitool after loading some ipmi kernel modules). <ul> <li>Set <b>IPMI over LAN</b> to <b>on</b></li> <li>Enter the <i>LAN parameters</i> menu: <ul> <li>Set <b>IP Address source</b> to <b>static</b></li> <li>Set <b>Ethernet IP Address</b> to <b>10.0.99.x</b></li> <li>Set <b>Subnet Mask</b> to <b>255.255.255.0</b></li> <li>Set <b>Hostname string</b> to something like <b>xxx-ipmi</b></li> </ul></li> <li>Enter the <i>LAN User Configuration</i> menu: <ul> <li>Set <b>Account User Name</b> to some login</li> <li>Enter a password in <b>Enter Password</b> and again below in <b>Confirm Password</b> </ul></li> </ul> </p> <p> IPMI is now configured correctly. You should be able to ping the IPMI IP addresses. <pre> $ ping 10.0.99.x </pre> </p> <p> Now, you may for instance reboot a node using the following line. Replace <tt>cycle</tt> with <tt>status</tt> to see the status, <tt>off</tt> to shutdown, <tt>on</tt> to start. <pre> ipmitool -I lan -H 10.0.99.x -U login -P passwd chassis power cycle </pre> </p> <p> Now we need to configure console redirection. It makes it possible to send the BIOS, Grub, and ttyS1 output through IPMI on the network on the <b>first</b> network interface. Note that COM2/ttyS1 is mandatory, it may not be COM1/ttyS0 instead. After booting, press <b>F2</b> to enter the BIOS. Go in the <i>Serial Communication</i> menu: <ul> <li>Set <b>Serial Communication</b> to <b>On with Console Redirection via COM2</b></li> <li>Set <b>Remote Terminal Type</b> to <b>VT100/VT220</b></li> <li>Set <b>Redirection After Boot</b> to <b>Enabled</b></li> </ul> </p> <p> With this configuration, you should see the BIOS and Grub output remotely using: <pre> $ ipmitool -I lanplus -H 10.0.99.x -U login -P password sol activate </pre> <p> <p> Then we want to see the kernel booting remotely. This is done by adding the following to the kernel command line. With Grub, you might want to add it to <tt># kopt=...</tt> and then run <tt>update-grub</tt> to update all automatic entries. <pre> console=ttyS1,57600 console=tty0 </pre> </p> <p> And finally, you might want to get a console login remotely through IPMI. To do so, add the following line to /etc/inittab: <pre> T0:23:respawn:/sbin/getty -L ttyS1 57600 vt100 </pre> </p> <p> With all this setup, the above <tt>ipmitool sol activate</tt> line will display the same thing than the physical console on the machine, which makes it very nice to configure the BIOS, change the kernel, debug, ... Note that <b>~</b> is the control character when using the console redirection. And <b>~.</b> may be used to leave the console. Also <tt>ipmitool sol deactivate</tt> may help if somebody did not leave the console correctly. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/13317.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:13122 2007-09-19T06:32:04Z 2008-11-08T23:43:17Z <p> The driver for ATI r5xx/r6xx boards that Suse developers have been working on for about 2 months with the <a href="http://bgoglin.livejournal.com/12755.html">recently released specifications</a> has been pushed to the freedesktop repository as <t>xf86-video-radeonhd</t>. So David packaged it and uploaded it in experimental as <tt>xserver-xorg-video-radeonhd</tt>. </p> <p> Of course, the driver is still very young, probably similarly stable than the now deprecated <tt>xserver-xorg-video-avivo</tt>. So if you want to test it, debug it and get it to work, you might want to join the corresponding IRC channel (<tt>#radeonhd</tt> on Freenode) and subscribe to the mailing list (<tt>radeonhd</tt> on the OpenSuse server, details are in the topic of the IRC channel). If not on IRC or on the mailing list, bugs should be reported at <tt>http://bugzilla.freedesktop.org</tt>, product <tt>xorg</tt>, component <tt>driver/radeonhd</tt>. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/13122.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:12835 2007-09-16T22:02:56Z 2007-09-16T22:03:19Z <p> Now that David pushed X.org 7.3 to unstable, experimental is available again for release candidates. So I just pushed <tt>xserver-xorg-video-mga</tt> 1.9.99. This is the first release candidate of the MGA driver with RandR 1.2 support. For the record, it means enabling/disabling/resizing/moving outputs dynamically. </p> <p> If you're planning to test it, you might want to read the <a href="http://lists.freedesktop.org/archives/xorg-announce/2007-September/000404.html">upstream announce</a> first. Tilman Sauerbeck did a very good job, but he doesn't have all kinds of board to test this. At least, the dual DVI G550 is known to not work. It might be good to report problems, either to us or directly to Tilman (IRC might be faster than reporting a bug...). </p> <p> As usual, you might want to refer to <a href="http://bgoglin.livejournal.com/10214.html">this</a> and <a href="http://bgoglin.livejournal.com/9846.html">this</a> to update your <tt>xorg.conf</tt> for RandR 1.2, and also <a href="http://bgoglin.livejournal.com/10423.html">this post</a> if the server doesn't choose the right mode by default. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/12835.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:12755 2007-09-12T20:22:20Z 2007-09-12T20:35:57Z <p> So, this time it was for real! AMD really meant it when they announce the release of specifications of ATI boards last weeks. During XDS2007 at Cambridge, we received the actual specs, 2 PDFs files, 460 pages for the M56 (Mobility X1600, r5xx board) and 436 pages for rv630. The files are now online, but I am not going to give the link here since the web server already suffered too much today (and the URL is easy to find anyway). </p> <p> People should NOT understand this as if we were going to get an open-source driver for all ATI boards next weeks. First, these are only 2D specifications for r500 and r600. 3D specs are expected in a couple weeks once AMD fixes the remaining issues. r300 specs might arrive later. Also, these specifications are pretty hard to use, as expected. There are something like 9000 registers in r6xx boards, and these PDF files are just description of these registers. It's of course far away from being a <i>"How-to write a driver?"</i>. So if you want to help, there will be lots of things to do. </p> <p> We also got a demo from some Suse guys of the driver there are working on. They got these specs about 2 months ago. And they already have some part of modesetting working. It means you might get your X server to start. There are about one hundreds different chipsets with their own quirks, so still lots of work to do. And then lots of performance things, 3D, ... to do. This driver is called "Radeon HD" so far. It will remain separated for now, but it might end up being merged with the upstream ATI driver later since the 3D engine are very similar (I personally hope it will happen). </p> <p> The reverse-engineered Avivo driver is dead now then. Fortunately, Jerome Glisse has been aware of the event for a couple months now, so he didn't waste to much time working on it. <tt>xserver-xorg-video-avivo</tt> will remain in Debian experimental until the new driver arrives. The good thing about Avivo is that it (and the ongoing Nouveau driver for Nvidia) led to the development of very nice reverse-engineering tools (revenge, renouveau, mmio trace, ...). They will be very useful for other graphic boards, or even some network hardware. </p> <p> Of course, many thanks to AMD for making this happen! </p> <div align="right">(<a href="http://bgoglin.livejournal.com/12755.html">Permanent link</a>)&nbsp;</div> urn:lj:livejournal.com:atom1:bgoglin:12340 2007-09-11T14:27:17Z 2007-09-11T19:14:42Z <p> The release plan for Xserver 1.5 and Xorg 7.4 was discussed during the X.org Developers' Summit in Cambridge (September 10-12th). This is what we expect to ship with Lenny, so here are some details about the upcoming. </p> <p><b><u>Timeline</u></b></p> <p> As usual, there will be a 6 months release cycle. So <b>Xorg 7.4 is expected on March 1st, 2008</b>. There won't probably be any new Xserver release before that since some changes (already merged) require all drivers to be updated anyway. So Xserver 1.5 is expected on the same date. </p> <p> Since there are already some known problems in Xserver, they also plan to release <b>Xserver 1.4.1 on November 1st</b>. </p> <p><b><u>PCI Rework</u></b></p> <p> The master branch of Xserver already contains the long-expected <tt>pci-rework</tt> which is supposed to fix all the PCI domains and other non-trivial PCI hierarchy support (important for ia64, but also for some powerpc and sparc users). </p> <p><b><u>RandR</u></b></p> <p> People having Intel, ATI or recent Nvidia boards learnt to love the RandR 1.2 extension which provides the ability to enable/disable, resize, rotate, move outputs within a single big virtual screen. More transformations should be possible with <b>RandR 1.3</b>. Hopefully, there will also be some standardization regarding output names in various drivers, or at least a way to retrieve the type of each output (LVDS, DVI, VGA, TV, ...). And the server should get an abstraction object to describe GPUs, which might make the support for multiple boards easier. </p> <p><b><u>Input</u></b></p> <p> On the input side, <b>XKB 2</b> and <b>XGE</b> should be merged, which shouldn't be really visible to end-users but should make internals much better. Then <b>MPX</b> (<b>Multi-Pointer X server</b>) might be in Xserver 1.5 too (if all semantics issues get fixed first). It would mean support for <b>multiple independent keyboard/mouse pairs</b> or so. See <a href="http://wearables.unisa.edu.au/mpx/">the MPX page</a> for details. </p> <p><b><u>Compositing</u></b></p> <p> Compositing still gets a lot of attention. Several distributions are actually thinking of enabling Compiz by default. EXA (the new acceleration architecture that has been designed for compositing) got improved a lot in Xserver 1.4. Several drivers including Intel and ATI r300 already work great with EXA (no need to use XAA + XAANoOffscreenPixmaps anymore) which means Compiz works very smoothly, even when resizing windows. XAA won't be removed soon though since lots of things needs to be fixed before that. There are also several videos available online, like <a href="http://youtube.com/watch?v=0MUOn_nJmRA">this one</a>. </p> <p> But one big piece is still missing for compositing: <b>directed rendering to redirected windows</b>. So far, if you start <tt>glxgears</tt> in Compiz, you will see that the gears completely ignore wobbli-ness of windows, other windows overriding them, cube rotation, ... they keep rendering of top of everything without any effect. Getting true support for compositing such windows requires lots of work in all parts of the DRI stack. Kristian Høgsberg got it to work (and we even get a great demo). See <a href="http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html">Kristian's blog</a> for details. Upstream devs are now working on integrating all modifications nicely in upstream Xserver, drivers, DRM module, Mesa, ... Once this works, you can get <tt>GLX_EXT_texture_from_pixmap</tt> for both direct and indirect rendering, and full support for GLX 1.4 in the server (only 1.2 is supported as of now). </p> <p> Also, redirected windows (let's say a wobbly window on a side of Compiz' cube) should get input events correctly thanks to <b>input transformation</b> in Xserver 1.5 (event coordinates will be converted into the redirected window coordinate space before being passed to the client application). <p> <p><b><u>Kernel-related reworks</u></b></p> <p> Compositing improvements actually require a large rework of the memory management in the server. Basically, we need a global management for both 2D and 3D object allocations, so that you can get both to work fine without having to change config options (things like <tt>XAANoOffscreenPixmaps</tt> or <tt>FbTexPercent</tt>). All this is related to the TTM (<b>Translation Table Maps</b>, see these <a href="http://www.tungstengraphics.com/xdevconf2006.pdf">slides</a> for details) which has been under development for a while. It requires to change the interface with the kernel DRM modules, and it won't happen before 2.6.24. The Xserver part of the work is not big, so it might still be done before 1.5 is released. Fortunately, once all this is ready, people should stop complaining about memory allocation failures, Compiz being slow because one option is not enabled by default, ... </p> <p> Another hot topic in the X.org/kernel area is about <b>moving modesetting in the kernel</b>. When you get a kernel panic, you only actually see it if not running X (or if logging kernel messages through the network). So your machine freezes, you don't know why, you have no way to know, and you just reboot. Getting panic messages on X would be much better. To do so, the kernel needs to now which mode is currently in use on the monitor and then it will render the message on the framebuffer. This require lots of work, so it will unlikely be in Xserver 1.5 though. </p> <p><b><u>Miscellaneous</u></b></p> <p> Xserver 1.5 will also contain <b>XACE</b> (security framework), the cleanup of the ABI (explicit <tt>_X_EXPORT</tt> required), and possibly <b>glucose</b> (OpenGL acceleration for X, see <a href="http://zrusin.blogspot.com/2006/08/glucose-and-graphics.html">Zack Rusin's blog</a>). </p> <p> I asked whether there was actually some work on building the <tt>GLcore</tt> server module as a part of Mesa so that building Xserver does not require the whole Mesa source anymore. People seem to agree the current situation is a real pain for distributions and we should make this change happen. But the actual work has to be done in Mesa anyway, we'll see what happens. </p> <div align="right">(<a href="http://bgoglin.livejournal.com/12340.html">Permanent link</a>)&nbsp;</div>