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.
Okay, I've been using Slackware for ages... since like 1997 or 1998. I have a Slackware 3.x CD around here somewhere. I'm usually the one explaining how Linux works to everyone else. I even got GnuCash working on Slackware. So these two problems are very frustrating...
1. Keyboard in Xorg. It seems to work, except the down arrow and the page down buttons are mapped as something else (the down arrow causes TEXT TO DISAPPEAR...I've had to type this like three times now...). After a bunch of searches, it looks like a problem with HAL and evdev (whatever that is). I tried setting the model in KDE's Regional control panel but that had no effect. Xorg.conf settings for this section... you can see some remnants from prior attempts:
I did check that event1 refers to the keyboard. The keyboard is a Microsoft Internet Keyboard that works fine; the arrow keys work great outside of X.
2. Mouse in Xorg. The scroll wheel wants to scroll side to side instead of up and down. This also happens to be a Microsoft product (I like their mice... my wife brought the Microsoft keyboard into the relationship...). It's just a wheel optical 3-button mouse, nothing special. Again, none of my usual xorg.conf edits seem to work; here's what I have right now.
Someone really should make an upgrade guide for people like me that have been using it for years and aren't really following the tech that explains new features like hal and evdev (I know hal has been around for a couple versions, but I've never gotten involved with it until now). Or maybe there is one and I'm just not aware of it. Basically I just want it to just work, which is why I use Slackware in the first place!
I should mention I did have both working under Slackware 13.1 on this machine until Windows conveniently erased my root partition for me, so I got to do a completely clean Slackware install for the first time in a LONG time. That's when the issue arose. Because I was in a rush, I did a full install. I assume the previous setup was using non-hal/non-evdev methods, but I might as well set this one up using the new methods, right?
I'm using Slackware64 13.1, running on a Core 2 Quad Q8300 @ 2.50 GHz. Hardware is fine - both mouse and keyboard work under Windows XP, and like I said the keyboard is fine outside X. It has to be some configuration problem ...somewhere.
Unless you're sure you need an xorg.conf (e.g. to load binary drivers from ATI or NVidia), you shouldn't have one. Try removing your xorg.conf file and letting X detect everything.
If you're using binary NVidia drivers, then see Zordrak's blog entry on setting them up under Slackware.
The changes and hints text on the DVD explains it more. But even if you have an ATI or NVidia card, you only need to define the card section of the xorg.conf. X uses hal to configure everything else.
I've done as that blog suggested, and I'm still having the problems. It's as if I didn't do anything at all (perhaps X was already ignoring those entries). I tried removing the xorg.conf file to verify X was reading it, and X failed to load, so apparently X is using that file at least in part. Here's what I have now:
This matches what I should have based on what I see in the blog. Any other suggestions?
Thanks.
Update: doing a "setxkbmap -model microsoftinet" seems to fix the problem with the keyboard (woohoo!). However, this didn't work, surprisingly...
rj@harper:~$ cat /etc/hal/fdi/policy/x11-input.fdi
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keyboard">
<merge key="input.x11_options.XkbModel" type="string">microsoftinet</merge>
</match>
</device>
</deviceinfo>
I did a /etc/rc.d/rc.hald restart to reload hal, and verified it restarted, and I thought that would be enough... (I should mention I've been restarting X after each attempt...)
It looks like my match statement in the x11-input.fdi file didn't work. Same goes for the mouse (I note that, hilariously, it knows the model of mouse, so in theory it could tell X that the ZAxisMapping should be 6 7...):
Any suggestions? The x11-input.fdi is readable by all, but I haven't see anywhere that indicated it had to be a certain permission setting.
Edit: Okay, so I figured out that you have to copy the 10-x11-input.fdi file to /etc/hal/fdi/policy and edit it to add the new features, and that does work. So now the two properties are showing up...but X isn't following them. Sigh.
Excerpt from /var/log/Xorg.0.log:
Code:
(II) config/hal: Adding input device AT Translated Set 2 keyboard
(**) AT Translated Set 2 keyboard: always reports core events
(**) AT Translated Set 2 keyboard: Device: "/dev/input/event1"
(II) AT Translated Set 2 keyboard: Found keys
(II) AT Translated Set 2 keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type:
KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "microsoftinet"
(**) Option "xkb_layout" "us"
(**) Option "xkb_options" "terminate:ctrl_alt_bksp"
So X is seeing the option...it's just ignoring it. Same goes for the mouse.
I'm still having this problem... Since the last post, I have:
--Updated all the software to the latest patches given on ftp.slackware.com
--Temporarily removed my .kde directory to see if that made a difference (no)
There are other things I've tried, but this is stupid. I have better things to do than screw around with this. If anyone has any suggestions, I'd like to hear them. In the meantime, I'm going back to using xorg.conf to configure X ... I know that actually works.
You have correctly identified that you have run into a HAL problem. For whatever the reasons, in some systems, HAL simply doesn't behave correctly. I had this same problem when I switched to 13.1. (I had my own thread on this back a number of months ago.) I found that HAL would read the data, then not transfer it. It would immediately deactive the mouse and keyboard. I found that, contrary to all those who tell you that you don't need an x-config file, I DID require one. At the end of the day, I finally "solved" the problem by effectively disabling HAL and passing the mouse and keyboard directly through the x-config. I "intended" to try to understand why HAL was acting like it was in the movie--but never got back to it after I "solved" the problem the "inelegant" way. Once I got things working, it wasn't the effort trying to troubleshoot HAL . . .
You have correctly identified that you have run into a HAL problem. For whatever the reasons, in some systems, HAL simply doesn't behave correctly. I had this same problem when I switched to 13.1. (I had my own thread on this back a number of months ago.) I found that HAL would read the data, then not transfer it. It would immediately deactive the mouse and keyboard. I found that, contrary to all those who tell you that you don't need an x-config file, I DID require one. At the end of the day, I finally "solved" the problem by effectively disabling HAL and passing the mouse and keyboard directly through the x-config. I "intended" to try to understand why HAL was acting like it was in the movie--but never got back to it after I "solved" the problem the "inelegant" way. Once I got things working, it wasn't the effort trying to troubleshoot HAL . . .
Good luck.
Rick
Thanks. That's pretty much what I found while searching - when it works, it's great, but for some people it just doesn't work, for no reason they can discern. In this case, I suspect HAL itself is working correctly, but Xorg just isn't taking its settings for some reason. (As I posted above Xorg is READING the settings - it's in the log file - but it's just not using them for some reason.)
Like you, I finally went back to the 'old' way of doing it, and I got both the keyboard and mouse working perfectly on the first try.
If HAL is working for other things, you may not want to disable it completely.
A note from the CHANGES_AND_HINTS.TXT on the install medium.
Quote:
If you prefer to do this the "old" way
using /etc/X11/xorg.conf, then you can use "X -configure" or "xorgsetup" to
generate an xorg.conf, then add the following lines to the "ServerFlags"
section to disable input device hotplugging via HAL:
Option "AllowEmptyInput" "false"
Option "AutoAddDevices" "false"
Option "AutoEnableDevices" "false"
This is also relevant if you prefer to disable HAL completely for whatever reason.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.