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?
- RandR 1.3: Panning, transforms (fixing projector keystones, etc.), primary outputs
- Xinput 1.5, including input device properties
- Predictable pointer acceleration
- DRI2
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.
Striving for greatness 
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.
greeetings
Karl
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?
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
The easiest way is to start with an existing fdi file that does something similar.
http://osdir.com/ml/fedora-extras-commits/2009-02/msg04579.html looks on the right track.
good morning Donni !
i already followed that link an did end up at :
http://cvs.fedora.redhat.com/viewvc/devel/linuxwacom/10-linuxwacom.fdi?view=markup&pathrev=linuxwacom-0_8_2_2-5_fc11
but – the question is – how to get a workaround to the momentuos unability of hal to manage more then just the one device on the same dev.
So at the momen one could say – better to have the pen working then nothing and forget about eraser and pad. I think WACOM will have to solve the problem also.
So what i meant with was pointing at this problem of HAL/xorg/dev.
Maybe you know any adress to go on with this.
thanks so long
Karl
PS. please shout at me if you think this is just taking your time. Honestly. I know there is a lot waiting for you and i wont start any flaming.
What will happen if hald will not be running while using evdev? Wouldn’t it stop mouse/keyboard from working?
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.
Forcing recompile of everything? Is that really a problem, since we’re running Gentoo? 😉
We’re used to it!
For some reason I cannot log into bugzilla. Those files are missing (but simply coping works):
x11-drivers/xf86-input-evdev/xf86-input-evdev-2.1.3.ebuild
x11-drivers/xf86-video-ati/xf86-video-ati-6.11.0.ebuild
x11-libs/libXi/libXi-1.2.1.ebuild
x11-libs/pixman/pixman-0.14.0.ebuild
PS. Thanks for clearing issue with evdev. I know that the hald have notifications but it does not mean xorg use it…
What do you mean by missing? I just synced my tree and I have all of those files.
Sorry. They were missing from x11 overlay as they hit main tree.
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….
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.
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.
Predictable pointer acceleration is in 1.5. I’ve been using it for months 😛
I update the overlay today and make a terible mess in my system because /usr/lib64/libxcb-xlib.la desaperar.
First I can’t go back because compilers fails complainin about missing libxcb-xlib.la, 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?
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.
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 libxcb-xlib.la.
revdep-rebuild won’t help as the problem is with libtool ‘library’ – not shared library itself.
This week I need the laptop so I can’t investigate. This weekend I retry I make a complete log.
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.
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.
Easier way of doing it (and safer): revdep-rebuild –library ‘.*xcb.*’
It looked to me like revdep-rebuild wouldn’t fix *.la files when passed a –library argument.
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).
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).
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 ‘libxcb-xlib.la’ | sed ‘s/:.*$//g;’`; do equery b -e $la | grep ‘[^\[]’; done | awk ‘{print “>=”$0}’)
I tried today and I succed 🙂
Using xcb-rebuilder.sh 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?
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 🙂
For some unknown reason, there’s still no upstream release of x11-apps/xrandr that actually works.
That did happen now, didn’t it?
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.
Without sounding too pushy, but what is soon?
Is it worth the wait, or should I go for the overlay?
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)