- - sync-to-vblank
+Core wayland protocol
- - switch scanout when top surface is full screen
+ - 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.
- - what about cursors then? maybe use hw cursors if the cursor
- satisfies hw limitations (64x64, only one cursor), switch to
- composited cursors if not.
+ICCCM
- - multihead, screen geometry and crtc layout protocol, hotplug
+ - 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
- - input device discovery, hotplug
+ - we need a "no kb focus please" mechanism. Or should this be
+ implicit in a specific surface type?
- - Advertise axes as part of the discovery, use something like
- "org.wayland.input.x" to identify the axes.
+EWMH
- - wayland-system-compositor
+ - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
+ dx, dy, width and height.
- - 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.
+ - 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?
- - send drm device in connection info, probably just udev path.
+ - window move and resize functionality for kb and touch.
- - cairo-drm; wayland needs cairo-drm one way or another:
+ - 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.
- - chris wilson (ickle) is doing cairo-drm for i915 now, basically
- the pixman-drm idean, but inside cairo instead.
+ - popup placement protocol logic.
- - 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.
+ - subsurface mechanism. we need this for cases where we would use an
+ X subwindow for gl or video other different visual type.
- - use open gl behind the scenes a la glitz.
+EGL/gbm
- - should be possible to provide a realistic api and then stub out
- the implementation with pwrite and pread so gtk+ port can proceed.
+ - Land Robert Braggs EGL extensions: frame age, swap with damage
- - 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.
+ - 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.
- - port gtk+
+ - 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.
- - eek, so much X legacy stuff there...
- - draw window decorations in gtkwindow.c
+Misc
- - start from alexl's client-side-windows branch
+ - glyph cache
- - 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...
+ - Needs a mechanism to pass buffers to client.
+
+ buffer = drm.create_buffer(); /* buffer with stuff in it */
+
+ cache.upload(buffer, x, y, width, height, int hash)
- - Port Qt? There's already talk about this on the list.
+ drm.buffer: id, name, stride etc /* event to announce cache buffer */
- - X on Wayland
+ cache.image: hash, buffer, x, y, stride /* event to announce
+ * location in cache */
- - move most of the code from xf86-video-intel into a Xorg wayland
- module.
+ cache.reject: hash /* no upload for you! */
- - don't ask KMS for available output and modes, use the info from
- the wayland server. then stop mooching off of drmmode.c.
+ cache.retire: buffer /* cache has stopped using buffer, please
+ * reupload whatever you had in that buffer */
- - map multiple wayland input devices to MPX in Xorg.
+ - 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.
- - rootless; avoid allocating and setting the front buffer, draw
- window decorations in the X server (!), how to map input?
- - gnome-shell as a wayland session compositor
+Clients and ports
- - runs as a client of the wayland session compositor, uses
- clutter+egl on wayland
+ - port gtk+
+
+ - draw window decorations in gtkwindow.c
+
+ - 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...
- - 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.
+ - dnd, copy-paste
- - 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.
+ - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?)
- - qemu as a wayland client; session surface as X case
+ - SDL port, bnf has work in progress here:
+ http://cgit.freedesktop.org/~bnf/sdl-wayland/
- - qemu has too simple acceleration, so a Wayland backend like the
- SDL/VNC ones it has now is trivial.
- - paravirt: forward wayland screen info as mmio, expose gem ioctls as mmio
+Ideas
- - mapping vmem is tricky, should try to only use ioctl (pwrite+pread)
+ - 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:
- - not useful for Windows without a windows paravirt driver.
+ interface "settings":
+ event int_value(string name, int value)
+ event string_value(string name, string value)
- - 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.
+ but maybe it's better to just require that clients get that from
+ somewhere else (gconf/dbus).
- - make libwayland-client less ghetto
- - sparse based idl compiler
+Crazy ideas
- - actually make batch/commit batch up commands
+ - 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:
- - protocol for setting the cursor image
+ - ioctl(wayland_fd, "surface_attach to object 5 should do a kms page
+ flip on ctrc 2");
- - should we have a mechanism to attach surface to cursor for
- guaranteed non-laggy drag?
+ - what about multiple crtcs? what about frame event for other
+ clients?
- - 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.
+ - forward these input devices to the client
- - enter/leave events from the input devices
+ - "scancode 124 pressed or released with scan codes 18,22 and 30
+ held down gives control back to userspace wayland.
- - 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.
+ - 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?
- - 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.
\ No newline at end of file
+ - Probably not worth it.
projects / profile / ivi / wayland.git / blobdiff