Messages in this thread | | | Date | Sat, 29 May 2004 15:12:33 +0200 | From | Vojtech Pavlik <> | Subject | Re: keyboard problem with 2.6.6 |
| |
On Fri, May 28, 2004 at 07:37:57PM +0200, Sau Dan Lee wrote:
> I also agree the new system has its merits.
Thanks.
> 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.
Well, keyboard support was always in the kernel - you need it there, because you need the keyboard always to work - even in the case of a crash, when all userspace programs may already be dead.
That's also the reason why keyboard processing is done in the interrupt context - even if nothing else works in the kernel but interrupts, you still can get a register dump for example, using the keyboard.
Regarding mice: Yes, PS/2 and serial mice can be in userspace, as is proven by reality. With USB mice it's much tougher, and busmice and many other mice on non-PC platforms need their drivers to be in the kernel, as they access hardware directly and not via a byte stream abstraction.
Although PS/2 mice are very common, they're just one case in many. Thus it was easier to put the processing of them in the kernel, too. It gives us good advantages, like the support for AUX multiplexing (where you have more mice connected to one system), synaptics passthrough (where you have a mouse connected to a touchpad, with the data being embedded in the touchpad protocol), and other stuff.
For serial mice, doing the processing in the kernel brought us a 4 times better response rate for the mousesystems kind of them and 2 times better for microsoft mice. That actually makes both useable.
And here are the two main reasons to keep mouse and keyboard processing in the kernel:
1) Latency. The time it takes from keypress to giving it to an application. Adding intermediate programs inbetween doesn't help this at all.
2) Unified interface. If an application (X, QtEmbedded, SDL ...) needs to talk to a mouse or keyboard, it can use the event interface instead of knowing a gazillion of different protocols. This is a kernel job.
-- Vojtech Pavlik SuSE Labs, SuSE CR - 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/
| |