As described in that URL "New configuration world order" there is already working support for udev backend and running Xorg without hal works OK again. I haven't found any hal fdi policy -> udev rules migrating script :/ But it wasn't so hard to migrate manually. Most tricky part was not to forget to add InputClass section to xorg.conf (without it are udev reported devices ignored and error about unspecified xorg driver is shown in log). Also ENV variable names I found somewhere were a bit different than what works for me (easiest to check in Xorg.0.log), so just in case I'll put my rules here as another example: ENV{ID_INPUT_KEYBOARD}=="?*", ENV{x11_driver}="evdev", ENV{xkblayout}="us,cz", ENV{xkbvariant}=",qwerty", ENV{xkboptions}="grp:alt_shift_toggle,grp:switch,compose:rwin,terminate:ctrl_alt_bksp" ENV{ID_INPUT_MOUSE}=="?*", ENV{x11_driver}="evdev" Hint for debuging rules: udevadm monitor --property and in 2nd terminal udevadm trigger --verbose --type=devices --subsystem-match=input and in 1st terminal you should see those ENV properties you prepared
Created attachment 219873 [details, diff] 0001-xorg-server-add-USE-flag-for-config-udev.patch Patch with added USE flag for x11 overlay
Hi Martin, your patch looks good, but i think we should also hard-disable the hal configuration. So if you would like to redesign the patch to work that way so i don't have to commit fix right after i apply it?
(In reply to comment #2) > Hi Martin, > your patch looks good, but i think we should also hard-disable the hal > configuration. So if you would like to redesign the patch to work that way so i > don't have to commit fix right after i apply it? udev and HAL support are exclusive in the server's configure.ac. IIRC, udev wins when both are enabled. Cheers
(In reply to comment #2) > Hi Martin, > your patch looks good, but i think we should also hard-disable the hal > configuration. So if you would like to redesign the patch to work that way so i > don't have to commit fix right after i apply it? With both forced as enabled it should fail in configure if test "x$CONFIG_UDEV" = xyes && { test "x$CONFIG_DBUS_API" = xyes || test "x$CONFIG_HAL" = xyes; }; then AC_MSG_ERROR([Hotplugging through both libudev and dbus/hal not allowed]) fi with HAL only as "auto", and udev USE flag enabled, UDEV will be used so you're right, we should make them mutually exclusive and Remi is right, that UDEV wins in "auto" and "yes" case. I don't remember how to make USE flags exclusive.. so feel free to change patch/commit fix. I'm also not really sure about "udev" USE name.. Thanks
See what i did in overlay. This bug is basicaly fixed. I will leave it open until we decide if we really want to kill hal completely :]
(In reply to comment #5) > See what i did in overlay. This bug is basicaly fixed. I will leave it open > until we decide if we really want to kill hal completely :] > Looks good to me, but I'm not sure that every overlay user is ready to migrate his custom fdi policy rules to udev rules. If you remove --disable-config-hal line, then hal stays default and only users with udev flag enabled, will have to migrate. With that line + without udev flag you have to put all config back to xorg.conf which is really going backwards.. Also the need for new Section in xorg.conf should be at least shown in ewarn with url how to migrate policy. I spent about an hour in terminal yesterday.. just because I forgot to add that InputClass and the error message looked more like unused udev rule to me..
Martin we might like to see your udev rules, so we can use them for examples in future. Wanna share them?
(In reply to comment #7) > Martin we might like to see your udev rules, so we can use them for examples in > future. +1. And yay, die hal die! BTW, (In reply to comment #6) > (In reply to comment #5) > Looks good to me, but I'm not sure that every overlay user is ready to migrate > his custom fdi policy rules to udev rules. Well, after my half day hal quest to make the old good DontZap False work with hal I'll more that happily move to whatever alternative. :P
Ok, I was kinda hoping to get this InCVS with 1.7.5.901, or did I get it wrong that this one's basically 1.8 RC?
(In reply to comment #9) > Ok, I was kinda hoping to get this InCVS with 1.7.5.901, or did I get it wrong > that this one's basically 1.8 RC? > Hi, 1.7.5.901 is 1.7.6 RC1 http://lists.freedesktop.org/archives/xorg/2010-March/049535.html 1.7.99.901 is 1.8 RC1 http://lists.freedesktop.org/archives/xorg/2010-February/049144.html Cheers,
Ah, OK... my fault, thanks for clarification ;) I guess I'll have to resort to the overlay stuff for a while then if I want to get rid of the -hal nightmare *g*
I just wanted to report that this works like a charm. ;) I didn't add any udev rules but created InputClass files /etc/xorg.conf.d/ Should udev rules finally bring us working non-root-X?
(In reply to comment #12) > I just wanted to report that this works like a charm. ;) > I didn't add any udev rules but created InputClass files /etc/xorg.conf.d/ Sure it works, if you're using defaults (or your DE is handling that for you), but for multiple layouts like I need to type our special national characters you need to "migrate" settings from xorg.conf or hal policy (.fdi) files. > Should udev rules finally bring us working non-root-X? AFAIK non-root-X is not related to udev rules or this whole udev xorg config.
(In reply to comment #13) > (In reply to comment #12) > > I just wanted to report that this works like a charm. ;) > > I didn't add any udev rules but created InputClass files /etc/xorg.conf.d/ > > Sure it works, if you're using defaults (or your DE is handling that for you), > but for multiple layouts like I need to type our special national characters > you need to "migrate" settings from xorg.conf or hal policy (.fdi) files. > > > Should udev rules finally bring us working non-root-X? > > AFAIK non-root-X is not related to udev rules or this whole udev xorg config. > Well, last time I tried NRX I was stuck without input. Thought udev rules would provide a way around that, but that's offtopic here. ;)
*** Bug 313269 has been marked as a duplicate of this bug. ***
*** Bug 311425 has been marked as a duplicate of this bug. ***
Wrote guide. See the URL. Needs review so we can make it into official space :]
It might not be obvious to all users that the "MatchIs*" rules are binary matches, and the other three substring. Otherwise imo, good job! ;)
This guide is actualy already official, we just forgot to close the bug :)
