Commit beed22b9 authored by Kristian Høgsberg's avatar Kristian Høgsberg

Update TODO

parent 12308a49
......@@ -45,40 +45,6 @@ returned in an event generated by the server once the commit has been
executed. This allows clients to throttle themselves against the
server and implement smooth animations.
ISSUES:
Include panel and desktop background in wayland?
How does clients move their surfaces? set a full tri-mesh every time?
How does the server apply transformations to a surface behind the
clients back? (wobbly, minimize, zoom) Maybe wobble is client side?
How do apps share the glyph cache?
Input handling - keyboard focus, multiple input devices, multiple
pointers, multi touch.
Drawing cursors, moving them, cursor themes, attaching surfaces to
cursors. How do you change cursors when you mouse over a text
field if you don't have subwindows?
synaptics, 3-button emulation, xkb, scim
changing screen resolution, adding monitors.
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.
Throttling/scheduling - there is currently no mechanism for scheduling
clients to prevent greedy clients from spamming the server and
starving other clients. On the other hand, now that recompositing is
......
- 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
- what about cursors then? maybe use hw cursors if the cursor
......@@ -13,6 +19,14 @@
- Advertise axes as part of the discovery, use something like
"org.wayland.input.x" to identify the axes.
- keyboard state, layout events at connect time and when it
changes
- relative events
- input handling - keyboard focus, multiple input devices,
multiple pointers, multi touch.
- wayland-system-compositor
- device kit/libudev/console kit integration to discover seats,
......@@ -108,10 +122,20 @@
desired data to write, if it overwrites tail, block guest. just
a socket would be easier.
- moblin as a wayland compositor
- clutter as a wayland compositors
- argh, mutter
- make libwayland-client less ghetto
- sparse based idl compiler
- crack?
- xml based description instead?
- actually make batch/commit batch up commands
- protocol for setting the cursor image
......@@ -119,6 +143,19 @@
- should we have a mechanism to attach surface to cursor for
guaranteed non-laggy drag?
- drawing cursors, moving them, cursor themes, attaching surfaces
to cursors. How do you change cursors when you mouse over a
text field if you don't have subwindows? This is what we do: a
client can set a cursor for a surface and wayland will set that
on enter and revert to default on leave
- server should be able to discard surfaces, and send a re-render
event to clients to get them to render and provide the surface
again. for wayland system compositor vt switcing, for example, to
be able to throw away the surfaces in the session we're switching
away from. for minimized windows that we don't want live thumb
nails for. etc.
- auth; We need to generate a random socket name and advertise that
on dbus along with a connection cookie. Something like a method
that returns the socket name and a connection cookie. The
......@@ -127,6 +164,10 @@
Wayland server generates the cookie on demand when the dbus method
is called and expires it after 5s or so.
- or just pass the fd over dbus
- drm bo access control, authentication, flink_to
- enter/leave events from the input devices
- gain, lose keyboard focus events; this event carries information
......@@ -138,4 +179,27 @@
we hand out a range of 256 IDs to each new clients, we're just
talking about 2^24 clients. That's 31 years with a new client
every minute... Maybe just use bigger ranges, then it's feasible
to track and garbage collect them when a client dies.
\ No newline at end of file
to track and garbage collect them when a client dies.
- multi gpu, needs queue and seqno to wait on in requests
- opaque region, window rect
- save and restore state on crash, clients reconnect, re-render
buffers
- how do apps share the glyph cache? what is the glyph cache, how
does it work? pixbuf cache?
- synaptics, 3-button emulation, scim
- 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.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment