Striving for greatness

Thoughts on emerging tech, open source, and life

Xorg-server 1.6 preview in Gentoo’s x11 overlay

To compete with Remi’s post about getting xorg-server 1.5.3 stable in Gentoo, here’s one about getting xorg-server 1.6, which was released today, into testing in the main tree. We’ve been maintaining the 1.6 release candidates in the x11 overlay for a while now. Tonight I added the final release to the overlay. (Update for Google users) What’s new in 1.6, you ask?

What’s left before it can move to the main tree? Here’s what I can think of, offhand:

  • The new XRandR stuff needs to get released upstream (randrproto, libXrandr, xrandr). Right now we’ve got the xrandr userland tool depending on live git of libXrandr, which won’t work for the main tree. (Update: randrproto and libXrandr 1.3 are out, just waiting on the userland tool xrandr)
  • We need to sort out the issue with XCB’s Xlib library renaming forcing recompiles of practically everything. This is becoming more and more of a blocker because now libXext 7.0.5 requires a new libX11. I think giving ourselves a hard blocker on 1.6 from this will help us get it fixed. See bug #248743 to track progress on this. (Update: solution in x11 overlay for testing)
  • The server now has a fix to keep looking for HAL if it’s not running when started. Should we change /etc/init.d/xdm to compensate for this change by no longer depending on hald, thus allowing gdm/kdm/etc to start earlier? This will give us one of the steps taken by the fastboot work seen lately in Moblin and elsewhere.
  • I think Remi’s going to add xf86-video-intel 2.6.2. (Update: done)
  • Our xinit is crazy stale, mainly because we patch it like crazy and I don’t like porting those. I’d like to get it updated to a current release for 1.6. In the longer term, we need to merge distro-neutral parts of our work upstream, but that’s not a 1.6 blocker.

To sum up, you can try xorg-server 1.6 now by adding the x11 overlay with layman, or you can wait for the above issues to get solved, and it will show up soon in testing in your main tree.


Written by Donnie Berkholz

February 26, 2009 at 12:09 am

Posted in Blog

Tagged with , ,

33 Responses

