|
|
@ -1,12 +1,16 @@ |
|
|
|
- sync-to-vblank |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- how does clients move their surfaces? set a full tri-mesh every |
|
|
|
- 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 |
|
|
|
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 |
|
|
|
do the fancy stuff. How does the server apply transformations to a |
|
|
|
surface behind the clients back? (wobbly, minimize, zoom) Maybe |
|
|
|
surface behind the clients back? (wobbly, minimize, zoom) Maybe |
|
|
|
wobble is client side? |
|
|
|
wobble is client side? |
|
|
|
|
|
|
|
|
|
|
|
- switch scanout when top surface is full screen |
|
|
|
|
|
|
|
|
|
|
|
- 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. |
|
|
|
|
|
|
|
|
|
|
|
- what about cursors then? maybe use hw cursors if the cursor |
|
|
|
- what about cursors then? maybe use hw cursors if the cursor |
|
|
|
satisfies hw limitations (64x64, only one cursor), switch to |
|
|
|
satisfies hw limitations (64x64, only one cursor), switch to |
|
|
@ -168,12 +172,6 @@ |
|
|
|
|
|
|
|
|
|
|
|
- drm bo access control, authentication, flink_to |
|
|
|
- drm bo access control, authentication, flink_to |
|
|
|
|
|
|
|
|
|
|
|
- enter/leave events from the input devices |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- gain, lose keyboard focus events; this event carries information |
|
|
|
|
|
|
|
about which keys are currently held down as a surface gains focus |
|
|
|
|
|
|
|
so the client can deduce modifier state. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Range protocol may not be sufficient... if a server cycles through |
|
|
|
- Range protocol may not be sufficient... if a server cycles through |
|
|
|
2^32 object IDs we don't have a way to handle wrapping. And since |
|
|
|
2^32 object IDs we don't have a way to handle wrapping. And since |
|
|
|
we hand out a range of 256 IDs to each new clients, we're just |
|
|
|
we hand out a range of 256 IDs to each new clients, we're just |
|
|
@ -196,10 +194,3 @@ |
|
|
|
- what to do when protocol out buffer fills up? Just block on write |
|
|
|
- what to do when protocol out buffer fills up? Just block on write |
|
|
|
would work I guess. Clients are supposed to throttle using the |
|
|
|
would work I guess. Clients are supposed to throttle using the |
|
|
|
bread crumb events, so we shouldn't get into this situation. |
|
|
|
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. |
|
|
|
|
|
|
|