Update todo
This commit is contained in:
parent
38bb716383
commit
0b77e0914b
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…
Reference in New Issue