> afaik, there is nothing at the kernel level to prevent a crash of the
> keyboard when running root or suidroot programs such as the X Server,
> DosEmu, SvgaLib-based programs (mostly games and demoscene stuff)...
I looked into this a bit. The problem is that keyboard mode is
associated with the device, not the file descriptor. It seems that
the device does the keyboard code translations before putting data
into a TTY flip buffer, from which multiple processes can read the
data. To fix, conversion must happen on the other side of the TTY
buffer or the TTY buffer must be eliminated AFAIK.
> keyboard anymore, and no mouse either because X overrides GPM
> (GPM has a feature for rebooting the system in case of keyboard
> lock, but if GPM is disabled by X, it's worthless, and anyway,
> the mouse is not the responsibility of the kernel).
No, the kernel should have better mouse support. SysV systems have
an event queue that includes both mouse and keyboard. If that is
not offered, then both mouse and keyboard need to supply high-resolution
timestamps so that user-space can be sure of event order. Without
the combined queue and/or timestamps, keystrokes can go to the wrong
window and a shift-click might be seen as shift followed by click.
I think GGI's EvStack provides both. Real-time scheduling can hide the
problem most of the time, but it doesn't completely eliminate the race.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu