<?xml version='1.0' encoding='utf-8' ?>
<!--  If you are running a bot please visit this policy page outlining rules you must respect. https://www.livejournal.com/bots/  -->
<rss version='2.0'  xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:media='http://search.yahoo.com/mrss/' xmlns:atom10='http://www.w3.org/2005/Atom'>
<channel>
  <title>Brice Goglin&apos;s Blog</title>
  <link>https://bgoglin.livejournal.com/</link>
  <description>Brice Goglin&apos;s Blog - LiveJournal.com</description>
  <lastBuildDate>Thu, 07 Dec 2017 20:52:43 GMT</lastBuildDate>
  <generator>LiveJournal / LiveJournal.com</generator>
  <lj:journal>bgoglin</lj:journal>
  <lj:journalid>10730461</lj:journalid>
  <lj:journaltype>personal</lj:journaltype>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/20759.html</guid>
  <pubDate>Thu, 07 Dec 2017 20:52:43 GMT</pubDate>
  <title>XFCE moving icons around when changing monitor sizes</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/20759.html</link>
  <description>XFCE saves desktop icon positions in a file whose name depends on the desktop size. It means that icon positions are not preserved when switching from laptop-only to laptop + external screen.&lt;br /&gt;  &lt;br /&gt;Now I run this at the beginning of my XFCE session. Whenever a new positions file is created, I move it back to the default filename (which doesn&apos;t depend on the desktop size).&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
    #!/usr/bin/perl -w

    my $dir = &quot;/home/bgoglin/.config/xfce4/desktop/&quot;;

    chdir $dir;

    open WATCH, &quot;inotifywait -m -e moved_to . |&quot;
      or die &quot;Failed to notifywait.\n&quot;;

    while ($line = &lt;watch&gt;) {
      next unless $line =~ m/(.*) MOVED_TO (.*)/;
      my $file = $2;
      next if $file =~ m/\.new$/;
      next unless $file =~ m/icons.screen0-.*\.rc/;
      unlink &quot;icons.screen0.rc.bak&quot;;
      rename &quot;icons.screen0.rc&quot;, &quot;icons.screen0.rc.bak&quot;;
      print &quot;Moving $file to icons.screen0.rc\n&quot;;
      rename $file, &quot;icons.screen0.rc&quot;;
    }
&lt;/pre&gt;</description>
  <comments>https://bgoglin.livejournal.com/20759.html?view=comments#comments</comments>
  <category>admin</category>
  <category>linux</category>
  <lj:security>public</lj:security>
  <lj:reply-count>0</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/20598.html</guid>
  <pubDate>Sat, 16 Feb 2013 15:27:16 GMT</pubDate>
  <title>Besoin d&apos;un GPS? Evitez Tomtom, c&apos;est de l&apos;arnaque</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/20598.html</link>
  <description>Je suis l&amp;#39;heureux propri&amp;eacute;taire d&amp;#39;une voiture avec GPS int&amp;eacute;gr&amp;eacute;. Si c&amp;#39;est pratique au premier abord (notamment le joystick sur la console centrale), ca devient beaucoup plus compliqu&amp;eacute; quand on creuse un peu.&lt;br /&gt;&lt;br /&gt;Tout d&amp;#39;abord, la carte Tomtom n&amp;#39;est mise &amp;agrave; jour que tous les 3 mois, il faut payer pour avoir la mise &amp;agrave; jour, et elle n&amp;#39;est en fait jamais vraiment &amp;agrave; jour! Combien de fois on se retrouve en plein champ parce que Tomtom n&amp;#39;est pas au courant des travaux r&amp;eacute;alis&amp;eacute;s il y a un an... Tous les sites proposant des cartes sur Internet y arrivent mais pas Tomtom.&lt;br /&gt;Ensuite, leur fameux service Live marche bien, &amp;agrave; condition d&amp;#39;attendre 5 minutes avant de d&amp;eacute;marrer. Il est si long &amp;agrave; r&amp;eacute;cup&amp;eacute;rer les infos de trafic qu&amp;#39;on est d&amp;eacute;j&amp;agrave; coinc&amp;eacute; dans les bouchons avant qu&amp;#39;il nous pr&amp;eacute;vienne. Pas du tout pratique en ville. Et je ne parle pas des nombreuses fois o&amp;ugrave; le Live ne r&amp;eacute;pond pas.&lt;br /&gt;Jusqu&amp;#39;il y a peu, il proposait une recherche Google pour trouver tout et n&amp;#39;importe quoi. Tous les clients qui paient pour ce service l&amp;#39;ont vu r&amp;eacute;cemment remplac&amp;eacute; par Tomtom places qui est juste d&amp;#39;une nullit&amp;eacute; incroyable. Au final, on se retrouve &amp;agrave; chercher sur son smartphone puis &amp;agrave; entrer le r&amp;eacute;sultat dans le GPS. Super... Quitte &amp;agrave; utiliser le smartphone, autant prendre un GPS dessus...&lt;br /&gt;Bref, on se demande &amp;agrave; quoi &amp;ccedil;a sert de payer pour leur Live ou pour des mises &amp;agrave; jour de carte.&lt;br /&gt;&lt;br /&gt;Pire, leur m&amp;eacute;thode de distribution logicielle est nulle. Impossible de revenir &amp;agrave; une version ant&amp;eacute;rieure quand la derni&amp;egrave;re est buggu&amp;eacute;e. Et quand la derni&amp;egrave;re est buggu&amp;eacute;e au point de planter d&amp;eacute;finitivement votre GPS (de nombreux utilisateurs ont r&amp;eacute;cemment du aller chez leur garagiste pour r&amp;eacute;parer), ils la laissent en ligne sans pr&amp;eacute;venir qu&amp;#39;elle va peut-etre aussi planter votre GPS. Entre fin novembre 2012 et mi-janvier 2013, des centaines de clients se sont fait avoir alors que Tomtom savait dans quel cas le bug se produisait. Mais ils ont refus&amp;eacute; de le pr&amp;eacute;ciser dans l&amp;agrave; o&amp;ugrave; on t&amp;eacute;l&amp;eacute;charge les mises &amp;agrave; jour. Bravo.&lt;br /&gt;Et inutile de demander une indemnisation. Ils se consid&amp;egrave;rent comme non-responsables des d&amp;eacute;lais de r&amp;eacute;paration soi-disant impos&amp;eacute;s par nos garagistes. Sauf que ces derniers ne savent pas r&amp;eacute;parer (ben oui, un garagiste r&amp;eacute;pare des voitures, pas des GPS) et Tomtom ne leur fournit pas d&amp;#39;info, donc ca prend des semaines. Bref, un mois et demi avec un GPS plant&amp;eacute; et un service client qui nous ignore. Sympa.&lt;br /&gt;&lt;br /&gt;Quand on voit qu&amp;#39;un GPS gratuit comme &lt;a href=&quot;http://www.waze.com/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Waze&lt;/a&gt; sur smartphone a une carte plus &amp;agrave; jour et des infos de trafic aussi bonnes, inutile d&amp;#39;envisager de donner un seul euro &amp;agrave; Tomtom.</description>
  <comments>https://bgoglin.livejournal.com/20598.html?view=comments#comments</comments>
  <lj:security>public</lj:security>
  <lj:reply-count>1</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/20464.html</guid>
  <pubDate>Mon, 19 Jul 2010 12:34:15 GMT</pubDate>
  <title>Remote Console Access with IPMI on Dell R710</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/20464.html</link>
  <description>&lt;p&gt;
