Re: Console Support for event devices.

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

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.

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.

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

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

-- 
Vojtech Pavlik
SuSE Labs