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.
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.
Not sure, since i am not aware of such bug, but might be worth the try since my external monitor + chromium won’t crash :)
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!
Just in case if somebody hit the same problem:
it’s x11-drivers/xf86-video-ati driver.
The version 6.13.x and above uses EXA by default which cases the freeze. There are number of bug reports with same symptoms opened currently, here is one of them:
https://bugs.freedesktop.org/show_bug.cgi?id=23660
We really need that KMS guide before we stabilise this :)
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.
Thanks, glad to hear, so no problems with undestadning xorg migration guide right? :)
Is there a tracker bug for this?
Now there is, I opened bug 344827.
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).
Just upgraded from 1.8 to 1.9, it was rather painless.
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.
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.
Hmm this looks like we will need to write KMS guide too :)
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
There should be
, not
on lines 226-227 of
, otherwise the message never gets logged to elog.
Just upgraded on amd64 with hardened profile and all worked fine (also nouveau drivers!).
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 :)
No problem with update, just a note: the “sync” extension requires a kernel >=2.6.35 (on a pc with Radeon and KMS enabled).
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
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 …
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 :)
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
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.
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.
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.
forgot to mention, here you can find the /etc/xorg.conf.d/ files i use with xorg-server-1.9 (german, nvidia and intel graphics):
http://www.neoberserker.de/phpBB3/viewtopic.php?f=13&t=2132&start=0
(someone maybe find them useful)
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! ^^
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
Correction: I meant this bug: https://bugs.gentoo.org/show_bug.cgi?id=337055