Our local servers are moving from Dell Poweredge 2950 to R710. A couple years ago, I wrote a &lt;a href=&quot;http://bgoglin.livejournal.com/13317.html&quot; target=&quot;_blank&quot;&gt;guide for Remote Console Access through IPMI 2.0 on the 2950&lt;/a&gt;. Some noticeable changes are needed for R710, so here&amp;#39;s a new updated guide. I also added some notes about R815 and R720 at the end, since they are very similar.
&lt;/p&gt;

&lt;p&gt;
You should first choose a new sub-network for IPMI. Although the IPMI network traffic uses a regular physical interface, it has a different MAC address and should use different IP address. If your boxes have 10.0.0.x regular IP addresses, you may for instance use &lt;b&gt;10.0.99.x&lt;/b&gt; for IPMI. Adding corresponding hostnames (for instance &lt;b&gt;xxx-ipmi&lt;/b&gt; for host xxx) in your DNS or &lt;tt&gt;/etc/hosts&lt;/tt&gt; file might be good too.
&lt;/p&gt;

&lt;p&gt;
At the end of the BIOS boot, press &lt;b&gt;Ctrl-e&lt;/b&gt; to enter the &lt;b&gt;Remote Access Setup&lt;/b&gt; and enable actual IPMI Remote Access
(note that some models can also be configured from Linux using ipmitool after loading some ipmi kernel modules).
&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Set &lt;b&gt;IPMI over LAN&lt;/b&gt; to &lt;b&gt;on&lt;/b&gt; (requires &lt;b&gt;iDRAC6 LAN&lt;/b&gt;)&lt;/li&gt;
&lt;li&gt;Enter the &lt;i&gt;LAN parameters&lt;/i&gt; menu:&lt;ul&gt;
&lt;li&gt;Keep &lt;b&gt;NIC Selection&lt;/b&gt; on &lt;b&gt;Shared&lt;/b&gt;&lt;/li&gt;
&lt;li&gt;Set &lt;b&gt;IPv4 Address source&lt;/b&gt; to &lt;b&gt;Static&lt;/b&gt;&lt;/li&gt;
&lt;li&gt;Set &lt;b&gt;IPv4 Address&lt;/b&gt; to &lt;b&gt;10.0.99.x&lt;/b&gt;&lt;/li&gt;
&lt;li&gt;Set &lt;b&gt;Subnet Mask&lt;/b&gt; to &lt;b&gt;255.255.255.0&lt;/b&gt; and set &lt;b&gt;Default Gateway&lt;/b&gt; if needed&lt;/li&gt;
&lt;li&gt;You may set &lt;b&gt;Host Name string&lt;/b&gt; to something like &lt;b&gt;xxx-ipmi&lt;/b&gt; but it does not seem that useful anyway&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;Enter the &lt;i&gt;LAN User Configuration&lt;/i&gt; menu:&lt;ul&gt;
&lt;li&gt;Set &lt;b&gt;Account User Name&lt;/b&gt; to some login&lt;/li&gt;
&lt;li&gt;Enter a password in &lt;b&gt;Enter Password&lt;/b&gt; and again below in &lt;b&gt;Confirm Password&lt;/b&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;By the way, while you&amp;#39;re there, you may enter &lt;i&gt;LCD Configuration&lt;/i&gt; and set your user-defined string in &lt;b&gt;LCD Line 1&lt;/b&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;
IPMI is now configured correctly. You should be able to ping the IPMI IP addresses for the master node (assuming you properly enabled the 10.0.99.x network there).
&lt;/p&gt;
&lt;pre&gt;
    $ ping 10.0.99.x
&lt;/pre&gt;

&lt;p&gt;
Now, you may for instance reboot a node using the following line. Replace &lt;tt&gt;cycle&lt;/tt&gt; with &lt;tt&gt;status&lt;/tt&gt; to see the status, &lt;tt&gt;off&lt;/tt&gt; to shutdown, &lt;tt&gt;on&lt;/tt&gt; to start.
&lt;/p&gt;
&lt;pre&gt;
    $ ipmitool -I lan -H 10.0.99.x -U login -P passwd chassis power cycle
&lt;/pre&gt;

