jussi.laako at linux.intel.com
Fri Apr 11 07:47:13 GMT 2014
On 11.4.2014 2:14, Carsten Haitzler (The Rasterman) wrote:
> 4. once you do these, you'll know why. (it's an essential part of input routing
> and focus management, as well as shortcuts, mouse pointer control and routing
> - only display server knows WHERE the mouse or touch point is pointing to on
> screen, and routes the mouse events appropriately).
Route control and data are two separate things. In order to control data
flow you don't actually have to see the data. Just like uploading
routing table to a hardware based route matrix.
Display server knows that application X has topmost window at (x, y, w,
h) so it tells mouse routing matrix to route translated mouse events
from input device to the application when mouse position is within these
coordinates. It shouldn't actually know where the mouse is.
Display server also knows that application X has keyboard focus, so it
tells keyboard route matrix to route keyboard input events from input
device to the application. Display server doesn't need to see the actual
Shortcuts can be implemented using a special global meta key filter in
the input layer driver and route those to a special shortcut key handler
device node where a special shortcut handler process sits, none of the
normal keyboard input events would be routed there.
Note that the route matrix can either reside within separate user space
process, or could be just a simple implementation right in the kernel
You can see this kind of software design pattern for example in the
Postfix email server, where each subtask is split to a separate least
More information about the Dev