Inner-workings of Keyboard Event Handling under Linux -
when press keyboard's key on gtk application under linux, happens exactly? how key received (from device), interpreted, passed program, , handled?
it's rather complex process...
- the keyboard has 2d matrix of key connections , own microprocessor or gate array containing microprocessor. scanning matrix find out if keys pressed. (to save pins, keys not individually tested.) keyboard micro speaks protocol keyboard controller in cpu , transmits message indicating keypress.
- the keyboard controller notes code , interrupts cpu.
- the keyboard driver receives interrupt, reads keycode out of controller register, , places keycode in buffer links interrupt side of kernel per-process threads. marks thread waiting keyboard input "runnable"
- this thread wakes up. turns out, x server. x server reads keycode kernel.
- the server will check see window has keyboard focus. window connected 1 of various clients.
- the server sends event client displayed specific window. (note server, every textbox , such "window", not entire applications.)
- the event loop in client waiting next server event message. connection via tcp or local unix feature. uses read(2) or socket op next event message.
- the low-level xlib routine passes keypress higher level widgets, getting gtk function of kind.
- the gtk api element hands character program.
i glossed on language mappings, console multiplexing, , few other things...
update: so, /dev/input/*
, in fact of /dev/*
things things called block or character special files. important thing have no stored data in filesystem, major , minor device number serve driver in kernel in table. it's simple. if ls -l
/dev/input see major , minor device number instead of file size. major number identifies device driver , minor number sort of instance-number passed (within kernel) parameter driver.
Comments
Post a Comment