&lt;p&gt;
Now we need to configure console redirection. It makes it possible to send the BIOS, GRUB, and kernel output through IPMI on the network. Note that the Second Serial port should be used. So usually you will use COM2/ttyS1. After booting, press &lt;b&gt;F2&lt;/b&gt; to enter the BIOS. Go in the &lt;i&gt;Serial Communication&lt;/i&gt; menu:
&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Set &lt;b&gt;Serial Communication&lt;/b&gt; to &lt;b&gt;On with Console Redirection via COM2&lt;/b&gt;&lt;/li&gt;
&lt;li&gt;Keep &lt;b&gt;External Port Address&lt;/b&gt; to &lt;b&gt;Serial Device1=COM1,Serial Device2=COM2&lt;/b&gt; (some models enforce Device2 for the serial redirection)&lt;/li&gt;
&lt;li&gt;Set &lt;b&gt;External Serial Connector&lt;/b&gt; to &lt;b&gt;Serial Device1&lt;/b&gt; (some models don&amp;#39;t allow using the same device here and for console redirection)&lt;/li&gt;
&lt;li&gt;Keep &lt;b&gt;Failsafe Baud Rate&lt;/b&gt; to &lt;b&gt;115200&lt;/b&gt;&lt;/li&gt;
&lt;li&gt;Keep &lt;b&gt;Remote Terminal Type&lt;/b&gt; to &lt;b&gt;VT100/VT220&lt;/b&gt;&lt;/li&gt;
&lt;li&gt;Set &lt;b&gt;Redirection After Boot&lt;/b&gt; to &lt;b&gt;Enabled&lt;/b&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;
With this configuration, you should see the BIOS and GRUB output remotely using:
&lt;/p&gt;
&lt;pre&gt;
    $ ipmitool -I lanplus -H 10.0.99.x -U login -P password sol activate
&lt;/pre&gt;

&lt;p&gt;
Then we want to see the kernel booting remotely. This is done by adding the following to the kernel command line:
&lt;/p&gt;
&lt;pre&gt;
    console=tty0 console=ttyS1,115200n8
&lt;/pre&gt;

&lt;p&gt;
With GRUB2 on Debian, you should open &lt;tt&gt;/etc/default/grub&lt;/tt&gt; and add these options to &lt;tt&gt;GRUB_CMDLINE_LINUX&lt;/tt&gt;. By the way, you probably want to uncomment &lt;tt&gt;GRUB_TERMINAL=console&lt;/tt&gt; and remove the &lt;tt&gt;quiet&lt;/tt&gt; option nearby. Everything will be propagated to &lt;tt&gt;/boot/grub/grub.cfg&lt;/tt&gt; when running &lt;tt&gt;update-grub&lt;/tt&gt;.
&lt;/p&gt;

&lt;p&gt;
And finally, you might want to get a console login remotely through IPMI. To do so, add the following line to /etc/inittab:&lt;/p&gt;
&lt;pre&gt;
    T0:23:respawn:/sbin/getty -L ttyS1 115200n8 vt100
&lt;/pre&gt;

&lt;p&gt;
With all this setup, the above &lt;tt&gt;ipmitool sol activate&lt;/tt&gt; 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 &lt;b&gt;~&lt;/b&gt; is the control character when using the console redirection. And &lt;b&gt;~.&lt;/b&gt; may be used to leave the console. Also &lt;tt&gt;ipmitool sol deactivate&lt;/tt&gt; may help if somebody did not leave the console correctly.
&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Update for R815 (2012/05/30):&lt;/b&gt;
The configuration for the R815 is very similar. I met some harder constraints about serial device configuration in the BIOS, everything is already explained above.
&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Update for R720 (2012/05/31):&lt;/b&gt;
On recent PowerEdge models, the IPMI config is directly available in the BIOS setup menus, no need to hit Ctrl-e during boot anymore. Just go in the BIOS with F2 as usual, then enter the iDRAC config. The following menus are similar to those described above.

The other difference is that the R720 doesn&amp;#39;t seem to work well with the IPMI &lt;t&gt;lan&lt;t&gt; interface. Always passing &lt;t&gt;lanplus&lt;/t&gt; instead of &lt;t&gt;lan&lt;/t&gt; to &lt;t&gt;ipmitool -I&lt;/t&gt; seems to work fine.&lt;/t&gt;&lt;/t&gt;
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/20464.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;) &lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/20464.html?view=comments#comments</comments>
  <category>linux</category>
  <category>ipmi</category>
  <lj:security>public</lj:security>
  <lj:reply-count>1</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/20039.html</guid>
  <pubDate>Sun, 02 May 2010 12:23:24 GMT</pubDate>
  <title>Encrypting part of /home</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/20039.html</link>
  <description>&lt;p&gt;
I am preparing my switch to a new laptop at work in the next weeks. I am considering adding encryption to part of the hard drive, but I don&apos;t want to dramatically decrease performance. Encrypting the swap device or some .foo directories in $HOME looks like a good idea to protect private keys, keyrings, ... But encrypting git clones of large projects is probably useless.
&lt;/p&gt;

&lt;p&gt;
So I am thinking of just having a small /home encrypted partition (a couple GB). I&apos;d keep .foo directories in $HOME and only have symlinks to another non-encrypted partition where all my actual source code and other non-sensitive files would be.
&lt;/p&gt;

&lt;p&gt;
Does this make any sense?
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/20039.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/20039.html?view=comments#comments</comments>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>10</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/19868.html</guid>
  <pubDate>Mon, 22 Mar 2010 10:37:35 GMT</pubDate>
  <title>Debian/X.org notes - Radeon KMS in unstable, enabled by default</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/19868.html</link>
  <description>&lt;p&gt;
Now that we have DRM from 2.6.33 in latest 2.6.32 kernel in unstable, I just uploaded Radeon KMS and DRI2 to unstable. xserver-xorg-video-radeon 1:6.12.192-2 even &lt;b&gt;enables KMS by default&lt;/b&gt;. Please test it.
&lt;/p&gt;

&lt;p&gt;
In case of problems, you may for instance disable KMS by changing modeset to 0 in /etc/modprobe.d/radeon-kms.conf. You may also downgrade to testing where xserver-xorg-video-radeon 1:6.12.6-1 does not enable/support KMS.
&lt;/p&gt;

&lt;p&gt;
Make sure you run linux-image-2.6.32-4-$arch or later so that you actually have DRM from 2.6.33 and the radeon kernel module gets loaded early by udev. Otherwise, you may experience problems like &lt;a href=&quot;http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569332&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;this&lt;/a&gt;.
You may need to add radeon to /etc/modules as a temporary fix.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/19868.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/19868.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>17</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/19624.html</guid>
  <pubDate>Sun, 07 Mar 2010 12:00:01 GMT</pubDate>
  <title>Debian/X.org notes - Bug triaging while waiting for DRM 2.6.33</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/19624.html</link>
  <description>&lt;p&gt;
Almost nothing interesting happened recently in X.org in Debian.
But interesting things are coming soon.
&lt;/p&gt;

&lt;br /&gt;

