From Fedora Project Wiki

< Xorg

Revision as of 07:23, 25 June 2009 by Mcepl (talk | contribs) (Created page with '[08:17:45] whot! "spanked"? that bad? [08:22:07] whot! hmm. we need to find some middle ground for triaging on the bug error...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

[08:17:45] whot! "spanked"? that bad? [08:22:07] whot! 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 [08:22:25] whot! 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 [08:26:56] mcepl: strongly challenged ... let's say [08:27:32] mcepl: ehm, "as flat as" ... means what? [08:28:10] mcepl: burnt out or having no idea? [08:28:18] whot! "flat out" means really busy [08:28:25] whot! might be australian [08:28:37] whot! comes from "flat out like a lizard drinking" [08:28:47] mcepl: well, yes, but ehm, your bugs are my job, so that's what I should be busy with [08:29:16] mcepl: yeah, please, move back to your Central European roots not that many lizards here [08:29:24] whot! hehe. sorry. [08:29:47] whot! a couple of things off the top of my head: [08:30:06] mcepl: I can see the page on wiki ... I will use it [08:30:18] whot! most evdev bugs aren't actually evdev bugs. they tend to get caught before the releases [08:30:34] mcepl: (well, once I make my firefox not to loose all bookmarks, that is ) [08:30:55] whot! they're either configuration issues (HAL, usually) or server bugs. especially when it comes to keyboard layouts etc., it's nearly always server [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! mouse/keyboard is unused unless the have AutoAddDevices "off", or "AllowEmptyInput" "off" in the config file. [08:31:56] whot! 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? [08:32:16] mcepl: OK, noted ... no -mouse, -keyboard [08:32:50] whot! 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 [08:33:04] whot! which means they try to switch to mouse/kbd, and that's where the real issues start [08:33:04] mcepl: OK, point taken [08:33:45] mcepl: how can I recognize real -evdev bugs then ... and I will move all others back to -server [08:33:50] mcepl: ? [08:34:00] whot! (you can still assign them to me, that's fine) [08:34:29] whot! 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! 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! yeah, probably. I don't think there's been a lot of real evdev bugs for a while now anyway [08:35:43] whot! so the standard approach for issues with devices is: [08:35:57] whot! is the device listed in /proc/bus/input/devices? no? -> kernel [08:36:04] whot! is the device listed in lshal? no? -> kernel [08:36:16] whot! is the devices listed with an input.x11_driver in lshal? no? - hal configuration issue [08:36:50] whot! 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! 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! 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! if it happens with > F11, its a bug that needs to be fixed upstream. [08:38:42] mcepl: > or >= ? [08:38:48] whot! and in that case I always need the output from [08:39:02] whot! sorry, F11 or higher (inclusive) [08:39:46] whot! I use that output to write software test devices to simulate the hardware. the repository for that is at git://, if the user can program, it's quite simple to add new devices [08:40:28] whot! 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! 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! [08:40:59] whot! I should have written all that down a while ago [08:41:44] mcepl: is that it? [08:41:48] whot! 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! 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! 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! 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! probably. I don't quite see how that could be triggered anywhere in the X stack [08:44:34] whot! 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! 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! synaptics uses the same backend, but evdev is a different driver [08:48:19] whot! evdev used to grab too until mid-F10 I think [08:48:34] mcepl: OK, I see [08:48:42] whot! anything that says input.capabilities input.touchpad in lshal uses synaptics. [08:48:57] whot! 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! don't have the file [08:56:58] mcepl: cool, thanks [08:57:06] whot! 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! 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! 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! hehe [09:05:22] whot! ok. gotta run. thanks for listening, I'll add to the wiki page once it's there