[luv-main] Keyboard lagging in X
I have a USB-serial cable connecting my laptop (running 2.6.39 from Debian) to a weather station. My keyboard is connected to a different USB port on the laptop. 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. 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. 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!). 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. I think this is only a recent occurence. Being my main desktop, I'm not ready to git bisect it yet, and don't know whether 2.6.39 brought this behaviour in. 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 (god knows why I upgraded. Oh yeah, squeeze. I should have learnt by now). -- Tim Connors
Hi. 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
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.
(Top-posting because quoting is apparently broken ...) Yargh, sorry. I've been forced on to my phone's mail client as the wifi in my laptop is dead. Didn't realise it was that broken. Cheers, Daniel On 14/09/2011, at 4:07 AM, Craig Sanders <cas@taz.net.au> wrote:
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. _______________________________________________ luv-main mailing list luv-main@lists.luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Wed, Sep 14, 2011 at 04:09:03AM -0500, Daniel Stone wrote:
(Top-posting because quoting is apparently broken ...)
better not to quote at all.
Yargh, sorry. I've been forced on to my phone's mail client as the wifi in my laptop is dead. Didn't realise it was that broken.
your wifi needs fixing. usb wifi is cheap :) and whoever thought that email clients on a phone would be a good idea ought to be shot. craig ps: yes, i have gmail and k9mail installed on my android phone. i rarely use them. i don't think i've sent even one msg using it. screen too small and virtual keyboard to painful for email. wd hv 2 dcrs my vrbsty. wrs, wrt lk n iltrt msylbic mrn. -- craig sanders <cas@taz.net.au> BOFH excuse #451: astropneumatic oscillations in the water-cooling
On Wed, 14 Sep 2011, Daniel Stone wrote:
Hi.
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.
Yep - pauses with evtest too. But again, only in X, not at the console. It also drops entire keystrokes instead of just lagging, at times.
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.
Just to be safe, I upgraded to kernel 3.0, and everything X related to debian unstable (so that's Version: 2:1.11.0-1 for xserver-xorg-core). And I moved over to Nouveau (damn frenchies. I can never spull that word correctly without consulting google-spull-correct) from nvidia. And I even deleted xorg.conf just to make sure everything is pulled in as default.
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 ...
Maybe my usbserial pl2303 device has daemons in it. My computers have... unique problems. The keyboard I had been using sometimes forgot to send the occasional keyup event. And indeed got confused as to whether a key was up or down. Replacing the keyboard at least fixed that problem. -- Tim Connors
On 18 September 2011 06:47, Tim Connors <tconnors@rather.puzzling.org> wrote:
On Wed, 14 Sep 2011, Daniel Stone wrote:
On 14/09/2011, at 3:38 AM, Tim Connors <tconnors@rather.puzzling.org> wrote: 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.
Yep - pauses with evtest too. But again, only in X, not at the console.
It also drops entire keystrokes instead of just lagging, at times.
Alright, that is indeed very much a kernel issue. It could be exacerbated by X; e.g. your GPU driver could be wedging for long enough that you miss a few interrupts -- something I have seen with nouveau previously. Try looking in dmesg for anything suspicious, or failing that, try the perf 'long IRQ handler' trace. Cheers, Daniel
On Wed, Sep 14, 2011 at 06:38:04PM +1000, Tim Connors wrote:
I have a USB-serial cable connecting my laptop (running 2.6.39 from Debian) to a weather station.
My keyboard is connected to a different USB port on the laptop. 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.
have you tried hard-coding your input devices into xorg.conf and telling X to not auto add/enable new devices? i used to have something very much like the following in my xorg.conf to prevent the scroll wheel from being enabled (before my game playing habit developed to the point where i decided that a working scroll wheel might suck in terminals but it's really bloody useful in games). note: reconstructed from commented out bits of crap in my xorg.conf, but reasonably close to a working config. or was reasonably close at some point in time. x has changed a lot in the last year or two. and the input layer has received a huge amount of attention. Section "ServerLayout" InputDevice "Generic Keyboard" InputDevice "Configured Mouse" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "Protocol" "Auto" Option "Device" "/dev/input/by-id/usb-Logitech_USB-PS_2_Optical_Mouse-mouse" EndSection Section "ServerFlags" Option "AllowEmptyInput" "false" Option "AutoAddDevices" "false" Option "AutoEnableDevices" "false" EndSection
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!).
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.
i have a USB serial converter. bought it cheap at a swap meet, figuring it might be a useful thing to have lying around...haven't used it yet. it's probably crap. I can probably dig up an old modem or something to have something for it to talk to. i can test it if you want. just plugged it in for the first time, it's a: Bus 008 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
(god knows why I upgraded. Oh yeah, squeeze. I should have learnt by now).
because upgrading is usually good. in the long run. btw, 2.6.39 is old and buggy. try 3.0 craig -- craig sanders <cas@taz.net.au> BOFH excuse #23: improperly oriented keyboard
Hi, On 14/09/2011, at 3:58 AM, Craig Sanders <cas@taz.net.au> wrote:
have you tried hard-coding your input devices into xorg.conf and telling X to not auto add/enable new devices?
i used to have something very much like the following in my xorg.conf to prevent the scroll wheel from being enabled (before my game playing habit developed to the point where i decided that a working scroll wheel might suck in terminals but it's really bloody useful in games).
FWIW, you can now use InputClass sections to apply options to hotplugged devices exactly as you can to statically-configured devices through xorg.conf. If you google for it, Peter Hutterer's blog has some examples. It's been around since xorg-server 1.9 or 1.10. Cheers, Daniel
On Wed, Sep 14, 2011 at 04:06:59AM -0500, Daniel Stone wrote:
FWIW, you can now use InputClass sections to apply options to hotplugged devices exactly as you can to statically-configured devices through xorg.conf.
neat. that's useful.
If you google for it, Peter Hutterer's blog has some examples. It's been around since xorg-server 1.9 or 1.10.
thanks. craig -- craig sanders <cas@taz.net.au> BOFH excuse #300: Digital Manipulator exceeding velocity parameters
participants (3)
-
Craig Sanders -
Daniel Stone -
Tim Connors