- - 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
+
+ - 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
satisfies hw limitations (64x64, only one cursor), switch 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
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
- 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.