lkml.org 
[lkml]   [2004]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: keyboard problem with 2.6.6
From
Date
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> 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 - you
Vojtech> need it there, because you need the keyboard always to
Vojtech> work

No. That's not the case (at least beginning from 2.6.6). If you
assume the keyboard is always there, they why make 'i8042' and 'atkbd'
modules?

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> - 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> That's also the reason why keyboard processing is done in
Vojtech> the interrupt context - even if nothing else works in the
Vojtech> kernel but interrupts, you still can get a register dump
Vojtech> for example, using the keyboard.

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


Vojtech> Regarding mice: Yes, PS/2 and serial mice can be in
Vojtech> userspace, as is proven by reality. With USB mice it's
Vojtech> much tougher, and busmice and many other mice on non-PC
Vojtech> platforms need their drivers to be in the kernel, as they
Vojtech> access hardware directly and not via a byte stream
Vojtech> abstraction.

A kernel driver can turn it into a byte stream. What does 'evdev' do,
then? Isn't it turning those events into a stream of "struct
input_event"s? That's a byte stream, although you have to be careful
to call read()/write() with a suitable size parameter.


Vojtech> For serial mice, doing the processing in the kernel
Vojtech> brought us a 4 times better response rate for the
Vojtech> mousesystems kind of them and 2 times better for
Vojtech> microsoft mice. That actually makes both useable.

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


Vojtech> And here are the two main reasons to keep mouse and
Vojtech> keyboard processing in the kernel:

Vojtech> 1) Latency. The time it takes from keypress to giving it
Vojtech> to an application. Adding intermediate programs inbetween
Vojtech> doesn't help this at all.

Well... I believe 'pppd' is more sensitive to latencies problems (when
talking to the RS232 port) than a mouse driver. Why don't you migrate
pppd into the kernel, then? Remember, we have 56kbps modems (at 2400
baud?). I believe pppd should be kernelized before the mouse drivers.
Making pppd a kernel module also eliminates the current need for pppd
to communicate with a kernel driver to create the ppp0, ppp1,
... interfaces, too.

Actually, as long as the low-level byte-stream module has a big enough
buffer to handle the bursts of data, and the userland driver is quick
enough (on average) to consume the incoming data, what's the problem?


Vojtech> 2) Unified interface. If an application (X, QtEmbedded,
Vojtech> SDL ...) needs to talk to a mouse or keyboard, it can use
Vojtech> the event interface instead of knowing a gazillion of
Vojtech> different protocols.

I've demonstrated how a unified interface can be done using my atkbd.c
and psmouse userland drivers. These useland drivers translate the raw
byte stream, convert them into "struct input_event", and then refeed
them into the input system. It works!


Vojtech> This is a kernel job.

No. This can be done in userspace. We should keep the kernel code to
a minimal size. Most other "drivers" in Linux has a kernel half
(a.k.a. bottom-half?) and a userland half. The kernel half is to do
what must be done in kernel: creating a device, reacting to
interrupts, putting the stream of data in a buffer. Mostly simple
tasks that must be done quickly. The userland half, which is more
computation-intensitive, gets the data and do the complicated
processing.


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?



--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)

E-mail: danlee@informatik.uni-freiburg.de
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.067 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site