Update todo

dev
Kristian Høgsberg 15 years ago
parent 38bb716383
commit 0b77e0914b
  1. 23
      TODO

23
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.

Loading…
Cancel
Save