xorg-server-1.9 stabilisation

The time has come. We plan to break your systems. And as usual we need your cooperation in this. :)

As first I generated a nice list that contain all packages with the respective arches.

Now there is required a bit of your interaction if you want to test this on your stable system, you need to convert this list onto package.keywords file:

grep [myarch] x11_stable.list |cut -d' ' -f1 |sed -e 's:^:=:' > x11_stable_keywords.list

Please try such list on your stable system and let us know about all issues you encounter (also remember to read the xorg-server migration guide that is mentioned by elog information from the x11-base/xorg-server package).

I will try to update the list based on comments and write the time of last update for it so you can easily figure if you need to update your keywords.list or not :)

Current version: 2010/11/08

Note: xf86-input-synaptics driver is not managed by x11 team anymore and might need also keywording to latest testing version to work.

Bookmark the permalink.

30 Responses to xorg-server-1.9 stabilisation

  1. Anton says:

    Just in time. I’m experiencing a nasty freeze with 1.7.7 and chromium browser on an external monitor, so I guess it’s time to move on and fix it in the new version if it’s still affected.

    • scarabeus says:

      Not sure, since i am not aware of such bug, but might be worth the try since my external monitor + chromium won’t crash :)

      • Anton says:

        My box was consultancy crashing then I was trying to resize a chrominium-bin window on external monitor, 1920×1200; video-ati driver, gnome env. It seems fine now with 1.9 but resizing is still a bit slow, comparing with other standard windows. I’ll keep an eye on it.

        Other then that, the update was very smooth, no issues so far.
        Thanks for working on it!

  2. andrew says:

    Just updated a stable amd64 machine, and it went very well. I had to add synaptics to the list, as mentioned, but otherwise very smooth.

    • scarabeus says:

      Thanks, glad to hear, so no problems with undestadning xorg migration guide right? :)

  3. Paolo says:

    Is there a tracker bug for this?

    • scarabeus says:

      Now there is, I opened bug 344827.

      • Paolo says:

        Cool.

        Now some feedback: I just transitioned two machines and they both seem to be working quite nicely.

        One of the two is even running mesa-7.9 (with ati r300 gallium backend) and libX11-1.3.99.903 from X11 overlay, and it seem to be working better than ever.

        You might consider including libX11-1.4 when it is released upstream (it should be any day now).

  4. Jan says:

    Just upgraded from 1.8 to 1.9, it was rather painless.

  5. tholin says:

    I decided to try it out and got hit by this bug: http://bugs.gentoo.org/337055
    Upgrading to mesa-7.9 from the x11 overlay solved the problem. Might be something to keep in mind before the big migration.

  6. rullzer says:

    On my (more or less) stable amd64 laptop upgrading went smooth I had to add synaptics to the list but that was an easy fix.

    Other than that I also had to enable KMS for the intel driver but that was not really due to the xorg upgrade but more due to the driver update.

  7. Kevin Lyles says:

    I had to keyword version 3.2.10 of the virtualbox guest additions (and the related input and video drivers) before X worked in my virtual machine. I was using 3.2.8 with no issues prior to upgrading xorg-server.

    The exact packages:
    x11-drivers/xf86-video-virtualbox-3.2.10
    x11-drivers/xf86-input-virtualbox-3.2.10
    app-emulation/virtualbox-guest-additions-3.2.10

  8. Andrey Vihrov says:

    There should be

    elog

    , not

    einfo

    on lines 226-227 of

    xorg-server-1.9.2.ebuild

    , otherwise the message never gets logged to elog.

  9. mack1 says:

    Just upgraded on amd64 with hardened profile and all worked fine (also nouveau drivers!).

  10. papillon81 says:

    I also just tested it on a x86 machine. No problems, except that xset should be set to version 1.2.1 and not 1.2.0, which is no longer in portage :)

  11. Quizzlo says:

    No problem with update, just a note: the “sync” extension requires a kernel >=2.6.35 (on a pc with Radeon and KMS enabled).

  12. Dragos says:

    How’s one supposed to set the keyboard mapping now? Previously (1.7) it was hal, now I hear that there’s the xorg.conf.d/ stuff, however it’s either not working as advertised or I’m doing something wrong.
    Tried adding to /usr/share/X11/xorg.conf.d/10-evdev.conf (of course @ the keyboard section) and I can see it being picked up in Xorg.0.log, but the keyboard is completely dead once X (gdm) starts. I had to boot using nox and modified the file back to it’s original form. You want me to open a ticket or that?

    thanks, Dragos

    • Dragos says:

      probably due to uninspired quoting the quoted text gone missing; here’s a second try:
      Tried adding ‘Option “xkb_layout” “uk”‘ to /usr/share/X11/xorg.conf.d/10-evdev.conf …

      • scarabeus says:

        Did you really really read the guide we propagate in elog messages? :)

        There is described how to configure keyboard, and i am particulary sure it is explicit about using /etc/ and leaving /usr alone :)

        • Dragos says:

          touche! I meant to but in the 72 long list of updates xorg-server wasn’t the last one, so by I not seening it when checked for completion I simply lost track of it.
          As for the /etc/xorg.conf.d stuff, I looked for it, but there was no /etc/xorg.conf.d dir (I would have expected an empty one), so I thought maybe there should be none; creating an empty one did not made the xorg server print the location in the log as it is done for the /usr/share/X11 one…

          anyway, complaining aside, I will go through the upgrade document you mentioned. Everything else looks good. thanks, dragos

          • Dragos says:

            I have the following snippet in the /etc/xorg.conf.d/97-evdev.conf:

            Section “InputClass”
            Identifier “keyboard-all”
            Driver “evdev”
            Option “XkbLayout” “uk”
            # Option “XkbVariant” “,qwerty”
            # Option “XkbOptions” “grp:alt_shift_toggle,grp:switch,compose:rwin,terminate:ctrl_alt_bksp”
            MatchIsKeyboard “on”
            EndSection

            as soon as gdm starts the keyboard is completely dead; Xorg.0.log shows it picking up the option (but it has some weird stuff after that which is missing otherwise and might explain the deadness):
            [ 67.748] (**) Option “xkb_rules” “evdev”
            [ 67.748] (**) Option “xkb_model” “evdev”
            [ 67.748] (**) Option “xkb_layout” “uk”
            [ 103.643] (II) Power Button: Close
            [ 103.643] (II) UnloadModule: “evdev”
            [ 103.647] (II) Sleep Button: Close
            [ 103.647] (II) UnloadModule: “evdev”
            [ 103.657] (II) Logitech USB-PS/2 Optical Mouse: Close
            [ 103.657] (II) UnloadModule: “evdev”
            [ 103.665] (II) AT Translated Set 2 keyboard: Close
            [ 103.665] (II) UnloadModule: “evdev”
            [ 103.681] (II) SynPS/2 Synaptics TouchPad: Close
            [ 103.681] (II) UnloadModule: “evdev”
            [ 103.697] (II) TPPS/2 IBM TrackPoint: Close
            [ 103.697] (II) UnloadModule: “evdev”
            [ 103.705] (II) ThinkPad Extra Buttons: Close
            [ 103.705] (II) UnloadModule: “evdev”

            this is on a Thinkpad T60, 32 bit gentoo, 2.6.35, kms, radeon.

        • Dragos says:

          d’oh, finally figured it out. Reviewing the hal fdi that was previously in charge of setting the keyboard layout revealed that the proper value is “gb”. Confusingly enough, “uk” is valid when defining the console keyboard layout in /etc/conf.d/keymaps.
          The xserver behavior could be better in the presence of invalid keyboard layout; a warn/error message in the log would have been extremely helpful.

  13. knecht says:

    I upgraded to xorg 1.9 to fit the requirements of intels 2010Q3 driver package:
    http://intellinuxgraphics.org/2010Q3.html

    maybe we should also add libva-1.0.5, mesa-7.9 and cairo-1.10 to the list and stablelize this packages too. Intel GMA HD chips are often used nowadays and a stable xorg-server 1.9 should be work well with intel chips (in my opinion)

    libva-1.0.5 has no ebuild in portage, i used this one:
    http://bugs.gentoo.org/show_bug.cgi?id=336854

    Everything works well here with the versions mentioned by 2010Q3 and kernel 2.6.35-r12.

  14. BAReFOOt says:

    Hmm, I already used 1.9 when it was -9999. ;)
    Plus -9999 mesa, and ati driver.
    It’s impressive how completely stable and reliable live versions of those packages run.
    I’m thankful for every day where I don’t have to use fglrx! ^^

  15. The_Docter says:

    I also needed to upgrade to mesa-7.9 as otherwise this bug: https://bugs.gentoo.org/show_bug.cgi?id=347217 hit me. However after this upgrade (and eselecting the proper mesa driver) KWin OpenGL Compositing works nicely and also way smoother than with xorg 1.7

  16. The_Docter says:

    Correction: I meant this bug: https://bugs.gentoo.org/show_bug.cgi?id=337055