&lt;p&gt;
First, radeon KMS and DRI2 will enter unstable soon.
xserver-xorg-video-radeon 1:6.12.191-1 is currently in experimental.
People seem to be happy with it so far,
and upstream is taking very good care of bug reports as usual.
&lt;/p&gt;
&lt;p&gt;
The next 2.6.32 kernel will contain DRM from 2.6.33.
It first means that the radeon KMS driver not in staging anymore.
Once this new kernel is uploaded, I&apos;ll put the new xserver-xorg-video-radeon
in unstable (6.13.0 is expected soon, but 6.12.191 already looks good so far).
&lt;/p&gt;
&lt;p&gt;
DRM from 2.6.33 will also brings nouveau support.
It means that we will build libdrm-nouveau and upload a new xserver-xorg-video-nouveau.
However, it also means that we need somebody to maintain this.
And nobody in the team has a nvidia board to test packages so...
&lt;b&gt;If you want nouveau in Debian, please help.&lt;/b&gt;
&lt;/p&gt;

&lt;br /&gt;

&lt;p&gt;
While waiting for all these, we have been triaging the BTS a bit.
Kibi is helping a lot by triaging recent intel bugs (many regressions fixed in recent kernels).
I spent some time during the week-end triaging some old bugs.
I closed more than a hundred of them, and pinged another hundred.
We still have more than 1100 bugs open.
It is not so bad compared to 1500-2000 when nobody maintains X (aka often), but still way too much.
&lt;/p&gt;
&lt;p&gt;
Some of my bug closing might look a bit rude.
But we had so many bug reports a couple years ago that are irrelevant today. 
Keeping them open would be meaningless.
For instance, many input problems are obsolete since a lot of the input code was rewritten, we switched to input-hotplug, and then hal to udev.
Another example is intel lockups (we had a lot of them after driver 2.2 arrived). But XAA and EXA were dropped in favor of UXA, DRI1 was dropped for DRI2, and KMS arrived.
So it&apos;s useless to keep these obsolete and irrelevant bugs that cannot be debugged nowadays.
&lt;/p&gt;

&lt;br /&gt;

&lt;p&gt;
As usual, the Debian X team needs a lot of help.
Again, &lt;b&gt;if you want nouveau in Debian, please help.&lt;/b&gt;
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/19624.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/19624.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>5</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/19346.html</guid>
  <pubDate>Mon, 01 Feb 2010 23:13:07 GMT</pubDate>
  <title>Debian/X.org notes - Radeon KMS and DRI2 in experimental</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/19346.html</link>
  <description>&lt;p&gt;
Now that libdrm-radeon1 is in unstable, I just uploaded a snapshot of the radeon driver to experimental (xserver-xorg-video-radeon package version 1:6.12.99+git20100201.a887818f-1). So you may now get KMS and DRI2 working, assuming you have a recent kernel (I am running 2.6.32-trunk-686 here). This driver even contains some early support for r8xx boards.
&lt;/p&gt;

&lt;p&gt;
To check whether KMS is working, look for &lt;em&gt;radeon kernel modesetting&lt;/em&gt; in dmesg. To check whether DRI2 is working, look for DRI2 in /var/log/Xorg.0.log.
&lt;/p&gt;

