[Dev] Cynara

Jussi Laako 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 
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.



More information about the Dev mailing list