mirrors/wayland
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/wayland/wayland.git synced 2025-11-16 06:59:47 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update todo

Browse source
This commit is contained in:
Kristian Høgsberg 2010-06-08 15:41:20 -04:00
parent 38bb716383
commit 0b77e0914b
1 changed files with 7 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

23
TODO
View file

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