&lt;p&gt;
Make sure the radeon kernel module is loaded early (which means: don&apos;t let X load it late in the boot, otherwise you may experience &lt;a href=&quot;http://bugs.freedesktop.org/show_bug.cgi?id=25607&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;this bug&lt;/a&gt;). I had to add &lt;b&gt;radeon&lt;/b&gt; to &lt;tt&gt;/etc/modules&lt;/tt&gt; and put &lt;b&gt;options radeon modeset=1&lt;/b&gt; in &lt;tt&gt;/etc/modprobe.d/&lt;/tt&gt;. In the past, I also needed agpmode=-1 there but it didn&apos;t seem to make any difference with latest packages.
&lt;/p&gt;

&lt;p&gt;
Then, actual DRI2 support requires Mesa packages rebuilt against libdrm-radeon1. This is in experimental as well now. Look for libgl1-mesa-dri and other Mesa packages version 7.7-3.
&lt;/p&gt;

&lt;p&gt;
Don&apos;t forget that these packages are in experimental for a good reason, they may not work. But at least basic things seem to work fine on my Radeon X300 (rv370). And don&apos;t forget that the X team needs help, otherwise these packages may never make it to unstable...
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/19346.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/19346.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>18</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/18689.html</guid>
  <pubDate>Sat, 31 Oct 2009 12:23:33 GMT</pubDate>
  <title>Fun with SuperMicro BIOS and PCI-NUMA</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/18689.html</link>
  <description>&lt;p&gt;
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.
&lt;/p&gt;
&lt;pre&gt;
  ---------   ------------   ------------   ---------
  | Mem#0 |===| Socket#0 |===| Socket#1 |===| Mem#1 |
  ---------   ------------   ------------   ---------
                   ||             ||
               -----------   -----------
               | IOHub#0 |===| IOHub#1 |
               -----------   -----------
                   ||             ||
                 GPU#0         GPU#1+2
&lt;/pre&gt;
&lt;p&gt;
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:
&lt;/p&gt;
&lt;pre&gt;
  $ 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
&lt;/pre&gt;
&lt;p&gt;
However, this is wrong since 0,2,4,6,8,10,12,14 means &lt;em&gt;near socket #0&lt;/em&gt; 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&apos;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.
&lt;/p&gt;

&lt;br /&gt;

&lt;p&gt;
The first BIOS upgrade (from 1.0 to 1.0b) went kind of bad: the machine didn&apos;t boot anymore at all, not even any BIOS message on screen. Fortunately, we removed the GPUs and it booted again. But Linux didn&apos;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.
&lt;/p&gt;
&lt;p&gt;
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&apos;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.
&lt;/p&gt;

&lt;br /&gt;

&lt;p&gt;
So we had to try upgrading again, and make sure NUMA wasn&apos;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!
&lt;/p&gt;
&lt;pre&gt;
  $ 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
&lt;/pre&gt;
&lt;p&gt;
You might have noticed that CPU numbering changed in the meantime (CPU number interleaving is different), but I don&apos;t care since we have hwloc (&lt;a href=&quot;http://www.open-mpi.org/projects/hwloc/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Hardware Locality&lt;/a&gt;) to deal with it. Now the development version of our lstopo tool reports the whole machine topology, including PCI, as expected:
&lt;/p&gt;
&lt;div align=&quot;center&quot;&gt;
 &lt;a href=&quot;http://pics.livejournal.com/bgoglin/pic/00002zb7&quot; target=&quot;_blank&quot;&gt;
  &lt;img src=&quot;https://pics.livejournal.com/bgoglin/pic/00002zb7&quot; width=&quot;326&quot; fetchpriority=&quot;high&quot; /&gt;
 &lt;/a&gt;
&lt;/div&gt;

&lt;br /&gt;

&lt;p&gt;
In short, if you have a X8DAH motherboard, don&apos;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).
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/18689.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/18689.html?view=comments#comments</comments>
  <category>pci</category>
  <category>linux</category>
  <lj:security>public</lj:security>
  <lj:reply-count>2</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/18559.html</guid>
  <pubDate>Sun, 13 Sep 2009 00:02:15 GMT</pubDate>
  <title>Debian/X.org notes - i865 fixed, Xserver 1.6 entering testing soon</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/18559.html</link>
  <description>&lt;p&gt;
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 &lt;a href=&quot;http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541307&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;#541307&lt;/a&gt;.
&lt;/p&gt;

&lt;p&gt;
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&apos;ll have to apply the &lt;a href=&quot;http://lists.freedesktop.org/archives/intel-gfx/2009-September/004122.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;patch&lt;/a&gt; or wait for an updated 2.6.31.x kernel to be released. &lt;/p&gt;

&lt;p&gt;
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&apos;ll likely experience lockups soon after X startup.
&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Update:&lt;/b&gt; If building the intel-agp driver as a module, you will also need &lt;a href=&quot;http://lists.freedesktop.org/archives/intel-gfx/2009-September/004128.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;another small patch&lt;/a&gt; to export the &lt;tt&gt;clflush_cache_range()&lt;/tt&gt; function to modules.
&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Update:&lt;/b&gt; Everything just entered testing for real.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/18559.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/18559.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>6</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/18277.html</guid>
  <pubDate>Mon, 27 Jul 2009 07:29:34 GMT</pubDate>
  <title>Debian/X.org notes - Quick Updates</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/18277.html</link>
  <description>&lt;p&gt;
Another round of quick notes about X in unstable while
the XSF team is on vacation.
&lt;/p&gt;

&lt;p&gt;&lt;i&gt;&lt;u&gt;
&lt;b&gt;Intel Driver and PAE kernels&lt;/b&gt;
&lt;/u&gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
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:
&lt;/p&gt;
&lt;pre&gt;
  (EE) intel(0): [drm] Failed to detect GEM.  Kernel 2.6.28 required.
  (EE) intel(0): Failed to become DRM master.
&lt;/pre&gt;
&lt;p&gt;
Obviously, 2.6.30 should be enough when 2.6.28 is required. But 2.6.30 with PAE is not.
&lt;/p&gt;

&lt;p&gt;&lt;i&gt;&lt;u&gt;
&lt;b&gt;Return of the DRI2 breakage&lt;/b&gt;
&lt;/u&gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
It looks like the DRI2 breakage in Xserver 1.6.1.901-3 wasn&apos;t enterily
fixed in 1.6.2.
According to &lt;a href=&quot;http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538637&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;#538637&lt;/a&gt;,
Xserver 1.6.2 didn&apos;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.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/18277.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/18277.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>3</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/17951.html</guid>
  <pubDate>Tue, 21 Jul 2009 14:48:55 GMT</pubDate>
  <title>Debian/X.org notes - Intel 2.8.0 in Sid, enforces UXA and DRI2</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/17951.html</link>
  <description>&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
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 &lt;a href=&quot;http://people.debian.org/~bgoglin/rebuilds/Xserver1.6/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;here&lt;/a&gt;) and switch away from UXA.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/17951.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/17951.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>12</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/17871.html</guid>
  <pubDate>Mon, 13 Jul 2009 23:02:01 GMT</pubDate>
  <title>Debian/X.org notes - DRI2 fixed in unstable, and more</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/17871.html</link>
  <description>&lt;p&gt;
A couple news from the mostly-offline X Strike Force team:
&lt;/p&gt;

&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
Intel driver 2.7.99.902 has landed in experimental as well.
&lt;/p&gt;

&lt;p&gt;
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&apos;re playing with kernel modesetting, upgrading to kernel 2.6.31 and latest intel driver in experimental is probably a good idea as well.
&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Update:&lt;/b&gt; Intel driver 2.7.99.902 is broken when NOT using Kernel Modesetting,
see &lt;a href=&quot;http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537052&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;#537052&lt;/a&gt;.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/17871.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/17871.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>7</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/17612.html</guid>
  <pubDate>Mon, 11 May 2009 07:08:41 GMT</pubDate>
  <title>Debian/X.org notes - Why some X drivers like firmware-linux</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/17612.html</link>
  <description>&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
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&apos;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.
&lt;/p&gt;

&lt;p&gt;
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 &lt;a href=&quot;http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523467#88&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;bug#523467&lt;/a&gt;
for an example.
&lt;/p&gt;


&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/17612.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/17612.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>4</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/17395.html</guid>
  <pubDate>Sat, 14 Feb 2009 09:45:45 GMT</pubDate>
  <title>Debian/X.org notes - Howto get DRI2 on Debian?</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/17395.html</link>
  <description>&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
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 :)
&lt;/p&gt;

&lt;p&gt;
Enable the new UXA acceleration architecture with
&lt;tt&gt;Option &quot;AccelMethod&quot; &quot;UXA&quot;&lt;/tt&gt; 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!
&lt;/p&gt;

&lt;p&gt;
Well, on my i945, Compiz was very slow by default.
I add to disable &lt;i&gt;Sync to-VBlank&lt;/i&gt; in the display settings
in Compiz&apos; general options.
If you don&apos;t want Compiz, you may also try running
&lt;tt&gt;xcompmgr&lt;/tt&gt; and then play with &lt;tt&gt;transset&lt;/tt&gt;
to put transparency on 3D applications.
&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Update:&lt;/b&gt;
Added kernel requirements, added how to make Compiz not slow, removed -a from xcompmgr.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/17395.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/17395.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>12</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/16916.html</guid>
  <pubDate>Sat, 14 Feb 2009 09:34:28 GMT</pubDate>
  <title>Debian/X.org notes - X behavior changes in experimental</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/16916.html</link>
  <description>&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
 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&apos;s disabled by default now.
To reenable it, add to the ServerFlags section of your xorg.conf:
&lt;pre&gt;
        Option &quot;DontZap&quot; &quot;off&quot;
