- - 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?
+Core wayland protocol
+ - Maybe try to make remote wayland actually happen, to see if there
+ is something in the protocol/architecture that makes it harder than
+ it should be.
- - 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.
+ICCCM
- - what about cursors then? maybe use hw cursors if the cursor
- satisfies hw limitations (64x64, only one cursor), switch to
- composited cursors if not.
+ - mime-type guidelines for data_source (ie, both dnd and selection):
+ recommended types for text or images, types that a clipboard
+ manager must support, mime-types must be listed in preferred order
- - multihead, screen geometry and crtc layout protocol, hotplug
+ - we need a "no kb focus please" mechanism. Or should this be
+ implicit in a specific surface type?
- - input device discovery, hotplug
+EWMH
- - Advertise axes as part of the discovery, use something like
- "org.wayland.input.x" to identify the axes.
+ - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
+ dx, dy, width and height.
- - keyboard state, layout events at connect time and when it
- changes
+ - move to workspace, keep on top, on all workspaces, minimize etc
+ requests for implementing client side window menu? or just make a
+ "show window menu" request to let the compositor display and manage
+ a popup window?
- - relative events
+ - window move and resize functionality for kb and touch.
- - input handling - keyboard focus, multiple input devices,
- multiple pointers, multi touch.
+ - Protocol for specifying title bar rectangle (for moving
+ unresponsive apps). Rectangle for close button, so we can popup
+ force-close dialog if application doesn't respond to ping event
+ when user clicks there. We could use the region mechanism here
+ too.
- - wayland-system-compositor
+ - popup placement protocol logic.
- - device kit/libudev/console kit integration to discover seats,
- that is, groups of input devices and outputs that provide a
- means for one user to interact with the system. That is,
- typically a mouse, keyboard and a screen. The input devices
- will just be evdev devices, the outputs will be a drm device
- filename and the specific outputs accessible throught that drm
- device.
+ - subsurface mechanism. we need this for cases where we would use an
+ X subwindow for gl or video other different visual type.
- - send drm device in connection info, probably just udev path.
+EGL/gbm
- - cairo-drm; wayland needs cairo-drm one way or another:
+ - Land Robert Braggs EGL extensions: frame age, swap with damage
- - chris wilson (ickle) is doing cairo-drm for i915 now, basically
- the pixman-drm idean, but inside cairo instead.
+ - Make it possible to share buffers from compositor to clients.
+ Tricky part here is how to indicate to EGL on the server side that
+ it should make an EGLImage available to a client. We'll need a
+ "create a wl_buffer for this EGLImage for this client" kind of
+ entry point.
- - pixman-drm; move the ddx driver batchbuffer logic into libdrm
- and write native, direct rendering acceleration code in
- pixman-drm. is a clean approach in that we avoid the mess of
- the global GL context leaking through to applications, and we
- can bootstrap this project by pulling in the EXA hooks from the
- DDX drivers.
+ - Protocol for arbitrating access to scanout buffers (physically
+ contiguous memory). When a client goes fullscreen (or ideally as
+ the compositor starts the animation that will make it fullscreen)
+ we send a "give up your scanout buffer" to the current fullscreen
+ client (if any) and when the client acks that we send a "try to
+ allocate a scanout buffer now" event to the fullscreen-to-be
+ client.
- - use open gl behind the scenes a la glitz.
- - should be possible to provide a realistic api and then stub out
- the implementation with pwrite and pread so gtk+ port can proceed.
+Misc
- - XKB like client side library for translating keyboard events to
- more useful keycodes and modifiers etc. Will probably be shared
- between toolkits as a low-level library.
+ - glyph cache
- - port gtk+
-
- - eek, so much X legacy stuff there...
-
- - draw window decorations in gtkwindow.c
-
- - start from alexl's client-side-windows branch
-
- - Details about pointer grabs. wayland doesn't have active grabs,
- menus will behave subtly different. Under X, clicking a menu
- open grabs the pointer and clicking outside the window pops down
- the menu and swallows the click. without active grabs we can't
- swallow the click. I'm sure there much more...
-
- - Port Qt? There's already talk about this on the list.
-
- - X on Wayland
-
- - move most of the code from xf86-video-intel into a Xorg wayland
- module.
+ - Needs a mechanism to pass buffers to client.
- - don't ask KMS for available output and modes, use the info from
- the wayland server. then stop mooching off of drmmode.c.
+ buffer = drm.create_buffer(); /* buffer with stuff in it */
- - map multiple wayland input devices to MPX in Xorg.
+ cache.upload(buffer, x, y, width, height, int hash)
- - rootless; avoid allocating and setting the front buffer, draw
- window decorations in the X server (!), how to map input?
+ drm.buffer: id, name, stride etc /* event to announce cache buffer */
- - gnome-shell as a wayland session compositor
+ cache.image: hash, buffer, x, y, stride /* event to announce
+ * location in cache */
- - runs as a client of the wayland session compositor, uses
- clutter+egl on wayland
+ cache.reject: hash /* no upload for you! */
- - talks to an Xorg server as the compositing and window manager
- for that server and renders the output to a wayland surface.
- the Xorg server should be modified to take input from the system
- compositor through gnome-shell, but not allocate a front buffer.
+ cache.retire: buffer /* cache has stopped using buffer, please
+ * reupload whatever you had in that buffer */
- - make gnome-shell itself a nested wayland server and allow native
- wayland clients to connect and can native wayland windows with
- the windows from the X server.
+ - A "please suspend" event from the compositor, to indicate to an
+ application that it's no longer visible/active. Or maybe discard
+ buffer, as in "wayland discarded your buffer, it's no longer
+ visible, you can stop updating it now.", reattach, as in "oh hey,
+ I'm about to show your buffer that I threw away, what was it
+ 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.
- - qemu as a wayland client; session surface as X case
- - qemu has too simple acceleration, so a Wayland backend like the
- SDL/VNC ones it has now is trivial.
+Clients and ports
- - paravirt: forward wayland screen info as mmio, expose gem ioctls as mmio
-
- - mapping vmem is tricky, should try to only use ioctl (pwrite+pread)
-
- - not useful for Windows without a windows paravirt driver.
-
- - two approaches: 1) do a toplevel qemu window, or 2) expose a
- wayland server in the guest that forwards to the host wayland
- server, ie a "remote" compositor, but with the gem buffers
- shared. could do a wl_connection directly on mmio memory, with
- head and tail pointers. use an alloc_head register to indicate
- 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
+ - port gtk+
- - make libwayland-client less ghetto
+ - draw window decorations in gtkwindow.c
- - sparse based idl compiler
+ - Details about pointer grabs. wayland doesn't have active grabs,
+ menus will behave subtly different. Under X, clicking a menu
+ open grabs the pointer and clicking outside the window pops down
+ the menu and swallows the click. without active grabs we can't
+ swallow the click. I'm sure there much more...
- - crack?
+ - dnd, copy-paste
- - xml based description instead?
+ - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?)
- - actually make batch/commit batch up commands
+ - SDL port, bnf has work in progress here:
+ http://cgit.freedesktop.org/~bnf/sdl-wayland/
- - protocol for setting the cursor image
- - should we have a mechanism to attach surface to cursor for
- guaranteed non-laggy drag?
+Ideas
- - 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
+ - A wayland settings protocol to tell clients about themes (icons,
+ cursors, widget themes), fonts details (family, hinting
+ preferences) etc. Just send all settings at connect time, send
+ updates when a setting change. Getting a little close to gconf
+ here, but could be pretty simple:
- - 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.
+ interface "settings":
+ event int_value(string name, int value)
+ event string_value(string name, string value)
- - 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
- connection cookie is just another random string that the client
- must pass to the wayland server to become authenticated. The
- Wayland server generates the cookie on demand when the dbus method
- is called and expires it after 5s or so.
+ but maybe it's better to just require that clients get that from
+ somewhere else (gconf/dbus).
- - or just pass the fd over dbus
- - drm bo access control, authentication, flink_to
+Crazy ideas
- - 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
- 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.
+ - AF_WAYLAND - A new socket type. Eliminate compositor context
+ switch by making kernel understand enough of wayland that it can
+ forward input events as wayland events and do page flipping in
+ response to surface_attach requests:
- - multi gpu, needs queue and seqno to wait on in requests
+ - ioctl(wayland_fd, "surface_attach to object 5 should do a kms page
+ flip on ctrc 2");
- - opaque region, window rect
+ - what about multiple crtcs? what about frame event for other
+ clients?
- - save and restore state on crash, clients reconnect, re-render
- buffers
+ - forward these input devices to the client
- - how do apps share the glyph cache? what is the glyph cache, how
- does it work? pixbuf cache?
+ - "scancode 124 pressed or released with scan codes 18,22 and 30
+ held down gives control back to userspace wayland.
- - synaptics, 3-button emulation, scim
+ - what about maintaining cursor position? what about pointer
+ acceleration? maybe this only works in "client cursor mode",
+ where wayland hides the cursor and only sends relative events?
+ Solves the composited cursor problem. How does X show its
+ cursor then?
- - 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.
+ - Probably not worth it.