Carsten Haitzler (The Rasterman)
tizen at rasterman.com
Sat Apr 12 03:09:42 GMT 2014
On Fri, 11 Apr 2014 14:32:16 +0300 Jussi Laako <jussi.laako at linux.intel.com>
> 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.
to route you have to see. content + context determines routing. didn't i
already repeat about grabs, coordinate transformation etc.
> > 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.
people who do this for a living have been down this design path and explored
it. it doesn't work. it scales horribly. look at x11 shape extension. people who
have been doing display systems for a long time. like most of their professional
lives. and that's a lot of years. i agree with them. there isn't just a single
matrix. it's far more complex than that. you can't do transforms over a bunny
mesh - or a sphere, or a curled piece of paper with a single matrix. you need a
vast detailed mesh. and as animation changes, this mesh keeps changing. handing
the data over is impractical at best, and at worst is heavily complicates a
kernel in doing things it never should do. then what happens when i have a voxel
layout and the router only allows triangle meshes?
> 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.
graphics is several orders of magnitude more complex and doesn't have a defined
standard ala tcp/ip that has to be adhered to. it's freeform.
> Similar with pulseaudio + murphy. Or jackd + qjackctl. You don't need
pulse audio sees all the audio data. it goes through it. also routing is
insanely simpler, and it's pa that defines the routing posibilites and design,
not in a display serever. the kernel doesnt design the graphics layout and
rendering methods (voxels, triangles, bitmaps or rect list regions etc.).
> 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.
you need access to pixel data to know if there is an alpha or transparency area
and if events are to drop through that area or not. you need access to the
entire 3d scene in its native representation to do picking. read up on it one
day. :) you need to know the key being pressed because aap a asked to be
sent the key event for F1 if F1 is pressed, so thee focused app doesnt get it -
the one that grabs it does. you cant route F1 to the destination app unless you
know it is F1 that is pressed. then there it eh case when someone has a
keyboard grab - then you don't route F1 as normal to the grab but the grabber
gets it. your routing patterns change on the current context and state of apps,
and the input itself.
> Maybe I add PIN code entry using speech recognition or whistling morse
> codes, then weston doesn't have access to it?
in your fantasy land - great.. not back in the real world, people will be
entering passwords via standard input mechanisms. the display system that is
there (x11 or wayland) is already designed and has compatibility and design
decisions all through it that you won't change. the fact is that given design
AND plractical concerns, and actual set of experience with history and past
efforts, the display server has access to all input. be that xorg (and thus any
x11 client via xinput), or wayland (only the display server has that access,
and can send/grant/route input to clients as it sees fit based on its policies.
> > 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
> routing either.
> You could also have "kbdrouted", "mouserouted", "touchrouted",
> "surfacesvcd", "windowmgrd", etc in user space. Again, compare to design
> of postfix.
but they will never exist. so you live in a world far away from everyone else
and far away from tizen. back in the real world, this is not the case, and
never will be because it's impractical. i think you should just go make your
own os, and the os you want is not the one the rest of us work on and use. :)
Carsten Haitzler (The Rasterman) <tizen at rasterman.com>
More information about the Dev