4.3.3 bugs

[Duncan]

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[1]), 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.

....
[1] 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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.