Console Support for event devices.

[Thomas H H. <wy...@at...>]

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.

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.  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.

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.

Happy Hacking,
--Tom.

============================================================
Thomas H. Hendrick
<wy...@at...>