Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@xxxxxxx> writes:

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

    Vojtech> Well, keyboard support was always in the kernel

Once in kernel space, forever in kernel space?  What's the logic?

Where  it is  now possible  to  move it  out of  kernel space  WITHOUT
performance problems, why not move it out?


    Vojtech>  - you need it there, because you need the keyboard
    Vojtech> always to work

Then, why make 'i8042' and  'atkbd' modules?  I still remember reading
web pages  that early  pioneers who migrated  from 2.4  to 2.6.0-test*
encountered a problem: they didn't compile-in these modules, and hence
the system boot  up without a responding keyboard.   Despite that, the
system does work and daemons are running!

So, why is a the keyboard need to always work?


I've  been  testing  'i8042'  module  and my  atkbd  driver  (and  the
SERIO_USERDEV  patch) through  the  network.  I've  been doing  'rmmod
i8042' many many times.  The system DOES work without that module (and
keyboard  functionality).   Why are  you  saying  that  "you need  the
keyboard  always  to  work"?   Again,   is  that  the  limit  of  your
imagination?

Are you aware of the i8042_shutdown bug, which I discovered and fixed?
How could I have found such a bug, if "keyboard has to always work"?


And  how about  mouse  drivers?  They  used  to be  in userland  (gpm,
XFree86 3.x -- 4.x, etc.)  Why move it into the kernel?




    >> I like the fact that 2.6.6 no longer assumes that the keyboard
    >> must be there (and thanks for your work to modularize those
    >> pieces of code).  This assumption doesn't hold, for instance,
    >> in some embedded systems, which has no keyboard controller and
    >> can only be controlled via an RS232 port.

    Vojtech> I meant that keyboard handling was never done in
    Vojtech> userspace. 

OK.  Then, it's time to consider moving it to userspace.


    Vojtech> Of course it is modular now, but that still counts as 'in
    Vojtech> the kernel'.

How about my atkbd.c?



    Vojtech> ;) On embedded systems, or when you have an USB
    Vojtech> keyboard, you can leave the whole PS/2 stuff out.

Is  it impossible  to run  daemons driving  the keyboard  (my atkbd.c,
should  be invoked  from inittab)  and mouse  (e.g.  gpm)  on embedded
systems?  I mean, why MUST the keyboard and mouse drivers be in kernel
space?


    Vojtech> But still, if you have a working keyboard, the handling
    Vojtech> is done in the kernel, and you can do a register dump,
    Vojtech> process listing, etc, even when the system is
    Vojtech> crashed.

Why just  the keyboard?  For that  purpose, we can  use mouse buttons,
the  power button,  a joystick  button, or  even a  home-brewed button
connected to the RS232 port or parallel port.  Why *limit* that to the
keyboard?


    Vojtech> You wouldn't be able to do that if the processing of the
    Vojtech> byte stream was done in an userspace program.

Isn't it  possible to monitor  the kernel via  a tty connected  to the
serial line?


    Vojtech> - even in the case of a crash, when all userspace
    Vojtech> programs may already be dead.
    >>  There are still RS232 ports and the network.

    Vojtech> Sure. How convenient it is to have to find an RS232
    Vojtech> cable, when your keyboard is just next to you on the
    Vojtech> table?

The keyboard should be made an *option*, not a *requirement* for that.
As an optional feature, yo shouldn't assume it for granted.



    >>  Can't SysRq be triggered from a program now, in addition to
    >> using a keyboard?

    Vojtech> It can. But if your userspace is dead, you cannot run
    Vojtech> that program. And that's usually when you need sysrq.

So, why limit that to the  keyboard only?  Why can't my LED lid switch
do it?


    >>  Is that "improvement" significant for 1200 baud devices?  Even
    >> on a 386DX-33?

    Vojtech> Yes. Very much significant. Exactly because they're
    Vojtech> running at 1200 baud, you need get most of that little
    Vojtech> data they're sending to you. 

I don't  understand this.  The slower  a device is, the  lesser is the
need to handle the incoming  data in kernel space.  I can't understand
how 1200baud is  fast enough to cause significant  delays.  Maybe, you
can enlighten me on that?


    Vojtech> The problem is that you get jerky mouse movement. It
    Vojtech> stays for a while on one place (when the buffer is
    Vojtech> filled), and then jumps elsewhere (when it's
    Vojtech> processed). You need to do the processing byte by byte,
    Vojtech> as they arrive.

Yeah.  At  what rate  are they arriving?   1200baud.  Let's  say that'
9600bps.   So,   1200  bytes  per   second.   1  byte  in   every  833
microseconds.  How  come a processor at 33MHz  (0.030 microseconds per
clock cycle) cannot  cope with that?  Assuming that  the processing of
the  data  plus  context  switching  plus  other  overhead  taks  1000
microseconds, that still shouldn't be felt by a HUMAN user.  Who has a
reaction time of less than 100 _milli_seconds?



    Vojtech> Yes, it does. Because it uses the _kernel_ input system
    Vojtech> to do the interfacing work. But I don't see any benefit
    Vojtech> of having to go to userspace and back again into the
    Vojtech> kernel.

Flexibility.  The  keyboard driver can  talk to another machine  via a
TCP  connection, for  instance.   The keyboard  driver  can be  easily
modified  and debugged --  all in  user space  -- without  hanging the
kernel due to  stupid bugs (e.g. NULL pointers).   The keyboard driver
could be prototyped  in Perl, C++, or any  other high-level languages.
(It'd be possible  to design a specific language to  make it easier to
describe the state machine, than in a general purpose language like C,
making it possible to  less programming-proficient users to change the
keyboard behaviours.)



    Vojtech> Care to name any? Everything from raw SCSI handling to
    Vojtech> presenting files to processes is done in the
    Vojtech> kernel. 

So,  raw access  is  still available,  just  in case  the kernel  code
developers' imaginations are exceeded in some applications.


    >> If you think those are kernel jobs, then you have an argument
    >> for implementing Ghostscript completely in kernel, so that we
    >> can cat mythesis.ps > /dev/psprinter, whether or not my printer
    >> is a Postscript printer, and whether or not it is connected
    >> locally or remotely, right?

    Vojtech> Good argument. There are limits of what makes sense to do
    Vojtech> in the kernel.  Ghostscript is easier to do in userspace,
    Vojtech> because it needs access to fonts, has a nontrivial
    Vojtech> configuration, isn't time critical, etc. Good candidate
    Vojtech> for userspace.

Keyboard and mouse drivers are also easier to do in userspace, because
that  makes access to  keymaps, mouse  protocol modules,  etc. easier.
Neither do I think keyboard/mouse  drivers are time critical enough to
be absolutely  placed in  kernel space.  Human  beings do not  work in
units of milliseconds.


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