Re: Console Support for event devices.

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

> 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
kernel takes care of stdin, but the event devices don't have that capability.
So, if programs wanted to use /dev/input/eventX for input instead of stdin, they
would get ALL of the events that the input device generates regardless of who
has the device focus.  Like I said, I figured that I'd play with it on a branch.

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

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

--Tom.