SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
You don'k now other consequenses. Group swich is not working and if youn unplug a USB mouse the server will crash, at least on my M6N. Reverted back to xorg-server-1.4.0-i486-2
This is a consequence of adding the input hotplug support - it ignores all your input device settings in xorg.conf, and expects you to configure them via HAL .fdi files.
I've e-mailed Pat and asked him to disable it by default (since it requires more configuration work from the end-user than I expected, and isn't very well documented yet - it will hopefully instead be available as an optional extra you can enable if you want to experiment with it).
For completeness sake - if you do actually want to use input hotplugging, you must:
A) Set the right locale in /usr/share/hal/fdi/policy/10osvendor if you are not using a US layout.
B) Make sure your window manager is not trying to override the keymap layout - either tell it not to set a keymap, or tell it to explicitly use evdev (if you set pc104 in your window manager, strange key remappings happen with evdev).
At first, some of my keyboard shortcuts didn't work unless I went into Xfce's settings manager and changed (or at least acted like I was going to change) one of them, and then they were fine until X was restarted.
Then I decided to futz with the /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi file (copy it to /etc/hal/fdi/policy/ and do the edits there) and that made it worse - no keyboard input was accepted at all. Of course, that means my edits were bad, but still, you get the idea
PiterPunk is also looking into this, and it seems that it's not an issue except on en_US layouts, but that might not be completely accurate either. Anyway, blacklisting the evdev module avoids the problem altogether here until a better fix is found, and it's being looked at to try and find the best way to handle it. Note that you'll have to reboot after adding the evdev module to the blacklist (either edit /etc/modprobe.d/blacklist, or create /etc/modprobe.d/evdev with one line that reads "blacklist evdev" - this is what I did, so it will be easier to see the custom change later).
Are you certain? Because the solution of just removing 10-x11-input.fdi works fine for both Debian & Ubuntu, who implemented it to disable input hotplugging by default.
Blacklisting evdev is, IMHO, overkill.
You could also try removing 10-keymap.fdi, since that also tries to call evdev and override the X layout.
Are you certain? Because the solution of just removing 10-x11-input.fdi works fine for both Debian & Ubuntu, who implemented it to disable input hotplugging by default.
Blacklisting evdev is, IMHO, overkill.
You could also try removing 10-keymap.fdi, since that also tries to call evdev and override the X layout.
Well, no, I'm not certain. I was trying to debug this a bit before all of this information was gathered in one place, so I was piecing together bits from various places trying to get a workable solution. I know I removed the 10-x11-input.fdi file from /usr/share, but now that I think a bit more about it, I just might have had a custom one in /etc/hal, and since the custom one obviously had other issues, that just might have been the problem. I'll try this again later tonight once my daughter drifts off to sleep and I have a bit of free time. I'd certainly like for it to work, as I completely agree that blacklisting evdev is not a good solution at all - too much other stuff depends on it.
Pat's posted the 'fix' (disabling HAL and D-Bus in xorg-server again), but to be honest, I'm a little disappointed; the solution is the worst of the three - blacklisting evdev or just removing a single file from HAL are far preferable to this (since neither of those require recompiling to enable input hotplugging).
Also, Pat's explanation is a bit odd - "Evidently, the HAL/D-Bus enabled X server, xf86-input-evdev, and one of HAL's .fdi files aren't playing well together."
AFAICT, they are all working fine and doing what they are supposed to do - the problem is just that the input hotplug is a bit immature, and most people aren't aware of how it works, and it is somewhat difficult to configure at the moment, so this line really doesn't sit well with me.
Are you certain? Because the solution of just removing 10-x11-input.fdi works fine for both Debian & Ubuntu, who implemented it to disable input hotplugging by default.
Blacklisting evdev is, IMHO, overkill.
You could also try removing 10-keymap.fdi, since that also tries to call evdev and override the X layout.
Oh..God! I spent too many hours trying to find an "elegant" way to do this on PCLinuxOS...and I think I've lost my sanity!! I have a multiseat setup...so I can't get rid of evdev (you need it for multiple independent inputs), but I can't exactly keep it when it borks the system in single-seat mode!
Eventually I just modified my /etc/init.d/dm to rmmod and modprobe evdev as required by the situation...meaning this multiseat setup has yet one more quirk (in addition to the other zillions like not being able to switch user on any but the first seat): no joysticks, etc... in single seat mode!
Ha ha ha ha ha ha ha ha ha ha ha!!! Bwaaaahahahahahahahaha!!! HAAAAA HAAAA HAAA HAAA HAAA HAAA HAA HAAA!!!! Oh God - this "hotplaguing" being crammed down everyone's throat is enough to make you jump ship and go back to using Windows where you expect that sort of thing! BWAAAAAAHAHAHAHAHAHAHAHA HA HA HA HA!! I think I'm tearing up from maniacal laughter here...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Ha ha ha ha ha!
