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.
226 lines
9.4 KiB
226 lines
9.4 KiB
Core wayland protocol
|
|
|
|
- generate pointer_focus (and drag focus) on raise/lower, move
|
|
windows, all kinds of changes in surface stacking.
|
|
|
|
- glyph cache
|
|
|
|
- dnd, figure out large object transfer: through wayland protocol or
|
|
pass an fd through the compositor to the other client and let them
|
|
sort it out?
|
|
|
|
- DnD issues:
|
|
|
|
How to roboustly handle failing drag, ie the case where an
|
|
application gets a button event, tries to activate a drag, but when
|
|
the server gets the drag request, the button has already been
|
|
released and the grab is no longer active. What's the concern:
|
|
|
|
- Application may set a drag cursor that doesn't revert back,
|
|
since a failed drag doesn't result in a pointer_focus event to
|
|
give focus back to the surface. We could just do that: if the
|
|
pointer_focus is the same surface as we tried to start a grab
|
|
for, just remove and give back pointer_focus.
|
|
|
|
Alternatively, set drag cursors only in response to drag events,
|
|
like drag focus. But drag_focus and drag_motion are sent to the
|
|
drag target, so the source surface won't always get those. We
|
|
may also end up setting the cursor after the drag ends, but in
|
|
this case the drag started and ended and we'll get a
|
|
pointer_focus event, which will make the application reset the
|
|
pointer image. Could introduce a drag start event that
|
|
indicates that the drag active.
|
|
|
|
How to handle drop decline (accept with type=NULL)
|
|
|
|
- Targets must send a NULL type in accept if they don't accept a
|
|
drop at the drag_focus/drag_motion position. Root window will
|
|
send a NULL type or x-wayland/root-something type if the source
|
|
offers that.
|
|
|
|
Races between pointer motion, ending the drag, the target sending
|
|
accept request and the source receiving the target event.
|
|
|
|
- We've sent a drag focus or motion event to the source, but
|
|
haven't received an accept request corresponding to that event
|
|
and now the button is release. The compositor could wait for
|
|
the source to reply to outstanding focus/motion events before
|
|
sending the finish event to the source. Or we could send the
|
|
finish event through the source so that it needs to reply to the
|
|
finish event too. Either way, the state of the drag blocks on
|
|
the client. What if we drag to a client that doesn't doo dnd?
|
|
|
|
How do we animate the drag icon back to the drag origin in case of
|
|
a failed drag?
|
|
|
|
How to handle surfaces from clients that don't know about dnd or
|
|
don't care? Maybe the dnd object should have a
|
|
dnd.register_surface() method so clients can opt-in the surfaces
|
|
that will participate in dnd. Or just assume client is not
|
|
participating until we receive an accept request.
|
|
|
|
May need to look at all offer events before we can decide which one
|
|
to go with. Problem is, we don't know when we've seen that last
|
|
offer event.
|
|
|
|
- copy-n-paste, store data in server (only one mime-type available)
|
|
or do X style (content mime-type negotiation, but data goes away
|
|
when client quits).
|
|
|
|
- Optional pointer images.
|
|
|
|
- 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.
|
|
|
|
- Initial placement of surfaces. Guess we can do, 1)
|
|
surface-relative (menus), 2) pointer-relative (tooltips and
|
|
right-click menus) or 3) server-decides (all other top-levels).
|
|
|
|
- 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. Should be possible for yuv overlays as well.
|
|
|
|
- what about cursors then? maybe use hw cursors if the cursor
|
|
satisfies hw limitations (64x64, only one cursor), switch to
|
|
composited cursors if not.
|
|
|
|
- clients needs to allocate the surface to be suitable for
|
|
scanout, which they can do whenever they go fullscreen.
|
|
|
|
- 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, keyboard leds
|
|
|
|
- relative events
|
|
|
|
- multi touch?
|
|
|
|
- synaptics, 3-button emulation, scim
|
|
|
|
- Figure out if we need the batch/commit scheme and what to do
|
|
instead. Since dropping the "copy" request, we have a race between
|
|
copy from back to front and reporting damage. "copy" did this
|
|
atomically, but copy is a rendering operation (wayland doesn't do
|
|
rendering) and requires synchronization between server and client
|
|
before client can reuse backbuffer.
|
|
|
|
The race condition happens when a client copies new content into
|
|
its window and then, before the client reports the damage, the
|
|
compositor then does a partial repaint (triggered by another
|
|
client) that only pulls in part of the repainted area. It's only a
|
|
one-frame glitch, as the client will submit the damage and the
|
|
compositor will repaint the damaged area next frame. And ideally
|
|
clients should do all rendering as early in the frame as possible
|
|
to avoid this race.
|
|
|
|
- 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.
|
|
|
|
- Add protocol to let applications specify the effective/logical
|
|
surface rectangle, that is, the edge of the window, ignoring drop
|
|
shadows and other padding. The compositor needs this for snapping
|
|
and constraining window motion. Also, maybe communicate the opaque
|
|
region of the window (or just a conservative, simple estimate), to
|
|
let the compositor reduce overdraw.
|
|
|
|
- multi gpu, needs queue and seqno to wait on in requests
|
|
|
|
Clients and ports
|
|
|
|
- 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
|
|
|