diff --git a/TODO b/TODO index 58db146b..bfc9c53c 100644 --- a/TODO +++ b/TODO @@ -1,12 +1,16 @@ - - 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 @@ -168,12 +172,6 @@ - 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 @@ -196,10 +194,3 @@ - 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.