Subscribe to comments with RSS.

  1. Hi Donnie !
    i am working with 1.5.3 for some month now and i am still hitting main problems after updating to kernel-2.6.28. It’s not just beqause of all the trouble with the intel driver and 865G chipset – and this is hard enough, so i can’t into 28 cause no way to start X.
    It’s also cause some insolveble problems with fdi-files.
    We need to have a running Intuos3 Tablet. No way either to find any solution to start this properly with all features enabled. So if 1.6 is depending on HAL and not recognising a AutoAddDevices” “false” we are stuck.
    So that would say – if as announced – 1.5 development would stop in favor of 1.6 and the intel-problem there can’t be solved, there might be some time we not able to do our work.

    Karl Ernst Brunk

    February 26, 2009 at 2:41 am

    • Karl,

      If you have a Linux driver at all for your tablet, you can set options for it in the FDI file when using input hotplugging. Are you having trouble figuring out how exactly to do that?

      Donnie Berkholz

      February 26, 2009 at 8:47 am

      • Thanks for reply Donni,
        i really do have problems to firgure that out. I am searching a lot, but up to right now not one site was giving an advice that really worked. Trial and error with the xorg-docs about fdi-tags took and takes hours but its not satisfying. So i would appreciate any hint which couldt get me closer to a solution of a working pen,pad,and eraser with hal.
        The linuxwacom-driver is working well. So what should i read or try with that.
        The crashing intel(865G)/dri2/2.6.28/(UXA/EXA) – problem is another story and will probably be resolved by another Board.
        Thanks a lot for your great work

        Karl Ernst Brunk

        February 26, 2009 at 2:11 pm

  2. What will happen if hald will not be running while using evdev? Wouldn’t it stop mouse/keyboard from working?


    February 26, 2009 at 3:38 am

    • Uzytkownik,

      Correct, input hotplugging will not work until hald starts. The change I suggest would be a matter of seconds, not minutes. Chances are, by the time you’ve actually logged into your X session, hald will be started.

      Donnie Berkholz

      February 26, 2009 at 8:47 am

  3. Forcing recompile of everything? Is that really a problem, since we’re running Gentoo? 😉

    We’re used to it!


    February 26, 2009 at 3:39 am

  4. For some reason I cannot log into bugzilla. Those files are missing (but simply coping works):

    PS. Thanks for clearing issue with evdev. I know that the hald have notifications but it does not mean xorg use it…


    February 26, 2009 at 8:23 am

    • What do you mean by missing? I just synced my tree and I have all of those files.

      Donnie Berkholz

      February 26, 2009 at 8:46 am

      • Sorry. They were missing from x11 overlay as they hit main tree.


        February 26, 2009 at 9:51 am

  5. Forcing anyone upgrading libxcb to rebuild everything which got “polluted” with libxcb seems like the easiest and cleanest method…

    …certainly works and doesn’t require much hackery. 😛

    Btw; it seems that many updated packages required by the x11 overlay’s xorg-server ebuild aren’t needed, 1.6.0 appears to work fine with earlier versions of said packages….


    February 26, 2009 at 8:33 am

  6. I couldn’t understand why upgrading libxcb would require anything other than upgrading Xlib, until I saw the note in the bug about –as-needed and realized that Gentoo might not use –as-needed by default. That would make things suck, yes. 🙂 You really want to do that, because absolutely nothing other than Xlib should have any dependency on libxcb-xlib.


    February 27, 2009 at 8:40 am

    • Yeah, basically there are a lot of broken packages out there, and we tend to go with the approach of “fix it all right the first time” rather than working around problems by stripping –as-needed from specific packages.

      Donnie Berkholz

      February 27, 2009 at 10:06 am

  7. Predictable pointer acceleration is in 1.5. I’ve been using it for months 😛


    March 2, 2009 at 2:42 pm

  8. I update the overlay today and make a terible mess in my system because /usr/lib64/ desaperar.

    First I can’t go back because compilers fails complainin about missing, etc. revdep-rebuild didn’t help. I have to remove the overlay, recompile libX11 and others and then downgrade libxcb to 1.1 to complete the “update”.

    Packages broken until I give up:

    kipi-plugin, gtk, freeglut, xf86-video-intel.

    It is normal? should I report to bugzilla?


    March 8, 2009 at 12:27 pm

    • I’m not sure why revdep-rebuild didn’t work for you. We would need more details about what exactly happened when you tried it — which packages were rebuilt, etc.

      Donnie Berkholz

      March 8, 2009 at 1:44 pm

      • I had the same problem. AFAIK the reason may be simple. The broken packages (well – as in source packages not gentoo packeges) referes to the

        revdep-rebuild won’t help as the problem is with libtool ‘library’ – not shared library itself.


        March 8, 2009 at 2:14 pm

      • This week I need the laptop so I can’t investigate. This weekend I retry I make a complete log.


        March 9, 2009 at 4:45 am

    • Are you running portage-2.2*? If so preserved libs can break things for you. It did for me, makeing many apps failing to start (somthing WRT symbols) and revdep-rebuild to fail since the .so-files still are there.

      I removed the libs by hand and ran revdep-rebuild.


      March 10, 2009 at 10:34 am

      • I don’t use preserved-libs because this options broke things in my system in the past (I think I had enable 2 days at most… ) I don’t think it left files in my system, but who kwons.


        March 10, 2009 at 11:04 am

      • Easier way of doing it (and safer): revdep-rebuild –library ‘.*xcb.*’


        March 10, 2009 at 11:41 am

        • It looked to me like revdep-rebuild wouldn’t fix *.la files when passed a –library argument.

          Donnie Berkholz

          March 10, 2009 at 11:47 am

          • Well. Basicly la files have nothing in common AFAIK with runtime linking. All it do is to “help” linking using linking.

            revdep-rebuild uses ldd which checks if shared libraries (lib.*\.so) are present and valid and therefore if program can be loaded (althought it does not check the symbols table only NEEDED entries). la on the other hand are used only during linking by libtool – not during runtime on modern *nixes (correct me if I’m wrong).


            March 10, 2009 at 11:58 am

            • Update: I finally understood what you mean. However broken .la files is build issue not runtime (i.e. lack of or broken .la file on moder *nix should not prevent running app – only building it).


              March 10, 2009 at 12:16 pm

          • It is far from being perfect but this one-line may help (at least it seems help me):
            emerge -av $(for la in `ls /usr/lib/*.la | xargs grep ‘’ | sed ‘s/:.*$//g;’`; do equery b -e $la | grep ‘[^\[]’; done | awk ‘{print “>=”$0}’)


            March 12, 2009 at 12:38 pm

  9. I tried today and I succed 🙂

    Using I recompile 10 packages and seems that all is working now.

    PS: I think 10 packages is not a lot of packages to rebuild, maybe this is because am I ussing –as-needed?


    March 12, 2009 at 1:15 pm

  10. How does it look with the progress, is there any estimate how long it will take before xserver 1.6 reaches ~x86? It has already been one month 🙂


    March 29, 2009 at 3:19 pm

    • For some unknown reason, there’s still no upstream release of x11-apps/xrandr that actually works.

      Donnie Berkholz

      March 31, 2009 at 9:38 pm

      • That did happen now, didn’t it?


        April 2, 2009 at 11:09 pm

        • Yep. I expect to add 1.6 soon. The XCB rebuilding script is OK, and the only other thing I’m thinking about is some xinit changes.

          Donnie Berkholz

          April 3, 2009 at 1:51 pm

  11. Without sounding too pushy, but what is soon?
    Is it worth the wait, or should I go for the overlay?


    April 8, 2009 at 7:53 am

  12. Will nouveau also make it into x11 overlay (in near future)?
    (A note in driver ebuilds supporting KMS would be a nice bonus, supporting as not conflicting with KMS or not touching GPU registers behind KMS’s back)


    April 30, 2009 at 1:56 pm

Comments are closed.

%d bloggers like this: