On Fri, 2009-03-27 at 11:30 -0300, Henrique de Moraes Holschuh wrote: > I think rephrasing that warning to: "set user_claim to 1 on any switches > that you're going to mess with in response to rfkill input events" would be > a LOT better. I should have written it that way. Indeed, but that's useless since almost all drivers disable userspace claiming... I'll re-implement it later for only the software state. > The truth is that userspace doestn't have to care about rfkill-input, unless > it is trying to do what rfkill-input is supposed to (i.e. listening to input > events and then trying to update switches), and if it is going to do that, > it needs stuff that I never sent in for review. Care to explain? > Anyway, I got sidetracked because I was Not Happy with the userspace ABI but > couldn't come up with anything better. It's not like we can change it now... > Better at least get those patches > into the open. I just pushed a rebased version of the patches to somewhere > public. > > It is at: > git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git rfkill > > Please take a look and tell me what you think, and whether there is anything > worth bothering with in there (FWIW, the patchset worked just fine last time > I checked). Ok, when I get online again :) > As for your second question, I have been looking at the issues re. input > devices and X.org evdev in the last two days, and the fact is that: it will > have to be handled in userspace on most non-embedded scenarios, if things > don't change in userspace soon. > > The problem is that X.org will exclusive-grab any input devices you let it > touch, and rfkill_input will never see any events, anyway. So, right now, > for the vast majority of the users, either an input device is not in use, or > it is in exclusive-grab mode feeding X.org evdev. > > At this point, I don't have a clue on what would be the best way to go about > addressing this issue, that is causing problems not only to rfkill_input, > but also to anyone who would like to have hotkey handling outside of X.org > in a system daemon, but still have x.org see the keys (without ugly 'event > repeater' hacks). > > I have no idea if we should talk to the X.org people to see if we can drop > that exclusive grab? Allow kernel-side input handlers to ignore exclusive > grabs? Have rfkill-input be a you-want-it-in-the-kernel solution and simply > don't care at all about userspace interfering with it? > > I was about to try to locate someone that deals with evdev to ask his ideas > on the subject. Indeed, but that means *X* needs to implement all this, or something running in X, which is undesirable... Other things are sure to run afoul of this too, for example some hal button handlers. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