&lt;/pre&gt;
&lt;/p&gt;

&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
Finally, you might also see &lt;tt&gt;glxgears&lt;/tt&gt;
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&apos;s it.
But it has nothing to do with DRI or 3D being slow.
Please try some relevant 3D programs or benchmarks before
complaining :)
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/16916.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/16916.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>8</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/16734.html</guid>
  <pubDate>Sat, 24 Jan 2009 21:07:16 GMT</pubDate>
  <title>Debian/X.org notes - Howto Input-hotplug?</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/16734.html</link>
  <description>&lt;p&gt;
I have been wondering for a while how to get X.org &quot;input-hotplug&quot;
to work, but I never actually tried before today.
It is actually fairly easy, once you know what to do.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Requirements&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
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).
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Telling hal what to do with input devices&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
Now, you need to tell hal how to configure your input devices.
Actually, you do not have much to do since latest
&lt;tt&gt;xserver-xorg-input-evdev&lt;/tt&gt; packages bring what you need.
hal reads all &lt;em&gt;fdi&lt;/em&gt; files under &lt;tt&gt;/usr/share/hal/fdi/policy&lt;/tt&gt;
to find out how devices should be configured.
If you run &lt;tt&gt;lshal&lt;/tt&gt; and look for &lt;em&gt;input&lt;/em&gt;, you should
see that the evdev is planned to drive your input devices.
&lt;/p&gt;

&lt;p&gt;
However, if you look at keyboard devices in lshal (look for &lt;em&gt;input.keys&lt;/em&gt;),
you will see that the US layout is used.
To switch to another layout, you can add some overriding rules
as a new &lt;tt&gt;*.fdi&lt;/tt&gt; file in &lt;tt&gt;/etc/hal/fdi/policy/&lt;/tt&gt;.
For instance, to get French layout:

&lt;pre style=&quot;margin-left: 24px; font-size: 80%;&quot;&gt;
&amp;lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&amp;gt;
&amp;lt;deviceinfo version=&quot;0.2&quot;&amp;gt;
  &amp;lt;device&amp;gt;
    &amp;lt;match key=&quot;info.capabilities&quot; contains=&quot;input.keys&quot;&amp;gt;
      &amp;lt;-- Enforce XkbLayout=fr and XkbVariant empty --&amp;gt;
      &amp;lt;merge key=&quot;input.xkb.layout&quot; type=&quot;string&quot;&amp;gt;fr&amp;lt;/merge&amp;gt;
      &amp;lt;merge key=&quot;input.xkb.variant&quot; type=&quot;string&quot; /&amp;gt;
    &amp;lt;/match&amp;gt;
  &amp;lt;/device&amp;gt;
&amp;lt;/deviceinfo&amp;gt;
&lt;/pre&gt;
&lt;/p&gt;

&lt;p&gt;
Thanks to this, you can enforce XkbLayout, XkbVariant and friends
as usual in &lt;tt&gt;/etc/X11/xorg.conf&lt;/tt&gt;.
Don&apos;t forget to restart hal after modifying some fdi files.
Then run &lt;tt&gt;lshal&lt;/tt&gt;, 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 &lt;tt&gt;lshal&lt;/tt&gt; and find something
like a hardware identifier to match on.
&lt;/p&gt;

&lt;p&gt;
You can find some documentation about these rules by looking at the
existing fdi files in &lt;tt&gt;/usr/share/hal/fdi/policy/20thirdparty/&lt;/tt&gt;,
and in the upstream
&lt;a href=&quot;http://cgit.freedesktop.org/xorg/xserver/plain/config/x11-input.fdi&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;x11-input.fdi&lt;/a&gt; (note that &lt;tt&gt;input.xkb.foo&lt;/tt&gt; is the actual recommended syntax instead of &lt;tt&gt;input.x11_options.XkbFoo&lt;/tt&gt;).
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Touchpads&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
If you have a touchpad and want to use the synaptics driver,
installing the &lt;tt&gt;xserver-xorg-input-synaptics&lt;/tt&gt; will bring
another fdi file.
&lt;tt&gt;/usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi&lt;/tt&gt;
matches &lt;em&gt;input.touchpad&lt;/em&gt; 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 &lt;tt&gt;/etc/hal/fdi/policy/&lt;/tt&gt;
and you can add many configuration options for synaptics as well.
See &lt;tt&gt;/usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi&lt;/tt&gt;
to get an example.
&lt;/p&gt;

&lt;p&gt;
Fortunately, you will not have to manually take care of the
above &lt;tt&gt;/etc/hal/fdi/policy/&lt;/tt&gt; 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.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Telling the Xserver to talk to hal&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
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 &lt;tt&gt;InputDevice&lt;/tt&gt; sections and all references
to them within other sections.
With recent Xserver versions, options &lt;tt&gt;AllowEmptyInput&lt;/tt&gt;
and &lt;tt&gt;AutoAddDevices&lt;/tt&gt; are enabled by default
(otherwise, you might have to add them in the &lt;tt&gt;ServerFlags&lt;/tt&gt;
section).
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Ignoring a device&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
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:
&lt;pre style=&quot;margin-left: 24px; font-size: 80%;&quot;&gt;
  &amp;lt;match key=&quot;info.product&quot; contains=&quot;myname&quot;&amp;gt;
    &amp;lt;remove key=&quot;input.x11_driver&quot;/&amp;gt;
  &amp;lt;/match&amp;gt;
&lt;/pre&gt;
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;For more information&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
For more documentation, you want to read
&lt;a href=&quot;http://who-t.blogspot.com/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Peter Hutterer&apos;s blog&lt;/a&gt;,
especially
&lt;a href=&quot;http://who-t.blogspot.com/2008/07/input-configuration-in-nutshell.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;this post&lt;/a&gt;
and
&lt;a href=&quot;http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;this one&lt;/a&gt;.
&lt;/p&gt;

