1i5t5.duncan at cox.net
Fri Nov 13 22:00:00 GMT 2009
James Tyrer posted on Thu, 12 Nov 2009 04:45:35 -0700 as excerpted:
>> I'm on xorg-server-1.7.1, yes. But you could have something with the
>> input driver. I've been using the xf86-input-evdev driver (2.3.0
>> currently) for some months now. It's nice to be able to use the same
>> driver for both mouse and keyboard, for one thing. The switchover
>> to hal- autodetect was a bit rough, especially for keyboard as I had to
>> figure out how to tell hal to use the correct "inet/media" keyboard
>> instead of the default 101-key and that's not the friendliest thing in
>> the world to try to configure, but before that, I had it set in
>> xorg.conf, with Option "AllowEmptyInput" "no" set in the serverflags
>> section as well, so it wouldn't ignore the xorg.conf settings. That
>> worked fine.
> I need to upgrade Xorg. However, I am using PS/2 connected mouse and
> keyboard. Can I use xf86-input-evdev with non-USB input devices?
I believe so. Note that you need the kernel (I'm assuming Linux) evdev
driver enabled (that was the part I missed), and the devices are a bit
different, but it's possible to keep the standard kernel mouse driver
enabled as well, as I did, since gpm didn't seem to work with evdev. But
the kernel long ago combined the pointing device input frameworks under
what originally started out as USB based HID, with the /dev/input/mice
and /dev/input/mouseN devices actually being kernel based emulation of a
standard imps mouse device(s), translating whatever you actually use into
the standard. If you're still using /dev/psaux, you may well have some
extra upgrading to do, but that's /waaaayyy/ outdated by now.
The basic keyboard "just worked", but as I mentioned, I did have to
figure out how to setup hal to handle the extra keys on the Logitech
inet/media keyboard I have, tho even that wouldn't have been necessary
had I setup the evdev driver in xorg.conf and disabled xorg and hal's
autodetect, the "legacy" way of doing it.
 Since I run ~arch, the unstable/testing branch of Gentoo, and even
unmask packages to try before they hit ~arch sometimes, I'm often way out
in front of the documentation Gentoo prepares for stable users before the
new version goes stable, when it's a major upgrade like some of the xorgs
are. In this case, I had been running the newer xorg-server, but with
the "legacy" xorg.conf setup, for a couple months before I got around to
tackling the new setup. By this time, Gentoo was getting ready to
stabilize it and had a draft upgrade guide, which was the basis of most
of my upgrade research. However, at the time, it neglected to mention
that there was an evdev kernel driver to enable as well, so I spent
several hours screwing with hal configs and wondering why nothing would
work, when it was simply a missing kernel driver! So then while I was
doing something else for awhile, my subconscious had time to recall that
I'd seen a kernel menuconfig item for it, and sure enough, turn it on,
rebuild the kernel, reboot with the new driver, and it worked! Obviously
I filed a bug on the Gentoo upgrade doc right away, and they added a note
about the kernel driver requirement to their docs. =:^)
That's the sort of thing I /expected/ to be doing when I upgraded to
kde4. Unfortunately, despite all the claims about it being ready for
normal use by 4.2, that wasn't the case. There were /waaayyy/ too many
things still broken in kde 4.2 for it to be even late beta quality then,
tho it is now. More like alpha quality, then. Of course, I had a bit of
a clue as I had been trying to upgrade to it since before 4.0, but it was
even worse than I expected.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde