You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
196 lines
7.4 KiB
196 lines
7.4 KiB
- 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?
|
|
|
|
|
|
- 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.
|
|
|
|
- what about cursors then? maybe use hw cursors if the cursor
|
|
satisfies hw limitations (64x64, only one cursor), switch to
|
|
composited cursors if not.
|
|
|
|
- multihead, screen geometry and crtc layout protocol, hotplug
|
|
|
|
- input device discovery, hotplug
|
|
|
|
- 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,
|
|
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.
|
|
|
|
- send drm device in connection info, probably just udev path.
|
|
|
|
- cairo-drm; wayland needs cairo-drm one way or another:
|
|
|
|
- chris wilson (ickle) is doing cairo-drm for i915 now, basically
|
|
the pixman-drm idean, but inside cairo instead.
|
|
|
|
- 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.
|
|
|
|
- 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.
|
|
|
|
- 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.
|
|
|
|
- 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.
|
|
|
|
- don't ask KMS for available output and modes, use the info from
|
|
the wayland server. then stop mooching off of drmmode.c.
|
|
|
|
- map multiple wayland input devices to MPX in Xorg.
|
|
|
|
- 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
|
|
|
|
- runs as a client of the wayland session compositor, uses
|
|
clutter+egl on wayland
|
|
|
|
- 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.
|
|
|
|
- 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.
|
|
|
|
- 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.
|
|
|
|
- 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
|
|
|
|
- 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
|
|
|
|
- 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
|
|
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.
|
|
|
|
- or just pass the fd over dbus
|
|
|
|
- drm bo access control, authentication, flink_to
|
|
|
|
- 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.
|
|
|
|
- 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.
|
|
|