|
|
| Line 1: |
Line 1: |
| <pre>
| | Most evdev bugs aren’t actually evdev bugs. they tend to get caught before the releases. They’re either configuration issues (HAL, usually) or server bugs. especially when it comes to keyboard layouts etc., it’s nearly always server. |
| [08:17:45] whot!porky.stuttgart.redhat.com: "spanked"? that bad?
| | |
| [08:22:07] whot!porky.stuttgart.redhat.com: hmm. we need to find some middle ground for triaging on the bug errors. I spent a lot of time telling users the same things over and over (hal configuration, etc.). now i'm so flat out I hardly get to look at bugreports, and there's a lot that just need attention but not really fixing
| | Also, there are almost no <code>xorg-x11-drv-{mouse,keyboard}</code> bugs. User has to have <code>AutoAddDevices "off"</code>, or <code>"AllowEmptyInput" "off"</code> in the config file, so nobody without <code>xorg.conf</code> will use them. |
| [08:22:25] whot!porky.stuttgart.redhat.com: right now, I'm not even sure how to fix this problem since I guess you're about as flat out as I am
| | |
| [08:26:49] mcepl: well, over IRC, so it wasn't that bad
| | Real evdev bugs are usually when over time something degenerates, when the pointer jumps after pressing a button, things like that, or when the server says “don’t know how to use device” (in <code>Xorg.*.log</code>). |
| [08:26:56] mcepl: strongly challenged ... let's say
| | |
| [08:27:32] mcepl: ehm, "as flat as" ... means what?
| | Therefore most input device bugs are in the <code>xorg-x11-server</code> component, assigned to peter. |
| [08:28:10] mcepl: burnt out or having no idea?
| | |
| [08:28:18] whot!porky.stuttgart.redhat.com: "flat out" means really busy
| | == How to spread bugs between evdev and -mouse or -keyboard == |
| [08:28:25] whot!porky.stuttgart.redhat.com: might be australian
| | |
| [08:28:37] whot!porky.stuttgart.redhat.com: comes from "flat out like a lizard drinking"
| | # is the device listed in <code>/proc/bus/input/devices</code>? no? -> kernel |
| [08:28:47] mcepl: well, yes, but ehm, your bugs are my job, so that's what I should be busy with
| | # is the device listed in <code>lshal</code>? no? -> kernel |
| [08:29:16] mcepl: yeah, please, move back to your Central European roots not that many lizards here
| | # is the devices listed with an <code>input.x11_driver</code> in <code>lshal</code>? no? -> hal configuration issue |
| [08:29:24] whot!porky.stuttgart.redhat.com: hehe. sorry.
| | # any <code>input.x11_options</code> by the user? no? - hal configuration issue. These are hard because they’re usually typos that are hard to spot, but you can probably punt the user to the input device configuration wiki page and let them sort it out themselves. |
| [08:29:47] whot!porky.stuttgart.redhat.com: a couple of things off the top of my head:
| | # if the Xorg.log lists the device when it appears and says “don’t know how to use device” that means the device is not detected by <code>evdev</code>. It shouldn’t happen with <code>>= F11</code> or rawhide, can still happen with <code>F10</code>. If it happens with <code>> F11</code>, its a bug that needs to be fixed upstream (and in that case I always need the output from http://people.freedesktop.org/~whot/evtest.c) |
| [08:30:06] mcepl: I can see the page on wiki ... I will use it
| | |
| [08:30:18] whot!porky.stuttgart.redhat.com: most evdev bugs aren't actually evdev bugs. they tend to get caught before the releases
| | I use output of <code>evtest</code> to write software test devices to simulate the hardware. the repository for that is at [git://people.freedesktop.org/~whot/testdevices.git git://people.freedesktop.org/~whot/testdevices.git], if the user can program, it’s quite simple to add new devices |
| [08:30:34] mcepl: (well, once I make my firefox not to loose all bookmarks, that is )
| | |
| [08:30:55] whot!porky.stuttgart.redhat.com: they're either configuration issues (HAL, usually) or server bugs. especially when it comes to keyboard layouts etc., it's nearly always server
| | If the device doesn’t send events or doesn’t behave properly, always check the evtest output too. if that one is busted, it’s a kernel or hardware issue. |
| [08:31:00] mcepl: yeah, that was the question ... I have no clue how to spread bugs between evdev and -mouse or -keyboard
| | |
| [08:31:29] whot!porky.stuttgart.redhat.com: mouse/keyboard is unused unless the have AutoAddDevices "off", or "AllowEmptyInput" "off" in the config file.
| | If evtest looks normal, but the server jumps it’s a server issue, often pointer acceleration or scaling |
| [08:31:56] whot!porky.stuttgart.redhat.com: so anyone w/o a configuration file will never use mouse/kbd
| | |
| [08:32:02] mcepl: well, and couldn't we make -evdev virtual component representing "whatever input problems we have" ... I have distrust for too big components?
| | == Synaptics bugs == |
| [08:32:16] mcepl: OK, noted ... no -mouse, -keyboard
| | |
| [08:32:50] whot!porky.stuttgart.redhat.com: i'm fine with a virtual component "X input" or so. evdev is more "political", if people always see that it's an evdev issue you get them to think that it's a broken driver
| | Another thing about evtest—synaptics won’t spit out any events to evtest while X is running because the device file is grabbed. so you need to VT switch away to get the events from the hardware. For evdev devices, that’s not a problem (now, evdev used to grab too until mid-F10). |
| [08:33:04] whot!porky.stuttgart.redhat.com: which means they try to switch to mouse/kbd, and that's where the real issues start
| | |
| [08:33:04] mcepl: OK, point taken
| | # anything that says input.capabilities input.touchpad in lshal uses synaptics. |
| [08:33:45] mcepl: how can I recognize real -evdev bugs then ... and I will move all others back to -server
| | # anything else, evdev |
| [08:33:50] mcepl: ?
| |
| [08:34:00] whot!porky.stuttgart.redhat.com: (you can still assign them to me, that's fine)
| |
| [08:34:29] whot!porky.stuttgart.redhat.com: real evdev bugs are usually when over time something degenerates, when the pointer jumps after pressing a button, things like that
| |
| [08:34:42] whot!porky.stuttgart.redhat.com: or when the server says "don't know how to use device".
| |
| [08:34:47] mcepl: or should I just fail on the other side and just move them to -server and we can move them back if necessary.
| |
| [08:35:24] whot!porky.stuttgart.redhat.com: yeah, probably. I don't think there's been a lot of real evdev bugs for a while now anyway
| |
| [08:35:43] whot!porky.stuttgart.redhat.com: so the standard approach for issues with devices is:
| |
| [08:35:57] whot!porky.stuttgart.redhat.com: is the device listed in /proc/bus/input/devices? no? -> kernel
| |
| [08:36:04] whot!porky.stuttgart.redhat.com: is the device listed in lshal? no? -> kernel
| |
| [08:36:16] whot!porky.stuttgart.redhat.com: is the devices listed with an input.x11_driver in lshal? no? - hal configuration issue
| |
| [08:36:50] whot!porky.stuttgart.redhat.com: any input.x11_options by the user? no? - hal configuration issue. these are hard because they're usually typos that are hard to spot
| |
| [08:37:11] whot!porky.stuttgart.redhat.com: but you can probably punt the user to the input device configuration wiki page and let them sort it out themselves
| |
| [08:37:59] whot!porky.stuttgart.redhat.com: if the Xorg.log lists the device when it appears and says 'don't know how to use device" that means the device is not detected by evdev. shouldn't happen with F11 or rawhide, can still happen with F10
| |
| [08:38:27] whot!porky.stuttgart.redhat.com: if it happens with > F11, its a bug that needs to be fixed upstream.
| |
| [08:38:42] mcepl: > or >= ?
| |
| [08:38:48] whot!porky.stuttgart.redhat.com: and in that case I always need the output from http://people.freedesktop.org/~whot/evtest.c
| |
| [08:39:02] whot!porky.stuttgart.redhat.com: sorry, F11 or higher (inclusive)
| |
| [08:39:46] whot!porky.stuttgart.redhat.com: I use that output to write software test devices to simulate the hardware. the repository for that is at git://people.freedesktop.org/~whot/testdevices.git, if the user can program, it's quite simple to add new devices
| |
| [08:40:28] whot!porky.stuttgart.redhat.com: if the device doesn't send events or doesn't behave properly, always check the evtest output too. if that one is busted, it's a kernel or hardware issue
| |
| [08:40:43] whot!porky.stuttgart.redhat.com: if evtest looks normal, but the server jumps it's a server issue, often pointer acceleration or scaling
| |
| [08:40:45] mcepl: Hmm, I think, good start will be to take this IRC conversation and rewrite it into wiki page ...
| |
| [08:40:51] whot!porky.stuttgart.redhat.com:
| |
| [08:40:59] whot!porky.stuttgart.redhat.com: I should have written all that down a while ago
| |
| [08:41:44] mcepl: is that it?
| |
| [08:41:48] whot!porky.stuttgart.redhat.com: lets do the following: you copy the above into a wiki page and I'll fix it up and add things as we go along. if you have extra questions, just ping me on IRC
| |
| [08:42:39] whot!porky.stuttgart.redhat.com: well, for now. I'll try to add some more info so you can help triaging it down to something more concrete to the wiki page
| |
| [08:42:44] mcepl: BTW, personal question, if I resume my T400 from suspend, and mouse doesn't move for couple of seconds? Have you seen this bug (I cannot recall I did)
| |
| [08:43:12] whot!porky.stuttgart.redhat.com: i got the same here. I think it's the kernel not restoring the device quickly enough.
| |
| [08:43:19] mcepl: well, OK, action notice for me now, is to make the draft of that wiki, and where to move from this point.
| |
| [08:43:21] whot!porky.stuttgart.redhat.com: so graphics comes back, but USB takes a while longer
| |
| [08:43:33] mcepl: OK, kernel then?
| |
| [08:43:45] mcepl: will file
| |
| [08:43:57] whot!porky.stuttgart.redhat.com: probably. I don't quite see how that could be triggered anywhere in the X stack
| |
| [08:44:34] whot!porky.stuttgart.redhat.com: oh, another thing about evtest - synaptics won't spit out any events to evtest while X is running because the device file is grabbed. so you need to VT switch away to get the events from the hardware
| |
| [08:44:41] whot!porky.stuttgart.redhat.com: for evdev devices, that's not a problem
| |
| [08:45:35] mcepl: meaning synaptics without evdev? (I guess synaptics driver is used somewhere in the background, isn't it?)
| |
| [08:48:10] whot!porky.stuttgart.redhat.com: synaptics uses the same backend, but evdev is a different driver
| |
| [08:48:19] whot!porky.stuttgart.redhat.com: evdev used to grab too until mid-F10 I think
| |
| [08:48:34] mcepl: OK, I see
| |
| [08:48:42] whot!porky.stuttgart.redhat.com: anything that says input.capabilities input.touchpad in lshal uses synaptics.
| |
| [08:48:57] whot!porky.stuttgart.redhat.com: anything else, evdev
| |
| [08:50:16] mcepl: OK, anything else (I am getting hungry and coffee-deprived; how long will you be around?)
| |
| [08:52:47] mcepl: BTW, can you run
| |
| ls ~/.mozilla/firefox/*.default/places.sqlite-*.corrupt|wc -l
| |
| and tell me what's the result?
| |
| [08:56:45] whot!porky.stuttgart.redhat.com: don't have the file
| |
| [08:56:58] mcepl: cool, thanks
| |
| [08:57:06] whot!porky.stuttgart.redhat.com: i'm on F11 though, maybe that's it?
| |
| [08:57:16] mcepl: no, I am on F11 as well
| |
| [08:57:25] mcepl: not *all* bugs went to Rawhide
| |
| [08:57:49] whot!porky.stuttgart.redhat.com: I think that's it with X bugs, at least from the top of my head. Gotta run for the bus too
| |
| [08:58:08] whot!porky.stuttgart.redhat.com: thanks and sorry for the spanking. I did tell kevin that it was mostly my fault for not telling you what to look for
| |
| [08:59:01] mcepl: no, spanking is probably too harsh ... kem is nice even when saying I screwed up (but that was the spirit of it)
| |
| [09:05:10] whot!porky.stuttgart.redhat.com: hehe
| |
| [09:05:22] whot!porky.stuttgart.redhat.com: ok. gotta run. thanks for listening, I'll add to the wiki page once it's there
| |
| </pre>
| |
Most evdev bugs aren’t actually evdev bugs. they tend to get caught before the releases. They’re either configuration issues (HAL, usually) or server bugs. especially when it comes to keyboard layouts etc., it’s nearly always server.
Also, there are almost no xorg-x11-drv-{mouse,keyboard} bugs. User has to have AutoAddDevices "off", or "AllowEmptyInput" "off" in the config file, so nobody without xorg.conf will use them.
Real evdev bugs are usually when over time something degenerates, when the pointer jumps after pressing a button, things like that, or when the server says “don’t know how to use device” (in Xorg.*.log).
Therefore most input device bugs are in the xorg-x11-server component, assigned to peter.
How to spread bugs between evdev and -mouse or -keyboard
- is the device listed in
/proc/bus/input/devices? no? -> kernel
- is the device listed in
lshal? no? -> kernel
- is the devices listed with an
input.x11_driver in lshal? no? -> hal configuration issue
- any
input.x11_options by the user? no? - hal configuration issue. These are hard because they’re usually typos that are hard to spot, but you can probably punt the user to the input device configuration wiki page and let them sort it out themselves.
- if the Xorg.log lists the device when it appears and says “don’t know how to use device” that means the device is not detected by
evdev. It shouldn’t happen with >= F11 or rawhide, can still happen with F10. If it happens with > F11, its a bug that needs to be fixed upstream (and in that case I always need the output from http://people.freedesktop.org/~whot/evtest.c)
I use output of evtest to write software test devices to simulate the hardware. the repository for that is at git://people.freedesktop.org/~whot/testdevices.git, if the user can program, it’s quite simple to add new devices
If the device doesn’t send events or doesn’t behave properly, always check the evtest output too. if that one is busted, it’s a kernel or hardware issue.
If evtest looks normal, but the server jumps it’s a server issue, often pointer acceleration or scaling
Synaptics bugs
Another thing about evtest—synaptics won’t spit out any events to evtest while X is running because the device file is grabbed. so you need to VT switch away to get the events from the hardware. For evdev devices, that’s not a problem (now, evdev used to grab too until mid-F10).
- anything that says input.capabilities input.touchpad in lshal uses synaptics.
- anything else, evdev