&lt;p&gt;
By the way, if you don&apos;t want this input-hotplug thing and you
want to run a recent Xserver anyway, you should set &lt;tt&gt;AllowEmptyInput&lt;/tt&gt;
and &lt;tt&gt;AutoAddDevices&lt;/tt&gt; to off in the &lt;tt&gt;ServerFlags&lt;/tt&gt; section.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Update:&lt;/u&gt;&lt;/b&gt;
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&apos;s comments.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/16734.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/16734.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>0</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/16547.html</guid>
  <pubDate>Sat, 24 Jan 2009 20:59:53 GMT</pubDate>
  <title>Debian/X.org notes - Xserver 1.6, Intel 2.6.1, ... what&apos;s up in XSF?</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/16547.html</link>
  <description>&lt;p&gt;
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&apos;s freeze, everything is happening in
experimental these days.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Xserver 1.6&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
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&apos;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&apos;s getting close for real.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Radeon 6.10.0 and Intel 2.6.1&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
Radeon driver 6.10.0 was released in early 2009.
As usual, it brings many fixes, and improvements for modern
boards (see
&lt;a href=&quot;http://www.botchco.com/agd5f/?p=34&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Alex Deucher&apos;s blog&lt;/a&gt;
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.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;DRI2&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
DRI2 is the new Direct Rendering Infrastructure.
The most noticeable change from the user point of view is support
for &lt;em&gt;Redirect Direct Rendering&lt;/em&gt;, which basically means
that your 3D application can be wobbly/transparent in Compiz.
See &lt;a href=&quot;http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Kristian Høgsberg&apos;s blog&lt;/a&gt;
for details.
&lt;/p&gt;

&lt;p&gt;
If you want to try DRI2 on Intel, you have to enable UXA
as the acceleration architecture in xorg.conf
(&lt;tt&gt;Option &quot;AccelMethod&quot; &quot;UXA&quot;&lt;/tt&gt; 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.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Kernel Modesetting&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
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&apos; 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&apos;t have
to change it later independently).
&lt;/p&gt;

&lt;p&gt;
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&apos;t get KMS to work on 2.6.29-rc2 here.
Again only Intel will support KMS soon, but other drivers
will follow.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Panning is back (aka RandR 1.3)&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;
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.
&quot;Panning&quot; (often referred to as &quot;Virtual Desktop&quot;) 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&apos;ll need the latest libxrandr2 and xrandr utilities to
do so (the latter is not uploaded yet).
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/16547.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/16547.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>14</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/16319.html</guid>
  <pubDate>Tue, 29 Jul 2008 17:29:05 GMT</pubDate>
  <title>MMU notifiers brings into Linux what we&apos;ve been wanted for HPC for a while</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/16319.html</link>
  <description>&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
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&apos;t intercept anything. So I wrote a patch called VMASpy which allowed other subsystems to be notified when part of a &quot;registered&quot; VMA is unmapped or forked. I never submitted it since it couldn&apos;t be accepted unless somebody in the kernel (i.e. IB) used it. Given &lt;a href=&quot;http://lists.linuxcoding.com/kernel/2005-q2/msg10051.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;posts like this&lt;/a&gt;, we see that IB people weren&apos;t conscious of the problem (nowadays they are interested but something in the IB specs apparently prevents them from using this).
&lt;/p&gt;

&lt;p&gt;
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.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/16319.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/16319.html?view=comments#comments</comments>
  <category>linux</category>
  <category>myri</category>
  <category>hpc</category>
  <lj:security>public</lj:security>
  <lj:reply-count>3</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/16043.html</guid>
  <pubDate>Tue, 29 Jul 2008 16:55:32 GMT</pubDate>
  <title>myri10ge broken in 2.6.26, will be fixed in 2.6.26.1</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/16043.html</link>
  <description>&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
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&apos;s tarball, take the driver from 2.6.27-rc1 or from 2.6.25, ... or just not use 2.6.26 :)
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/16043.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/16043.html?view=comments#comments</comments>
  <category>linux</category>
  <category>myri</category>
  <lj:security>public</lj:security>
  <lj:reply-count>0</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/15638.html</guid>
  <pubDate>Sun, 22 Jun 2008 12:52:05 GMT</pubDate>
  <title>Debian/X.org notes - xserver-xorg-video-radeon in unstable</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/15638.html</link>
  <description>&lt;p&gt;
 As you may now, the r128 and mach64 drivers were split out of ati recently. However, for Etch-&amp;gt;Lenny transitional reasons, xserver-xorg-video-ati still depends on xserver-xorg-video-r128 and -mach64. If you&apos;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.
&lt;/p&gt;

&lt;p&gt;
 xserver-xorg-video-ati still exists, for transitional reasons. It also provides the &quot;ati&quot; meta-driver which takes care of loading &quot;mach64&quot;, &quot;r128&quot; or &quot;radeon&quot; depending on your hardware. If you actually remove xserver-xorg-video-ati, don&apos;t forget to update your xorg.conf into Driver &quot;radeon&quot;.
&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Update:&lt;/b&gt;
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.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/15638.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/15638.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>2</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/15598.html</guid>
  <pubDate>Sat, 14 Jun 2008 11:36:16 GMT</pubDate>
  <title>Debian X.org notes - X.org in Lenny (and more)</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/15598.html</link>
  <description>&lt;p&gt;&lt;b&gt;&lt;u&gt;Xserver 1.4.2 for Lenny&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;XaaNoOffscreenPixmaps by default&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;ATI 6.8.191, Intel 2.3.2, Mesa 7.0.3++&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
Apart from the server, some big components are getting updated these days:
&lt;/p&gt;

&lt;p&gt;
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.
&lt;/p&gt;

&lt;p&gt;
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&apos;s only a
release candidate.
&lt;/p&gt;

&lt;p&gt;
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&apos;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.
&lt;/p&gt;

&lt;p&gt;
On the Intel side, a new 2.3.2 is expected soon, without many big improvements from what I have seen.
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;X.org post-Lenny Future&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
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&apos;t
need the whole Mesa source anymore (the GLcore module that AIGLX uses will be
built/shipped within Mesa).
&lt;/p&gt;

&lt;p&gt;&lt;b&gt;&lt;u&gt;Stop build-depending on xutils!&lt;/u&gt;&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
Also, we&apos;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-&amp;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&apos;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.
&lt;p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/15598.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/15598.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>3</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/15162.html</guid>
  <pubDate>Sun, 02 Mar 2008 14:57:00 GMT</pubDate>
  <title>Debian X.org notes - Radeon Textured Xvideo in experimental, r128 and mach64 split out</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/15162.html</link>
  <description>&lt;p&gt;
 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 &lt;tt&gt;xserver-xorg-video-ati&lt;/tt&gt; package only contains the &lt;tt&gt;radeon&lt;/tt&gt;
 subdriver. The other subdrivers have been moved to their own &lt;tt&gt;xserver-xorg-video-r128&lt;/tt&gt;
 and &lt;tt&gt;-mach64&lt;/tt&gt; packages. All of them just landed in experimental.
