Re: rfkill-input madness

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]