From beed22b9a39a3f0cb793b986a01f63d4b8695590 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kristian=20H=C3=B8gsberg?= Date: Wed, 30 Sep 2009 23:14:19 -0400 Subject: [PATCH] Update TODO --- NOTES | 34 ------------------------------ TODO | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 65 insertions(+), 35 deletions(-) diff --git a/NOTES b/NOTES index 48836fe4..40569596 100644 --- a/NOTES +++ b/NOTES @@ -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 diff --git a/TODO b/TODO index 099210e2..58db146b 100644 --- a/TODO +++ b/TODO @@ -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.