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 commands.
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 input layer.
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 privileged process.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
