Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Giuseppe" == Giuseppe Bilotta <bilotta78@xxxxxxxxxx> writes:

    Giuseppe> Concerning GPM vs kernel support for mice, maybe we can
    Giuseppe> hope for a merging of the efforts and a reduction of
    Giuseppe> code duplication, if there is any?

I'm trying to port the kernel's psmouse.c to userspace, exploiting the
SERIO_USERDEV patch that Tuukka  Toivonen and I developed.  That patch
provided a  direct path  from the  PC keyboard and  PS2 mouse  port to
userspace programs.  I've been using it so as to use my legacy XFree86
driver for my touch screen for many weeks.

I've just had some success porting atkbd.c to userspace.  Running this
userspace  program and  unloading the  'atkbd' module,  I can  type as
usual.  It works like this:


        userland          atkbd.c --------+             apps
                               ^          |              ^
                               |3         |4             |7
        module           'serio' with     |              |
                        SERIO_USERDEV     v        {input system}
                               ^        uinput           |
                               |2         |              |
        module              'i8042'       |5             |6
                               ^          |              |
                               |          |              |
        virtual device         |          +---> "AT keyboard"
                               |1
                               |
        hardware           i8042 chip

Data abstraction:
  (1) electronic signals
  (2), (3) byte stream
  (4), (5), (6), (7) a stream of struct input_event

By moving  the translation from  byte-stream to input events,  we have
more  flexibilities.  E.g.,  I've imagined  using SSH  to pipe  (3) to
another machine,  where my atkbd.c userland program  can then continue
converting to (4) and feeding that to the *remote* system.  This means
it's  possible  to  Alt-F1,  SysRq-*, ctrl-alt-delete  from  a  REMOTE
machine!   It's also  possible to  replace atkbd.c  above with  an X11
client that gives a virtual keyboard.  Again, this can be exploited to
do remote controlling.

Right now, my  atkbd.c doesn't hand the LEDs.  I get  stuck with a bug
with  'uinput',  which  oops   upon  select()  and  poll(),  which  is
necessary.  I've posted this bug,  which has been entered into buzilla
as bug #2786.

        http://bugzilla.kernel.org/show_bug.cgi?id=2786

As soon  as this  bug is fixed,  the userland  atkbd.c can be  made to
support the keyboard LEDs.



    Giuseppe> Overall, I think that the new system *could* be a good
    Giuseppe> starting point, but it still needs a *lot* of work.

I also agree the  new system has its merits.  What I  hate is only the
part  where  mouse/keyboard drivers  are  now  in  kernel space.   The
translation of  raw byte  streams into input  events should  be better
done in userland.  One important  argument is: userland program may be
swapped out.  Kernel modules can't.




--
Sau Dan LEE                     ???(Big5)                    ~{@nJX6X~}(HZ)

E-mail: danlee@xxxxxxxxxxxxxxxxxxxxxxxxxx
Home page: http://www.informatik.uni-freiburg.de/~danlee

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