|
|
|
@ -1,5 +1,11 @@ |
|
|
|
|
- sync-to-vblank |
|
|
|
|
|
|
|
|
|
- how does clients move their surfaces? set a full tri-mesh every |
|
|
|
|
time? probably just go back to x and y position, let the compositor |
|
|
|
|
do the fancy stuff. How does the server apply transformations to a |
|
|
|
|
surface behind the clients back? (wobbly, minimize, zoom) Maybe |
|
|
|
|
wobble is client side? |
|
|
|
|
|
|
|
|
|
- switch scanout when top surface is full screen |
|
|
|
|
|
|
|
|
|
- what about cursors then? maybe use hw cursors if the cursor |
|
|
|
@ -13,6 +19,14 @@ |
|
|
|
|
- Advertise axes as part of the discovery, use something like |
|
|
|
|
"org.wayland.input.x" to identify the axes. |
|
|
|
|
|
|
|
|
|
- keyboard state, layout events at connect time and when it |
|
|
|
|
changes |
|
|
|
|
|
|
|
|
|
- relative events |
|
|
|
|
|
|
|
|
|
- input handling - keyboard focus, multiple input devices, |
|
|
|
|
multiple pointers, multi touch. |
|
|
|
|
|
|
|
|
|
- wayland-system-compositor |
|
|
|
|
|
|
|
|
|
- device kit/libudev/console kit integration to discover seats, |
|
|
|
@ -108,10 +122,20 @@ |
|
|
|
|
desired data to write, if it overwrites tail, block guest. just |
|
|
|
|
a socket would be easier. |
|
|
|
|
|
|
|
|
|
- moblin as a wayland compositor |
|
|
|
|
|
|
|
|
|
- clutter as a wayland compositors |
|
|
|
|
|
|
|
|
|
- argh, mutter |
|
|
|
|
|
|
|
|
|
- make libwayland-client less ghetto |
|
|
|
|
|
|
|
|
|
- sparse based idl compiler |
|
|
|
|
|
|
|
|
|
- crack? |
|
|
|
|
|
|
|
|
|
- xml based description instead? |
|
|
|
|
|
|
|
|
|
- actually make batch/commit batch up commands |
|
|
|
|
|
|
|
|
|
- protocol for setting the cursor image |
|
|
|
@ -119,6 +143,19 @@ |
|
|
|
|
- should we have a mechanism to attach surface to cursor for |
|
|
|
|
guaranteed non-laggy drag? |
|
|
|
|
|
|
|
|
|
- drawing cursors, moving them, cursor themes, attaching surfaces |
|
|
|
|
to cursors. How do you change cursors when you mouse over a |
|
|
|
|
text field if you don't have subwindows? This is what we do: a |
|
|
|
|
client can set a cursor for a surface and wayland will set that |
|
|
|
|
on enter and revert to default on leave |
|
|
|
|
|
|
|
|
|
- server should be able to discard surfaces, and send a re-render |
|
|
|
|
event to clients to get them to render and provide the surface |
|
|
|
|
again. for wayland system compositor vt switcing, for example, to |
|
|
|
|
be able to throw away the surfaces in the session we're switching |
|
|
|
|
away from. for minimized windows that we don't want live thumb |
|
|
|
|
nails for. etc. |
|
|
|
|
|
|
|
|
|
- auth; We need to generate a random socket name and advertise that |
|
|
|
|
on dbus along with a connection cookie. Something like a method |
|
|
|
|
that returns the socket name and a connection cookie. The |
|
|
|
@ -127,6 +164,10 @@ |
|
|
|
|
Wayland server generates the cookie on demand when the dbus method |
|
|
|
|
is called and expires it after 5s or so. |
|
|
|
|
|
|
|
|
|
- or just pass the fd over dbus |
|
|
|
|
|
|
|
|
|
- drm bo access control, authentication, flink_to |
|
|
|
|
|
|
|
|
|
- enter/leave events from the input devices |
|
|
|
|
|
|
|
|
|
- gain, lose keyboard focus events; this event carries information |
|
|
|
@ -139,3 +180,26 @@ |
|
|
|
|
talking about 2^24 clients. That's 31 years with a new client |
|
|
|
|
every minute... Maybe just use bigger ranges, then it's feasible |
|
|
|
|
to track and garbage collect them when a client dies. |
|
|
|
|
|
|
|
|
|
- multi gpu, needs queue and seqno to wait on in requests |
|
|
|
|
|
|
|
|
|
- opaque region, window rect |
|
|
|
|
|
|
|
|
|
- save and restore state on crash, clients reconnect, re-render |
|
|
|
|
buffers |
|
|
|
|
|
|
|
|
|
- how do apps share the glyph cache? what is the glyph cache, how |
|
|
|
|
does it work? pixbuf cache? |
|
|
|
|
|
|
|
|
|
- synaptics, 3-button emulation, scim |
|
|
|
|
|
|
|
|
|
- what to do when protocol out buffer fills up? Just block on write |
|
|
|
|
would work I guess. Clients are supposed to throttle using the |
|
|
|
|
bread crumb events, so we shouldn't get into this situation. |
|
|
|
|
|
|
|
|
|
- when a surface is the size of the screen and on top, we can set the |
|
|
|
|
scanout buffer to that surface directly. Like compiz unredirect |
|
|
|
|
top-level window feature. Except it won't have any protocol state |
|
|
|
|
side-effects and the client that owns the surface won't know. We |
|
|
|
|
lose control of updates. Should work well for X server root window |
|
|
|
|
under wayland. |
|
|
|
|