On Wed, Sep 14, 2011 at 03:50:28AM -0500, Daniel Stone wrote:
[stuff that is mixed in indistinguishably from stuff that Tim wrote]
your mail client is broken. or, at least, its quotation settings are misconfigured. it may *look* OK to you if you're viewing the text/html version, but the text/plain version created by your mail client is failing to prefix quoted material with a > (or anything else). please fix. this is what it looks like in a text/plain mail reader. you might be able to because you wrote some of it, but i can't tell where Tim's words stop and yours begin, not without going back and reading the original mail - which kind of defeats the purpose of quoting: On 14/09/2011, at 3:38 AM, Tim Connors <tconnors@rather.puzzling.org> wrote: Whenever the met software is reading and/or writing to the serial port (I haven't yet debugged whether it only happens during read or write), the keyboard badly lags when in X, but not at the console. I don't *think* the mouse is affected, most of the time, unless X is waiting for the keyboard to catch up. Very weird indeed. X doesn't do anything fancy with its keyboard handling there and in fact we don't even know that it's USB: we just process the events as we get them. Does running evtest on the keyboard device (which you can find through /var/log/Xorg.0.log or /proc/bus/input/devices) show the same lag? If so - definitely a kernel issue. I'm apparently using the evdev driver. In xorg.conf, synaptics is configured for the mouse, talking on /dev/psaux, and not as core pointer. corekeyboard and coremouse are left as default. The 'core' options are all meaningless now, BTW. So now, given the bloat (sorry, abstraction) that has been thrown at X/HAL/udev over the last few years, where do I start debugging this one? (friggin give me back XFree86 and a keyboard driver understood by more than 3 people on the damn planet!). Eh, HAL was a mistake for sure but the rest has been hugely beneficial. Including moving away from the nonsense kbd driver which was full of crap special-case hacks and no-one actually understood, to evdev which is entirely tractable. :) HAL support isn't being used and udev has no role beyond device discovery: after that, we just open() the /dev/input/eventN node directly. Can anyone else reproduce this? You probably don't need a USB-serial converter. It's probably just some conflict reading things from /dev/input/* or in the kernel TTY layer or something, and so any old serial connection busily talking will do it. Nope, not on any kernel from ~2.6.32 through to 3.1rc. I use a USB-serial converter all the time and it works just fine. It could have been back in April: [UPGRADE] xserver-xorg 1:7.6~2 -> 1:7.6+6 [UPGRADE] xserver-xorg-core 2:1.7.7-11 -> 2:1.9.5-1 [UPGRADE] xserver-xorg-input-evdev 1:2.6.0-1 -> 1:2.6.0-2 [UPGRADE] xserver-xorg-input-kbd 1:1.4.0-2 -> 1:1.6.0-1 As I said, we just process the events as the kernel sends them to us and don't even know the keyboard's a USB device. So if the delivery changes based on USB activity, I'd be looking very, very firmly at the kernel ... Cheers, Daniel _______________________________________________ luv-main mailing list luv-main@lists.luv.asn.au http://lists.luv.asn.au/listinfo/luv-main craig -- craig sanders <cas@taz.net.au> BOFH excuse #109: The electricity substation in the car park blew up.