&lt;/p&gt;

&lt;p&gt;
 Your existing xorg.conf should work as before. I don&apos;t have any Mach or Rage
 board, so please test these new packages and report back if they don&apos;t work.
 Note that if your xorg.conf contains &lt;tt&gt;Driver &quot;ati&quot;&lt;/tt&gt;, you&apos;ll need to
 keep &lt;tt&gt;xserver-xorg-video-ati&lt;/tt&gt; installed. If you only have the &lt;tt&gt;mach64&lt;/tt&gt;
 or &lt;tt&gt;r128&lt;/tt&gt; package installed, you need switch to &lt;tt&gt;Driver &quot;mach64&quot;&lt;/tt&gt;
 or &lt;tt&gt;&quot;r128&quot;&lt;/tt&gt; in xorg.conf.
&lt;/p&gt;

&lt;p&gt;
 On the &lt;tt&gt;radeon&lt;/tt&gt; side, the upstream developers are still very active. The
 last feature that has been added is &lt;em&gt;Textured Xvideo&lt;/em&gt;. 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.
&lt;/p&gt;

&lt;p&gt;
 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&apos;t considered stable enough yet.
 To enable it, you can use something like:
&lt;pre&gt;
    mplayer -vo xv:port=74 foo.avi
&lt;/pre&gt;
&lt;/p&gt;

&lt;p&gt;
 Where do I get this port 74 from? Just look at the output of &lt;tt&gt;xvattr&lt;/tt&gt;
 or &lt;tt&gt;xvinfo&lt;/tt&gt;:
&lt;pre&gt;
    $ 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: &quot;ATI Radeon Video Overlay&quot;
      number of ports: 1
      port base: 73
      [...]
     Adaptor #1: &quot;Radeon Textured Video&quot;
      number of ports: 16
      port base: 74
      [...]
&lt;/pre&gt;
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/15162.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/15162.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>3</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/15063.html</guid>
  <pubDate>Sat, 19 Jan 2008 10:15:38 GMT</pubDate>
  <title>Debian X.org notes - No, DisplaySize and DPI are not (always) broken</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/15063.html</link>
  <description>&lt;p&gt;
 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.
&lt;/p&gt;

&lt;p&gt;
With a default config, RandR 1.2 drivers will basically associate the unique Monitor section with their first output, even if not enabled. Bug &lt;a href=&quot;http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461501&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;#461501&lt;/a&gt; is a good example of this issue.
&lt;/p&gt;

&lt;p&gt;
 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 &quot;Foo&quot; connected on output &quot;BAR&quot;, then you want the following in your Device section:
&lt;pre&gt;
    Option &quot;Monitor-BAR&quot; &quot;Foo&quot;
&lt;/pre&gt;
&lt;/p&gt;

&lt;p&gt;
 Or (easier), just rename identifier &quot;Foo&quot; into &quot;BAR&quot;. 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 &lt;a href=&quot;http://wiki.debian.org/XStrikeForce/HowToRandR12&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;HowToRandR12&lt;/a&gt; sections III.1 and III.3 for details.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/15063.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/15063.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>0</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/14593.html</guid>
  <pubDate>Sun, 06 Jan 2008 12:28:24 GMT</pubDate>
  <title>Debian X.org notes - One year of X.org BTS maintenance</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/14593.html</link>
  <description>&lt;p&gt;
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 &lt;a href=&quot;http://ftp.es.debian.org/~ender/XSF_bugs/graphs/total-year.png&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Ender&apos;s graph&lt;/a&gt; (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&apos;s not that easy unfortunately...
&lt;/p&gt;

&lt;p&gt;
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&apos;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&apos;t upgrade to unstable, ...
&lt;/p&gt;

&lt;p&gt;
I am sometimes tired of getting so many bugs without being able to do much about them. Maybe because upstream doesn&apos;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&apos;s very nice and easy to work with them.
&lt;/p&gt;

&lt;p&gt;
Of course, we have a lot of work and few people to do it. That&apos;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&apos;t seem to look fun. If you&apos;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 :)
&lt;/p&gt;



&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/14593.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/14593.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>0</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://bgoglin.livejournal.com/14265.html</guid>
  <pubDate>Fri, 21 Dec 2007 08:13:10 GMT</pubDate>
  <title>Debian X.org notes - ATI 6.7.197 in unstable, AtomBIOS r500/600 support in experimental</title>
  <author>bgoglin</author>
  <link>https://bgoglin.livejournal.com/14265.html</link>
  <description>&lt;p&gt;
 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.
&lt;/p&gt;

&lt;p&gt;
 Things are (again) moving fast upstream. Right after the 6.7.197 released, they merged 2 important branches in master:
 &lt;ul&gt;
 &lt;li&gt;
  &lt;b&gt;atombios-support&lt;/b&gt; 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 &lt;a href=&quot;http://airlied.livejournal.com/53129.html&quot; target=&quot;_blank&quot;&gt;Dave Airlie&apos;s blog entry&lt;/a&gt;.
 &lt;/li&gt;
 &lt;li&gt;
  &lt;b&gt;zaphod-lolz&lt;/b&gt; 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 &lt;a href=&quot;http://airlied.livejournal.com/54069.html&quot; target=&quot;_blank&quot;&gt;Dave Airlie&apos;s blog entry&lt;/a&gt; for some details.
 &lt;/li&gt;
 &lt;/ul&gt;
&lt;p&gt;

&lt;p&gt;
 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!
&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Update:&lt;/b&gt;
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.
&lt;/p&gt;

&lt;div align=&quot;right&quot;&gt;(&lt;a href=&quot;http://bgoglin.livejournal.com/14265.html&quot; target=&quot;_blank&quot;&gt;Permanent link&lt;/a&gt;)&amp;nbsp;&lt;/div&gt;</description>
  <comments>https://bgoglin.livejournal.com/14265.html?view=comments#comments</comments>
  <category>debian</category>
  <category>xorg</category>
  <category>planet.d.o</category>
  <lj:security>public</lj:security>
  <lj:reply-count>1</lj:reply-count>
  </item>
</channel>
</rss>
