jussi.laako at linux.intel.com
Fri Apr 11 11:32:16 GMT 2014
On 11.4.2014 12:31, Carsten Haitzler wrote:
> you route on an event by event basis based on the content of the event
> and the requests from clients plus current display state. that's how you
> manage key grabs.
Notice that routing events != seeing event contents.
> and what when the window is rotated by 30 degrees, or wrapped around a
> 3d mesh of a bunny rabbit? and the only one who knows the mesh is the
> compositor/display server? yes - that's wayland. it allows this and is
> designed to be able to do it and work correctly.
Well, you upload the transformation matrix to routing node then. You
could even have hardware IP block optimized to do this kind of
transformation and routing.
This kind of thing has been done at networking side already, you can
upload new routing tables to routers using SNMP and update routes using
RIP, but that doesn't mean you would need to see all the packet content
or decrypt HTTPS traffic at the point where the routing tables are created.
Similar with pulseaudio + murphy. Or jackd + qjackctl. You don't need
access to the audio data in order to make routing decisions. Why would
display system need such access? Do you next plan to add also audio to
the display server? Luckily X11 audio never made it.
Maybe I add PIN code entry using speech recognition or whistling morse
codes, then weston doesn't have access to it?
> so you just move stuff from display server into kernel, bloating the
> kernel with policy it isn't interested in and is better handled in
> userspace. and that policy can get increasingly more complex as time
> goes on to handle all the event routing situations - see above with 3d
> bunny mesh.
This is already done with IP routing tables and iptables packet
filtering. Nothing new really. And kdbus is not that far from message
You could also have "kbdrouted", "mouserouted", "touchrouted",
"surfacesvcd", "windowmgrd", etc in user space. Again, compare to design
More information about the Dev