Re: Console Support for event devices.

[Vojtech P. <vo...@su...>]

On Sat, Apr 13, 2002 at 01:23:16PM -0400, Thomas H Hendrick wrote:
> > On Fri, Apr 12, 2002 at 03:18:40PM -0400, Thomas H Hendrick wrote:
> > > I was thinking that it would be nice if we could include support for
> user-space
> > > programs to request that events (/dev/input/eventX) only be sent to a file
> > > descriptor when they are the foreground terminal.  I am going to play with
> this
> > > idea on my branch so it doesn't pollute the current devel code.  If we like
> it,
> > > we can merge when the time comes.
> > >
> > > The idea is that the input_event struct provides all the wonderful
> information
> > > that programs will need.  However, between input and the user is some
> > > boiling/refining that removes some of the unnecessary information that
> probably
> > > 90-95% of all user-space programs don't care about.  For them, stdin/stdio
> takes
> > > care of all of their needs.
> > >
> > > For that other 5-10%, the event device provides all the information you
> would
> > > need to do mouse, keyboard, etc.  However you will get ALL events destined
> for
> > > ALL consoles/terminals/etc, regardless of whether it was intended for you or
> vc
> > > 6 or the X-server or some x-term ... etc.
> >
> > xterm? Uh-huh, how? xterms get mouse/keyboard data via the X protocol.
> 
> Sorry.  Meant something else.
> 
> > Actually a much more interesting project would be to write a console as
> > an userspace program connecting to /dev/pty's and using input and
> > framebuffers to implement all that's expected from a console. Including
> > nifty stuff like complete Unicode support, etc.
> 
> > > I know by the end of 2.5.X I'm going to be nicknamed "The Ioctl Avenger" or
> > > something, but my current idea is to leave the devices are they are
> currently,
> > > and just add support for an ioctl, EVIOCCONSOLEONLY, which will signal to
> the
> > > event driver to only deliver events to a particular struct file when it is
> > > associated with the foreground console.  The rest is just adding the check
> to
> > > see if the pid of the file-owner is the same as the pid of the foreground vc
> > > owner before delivering the event.
> >
> > I don't think this is a good idea. The app can filter that itself with
> > no problems, while it adds a lot of cruft into the kernel if implemented
> > there.
> 
> Well, the problem is that if an event comes into a program, it will have no idea
> if that event was meant for it, or another program on a different console. 

The program can know which console is active and which console it is
running on, thus can know whether the event is meant for it or not.

> The
> kernel takes care of stdin, but the event devices don't have that capability.

Because they're much more low-level, yes. That's intended.

> So, if programs wanted to use /dev/input/eventX for input instead of stdin,

That's of course impossible because of the completely different data
format, for example.

> they would get ALL of the events that the input device generates
> regardless of who has the device focus. 

Input is vt/console agnostic - it doesn't know and doesn't want to know
anything about virtual terminals or consoles, they're a layer above
input. It must work just fine even without any console code (and it
does).

> Like I said, I figured that
> I'd play with it on a branch.

And I won't accept it into the mainstream, unless you bring some
stronger arguments why it is really needed. If there are any programs
that would benefit from it.

> > > There is one downside, however, that
> > > programs using the event device which may have more than one console open
> will
> > > not know which console the event occurred on, unless the input_event struct
> is
> > > changed to include a vc number - or- they open each event device multiple
> times,
> > > and register a different vc for each one.  There is a possible security
> risk,
> > > however, if I just let an program register to listen for events on any vt.
> Not
> > > that it isn't a risk already, to some degree.  (A potential malcontent could
> ssh
> > > to a machine they have an account on, and use evtest to listen to the
> keyboard.
> > > They just need to look for KEY_EVENT "r" "o" "o" "t" "KEY_ENTER" "p" "a" "s"
> "s"
> > > "w" "o" "r" "d" KEY_ENTER.  Like I said, I'll play with it.
> >
> > Actually, no. They should be root-readable only anyway, and root isn't
> > interested in his own password.
> 
> Noted.  Wonder why mine was set to ugo+rw...

Tracking the mouse or whatever is similarly dangerous. Note that even if
you added VT-switching support into evdev (or deeper into input), it
won't help, because the application still can not enable it and get all
events.

Anyway, what you might be aiming at is adding 'event' protocol support
to the console, in addition to the raw and medium raw protocols. It
might be interesting, yes. I think (extended) medium raw, as available
now in ruby is quite enough anyway.

> > > The alternative to the Ioctl idea was to add separate /dev/input devices
> that
> > > would be associated with particular terminals, but each input device would
> need
> > > a file associated with each terminal, and ... well, that's just ugly, IMHO.
> > >
> > > Like I said, I'm gonna branch this so it doesn't pollute.
> > >
> > > On the flip side of things, I'm hammering away on the user-space program to
> swap
> > > in keymaps.  I have implemented the full keymap ioctl's to transfer the
> keymap
> > > data all-at-once.  I will remove the older ioctl's, and test the newer ones
> once
> > > I get the user-space program finished.
> >
> > Keep in mind that the keymaps will have different sizes and different
> > cell sizes as well. They may be 256 bytes or 512 shorts or anything else
> > on different keyboards.
> 
> Already taken into account.  The code that you had already placed there took
> care of the data-sizing, so I copied the relevant bits to adjust the size as
> appropriate.  Like I said, I'll test it once I get the user-space program
> together, which I've been busy the past couple of days and I haven't been coding
> much.
> 
> BTW, is there a "release date" for 2.6.0 rumored, talked about, scheduled,
> anything?

No, of course not. We've just started the 2.5 series.

-- 
Vojtech Pavlik
SuSE Labs