diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 66 |
1 files changed, 65 insertions, 1 deletions
@@ -1,5 +1,11 @@ - 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. |