linux-kernel - Re: [PATCH] Input: Support for a less exclusive grab.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d120d5000710261029t6673c60ci923823fb84cac373@mail.gmail.com>
Date:	Fri, 26 Oct 2007 13:29:37 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Ryan Lortie" <desrt@...rt.ca>,
	"Dmitry Torokhov" <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org, "Vojtech Pavlik" <vojtech@...e.cz>,
	linux-input <linux-input@...ey.karlin.mff.cuni.cz>
Subject: Re: [PATCH] Input: Support for a less exclusive grab.

On 10/26/07, Zephaniah E. Hull <warp@...allh.com> wrote:
> On Thu, Oct 25, 2007 at 01:37:34AM -0400, Ryan Lortie wrote:
> > On Wed, 2007-24-10 at 11:35 -0400, Zephaniah E. Hull wrote:
> > > We need a way to, at the absolute minimum, unbind the keyboard from the
> > > text console.  The current solution sucks for things like rfkill.
> > >
> > > I'm not convinced that Ryan's fix is any better, but just saying that X
> > > should open the console and ignore the characters is simply not an
> > > option as far as I am concerned for X.
> >
> > Can you think of any other way to separate things like rfkill/evdev from
> > things like the text console that's less hacky than my 'priority'
> > scheme?
>
> What we really want to give is exclusitivity verses other 'end users',
> as opposed the 'filters'.
>
> I'm defining an 'end user' to be a handler that cares about all the
> events from a device and plans on doing something with it.
>
> That would be the console layer for keyboards, /dev/input/mice and
> /dev/input/mouse<n> for mice, X for both of those, etc.
>
> A 'filter' cares about a key or two, and might even want to remove it
> from the stream, rfkill is a good example.
>

No, rfkill does not want to remove anything from the event stream. It
perfectly happy with other users seeing the same events and doing
their own things with them.

> Now, how do we design for that?  Not a clue right now, still thinking
> about it really.
>

I really think that it should be solved by applications themselves.
Applications should only open devices they are interested in and only
process events they are interested in. The rest should be simply
ignored by the application. This is the only sane way. Otherwise we
will need to split applications into first and second class citizens
and have to manage dependencies between them.

The only exception is console because both kerenl and X are fighting
over control of VT switching. As a workaround one could open console
in raw mode. If this feels too "dirty" I guess we could have ioctl for
"taking over console" for applications willing to do so. The ioctl
would disable VT switching and touching LEDs by the console driver.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/