So I decided to get myself into real trouble again and jump ship onto X Server 1.8, with its RC2 just been released yesterday. With HAL axed and input detection moving to udev, I at least would have expected it to cause some trouble on first try. But guess what - it worked right from the beginning, including keymap stuff and such.

Update 02-04-10: As they say, X.Org Server 1.8.0 Is Here and was instantly added to the x11 overlay. Also, updated and generalised my xorg config quite a bit. Even if it runs stable on my system, issues are to be expected. I'll collect them at the end of this post.

Update 09-04-10: There have been several changes in the xorg-server-1.8.0.ebuild, one of them being a standard evdev catchall config file which should provide most users with a working standard environment (provided they use evdev which is recommended), and the default config path for Gentoo now residing in /etc/X11/xorg.conf.d. I guess users are suggested to put their custom configuration into /etc/X11/xorg.conf now.

Update 13-04-10: xorg-server-1.8.0, xorg-drivers-1.8, xinit-1.2.1-r1 are now all in Portage and not hardmasked anymore. I'd recommend to rebuild those as there have been changes to the ebuild again, possibly affecting your system.

Update 26-05-10: good news for ATI, bad ones still for Intel - see at the end of this post.

~arch users now don't have to unmask this version anymore, stable branch users though will have to put at least those into package.keywords, perhaps some more:

Code:

=x11-base/xorg-server-1.8.0
=x11-base/xorg-drivers-1.8

Now, you should definitely have set the following option in /etc/make.conf (among other ones, if you need), for evdev is the way to go for setting up input devices (whether they are joysticks, keyboards or mice...):

Code:

INPUT_DEVICES="evdev"

Notice the udev USE-flag (update-09-04-10: also -hal if you are pedantic):

Read the tight-lipped instructions here or in "man xorg.conf" for more detailed info to get your devices together.

Finally:

Code:

rc-update del hald default

Notice however, that many applications still need the hald daemon for hotplug detection such as KDE (in its current state, 4.4.2), e17, ...

Remember to run etc-update, it will seek to overwrite your old xdm config as well as init script (if there was any), don't forget to set your favourite login mgr again.

...and voilá! Next, it would be interesting to apply the non-root-X patches again and see if it gets me farther than just rendering kdm - without input - this time.

Known issues:

huge Intel issues - as of 15-05 and xorg-server-1.8.1, xrandr is still broken (especially during active compositing, less so after deactivating it) - including latest git version. Users (including me) report random freezes, screen corruption. Avoid it if you need a stable system, until there's a fix from Intel devs!

Thank you for sharing, but I will keep xorg-server 1.7.6 until they will make a non 9999 ebuild.
I am already quite satisfied with xorg-server 1.7.6, xf86-video-intel-2.10.903 and mesa 7.8_rc2 (finally desktop effects work again).
gma x4500 here too._________________Computers are like air conditioners:
they stop working properly when you open Windows...

ah that happens when you carelessly copy over config files. Fixed now. I didn't have time yet to keep evdev from trying to take over my Intel HDA or Lid Switch, but later this day..._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

I am now also using rc2 without the patch and it works, even though in here they say it still isn't fixed? I'm curious. EDIT: Well, different issue, different patch, and it seems to depend on some other variable still yet to be found._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

Last edited by asturm on Wed Mar 24, 2010 1:43 pm; edited 1 time in total

So, during the last two days I experienced
- one X freeze (which seems to have been related to firefox-win32 crashing wine)
- one plasma segfault (which needn't strictly be attributed to X)_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

what are the chances we can get gentoo's xorg-server-1.8 to ship with /etc/X11/xorg.conf.d/90-input-default.conf or something similar specifying the default evdev fallback? or better yet, have xf86-input-evdev supply this file. other drivers like xf86-input-synaptics could add their own config specifying the synaptics driver for applicable input classes.

im not sure how much we want ebuilds meddling with xorg configs, but w/ xorg.conf.d it makes it a lot easier to cleanly do so

I believe it's supposed to be precisely that way you described it, reading this:

Quote:

Note that the xorg.conf is parsed before the xorg.conf.d, hence it always has precedence. This allows for distributions to populate the xorg.conf.d directory with various quirks, yet still have user-specific configuration in the good old xorg.conf.

There are actually 3 ways for configuring input:

Quote:

- udev backend support
- Support for an xorg.conf.d configuration directory
- Support for matching rules in the xorg.conf

On a sidenote, I just discovered that, without hald, the phonon backend wouldn't detect any analogue inputs/outputs of my Intel HDA. _________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

ATI users: According to this thread (ebuild included!), Catalyst 10.4 should work with X Server 1.8!_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

If libudev is found, we use that for hotplug and disable the hal and
dbus backends.
We look for event devices with an "x11_driver" property. XKB
configuration happens using xkb{rules,model,layout,variant,options}
properties. Arbitrary driver options can be set with a "x11_options."
prefix.

It isn't yet released upstream, but xf86-video-intel-9999 more or less is it (and it works flawlessly)._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic