3 - The message format has to include information about number of fds
4 in the message so we can skip a message correctly. Or we should
5 just give up on trying to recover from unknown messages.
7 - generate pointer_focus (and drag focus) on raise/lower, move
8 windows, all kinds of changes in surface stacking.
10 - make a client side circular buffer of pending ping requests with
11 callbacks and data. if buffer fills up, just iterate until an
12 entry becomes available. wl_display_ping(dpy, func, data), basically.
13 func is called when the reply comes in for the ping request.
17 - dnd, figure out large object transfer: through wayland protocol or
18 pass an fd through the compositor to the other client and let them
23 How to handle drop decline (accept with type=NULL)
25 - Targets must send a NULL type in accept if they don't accept a
26 drop at the drag_focus/drag_motion position. Root window will
27 send a NULL type or x-wayland/root-something type if the source
30 Races between pointer motion, ending the drag, the target sending
31 accept request and the source receiving the target event.
33 - We've sent a drag focus or motion event to the source, but
34 haven't received an accept request corresponding to that event
35 and now the button is release. The compositor could wait for
36 the source to reply to outstanding focus/motion events before
37 sending the finish event to the source. Or we could send the
38 finish event through the source so that it needs to reply to the
39 finish event too. Either way, the state of the drag blocks on
40 the client. What if we drag to a client that doesn't doo dnd?
42 How do we animate the drag icon back to the drag origin in case of
45 How to handle surfaces from clients that don't know about dnd or
46 don't care? Maybe the dnd object should have a
47 dnd.register_surface() method so clients can opt-in the surfaces
48 that will participate in dnd. Or just assume client is not
49 participating until we receive an accept request.
51 May need to look at all offer events before we can decide which one
52 to go with. Problem is, we don't know when we've seen that last
55 Create transient dnd object when a client starts a drag. Announce
56 the dnd object to clients first time the drag enters one of its
57 surfaces. Track if we've already announced the object by comparing
58 the drag start timestamp/serial with the clients last-event
59 timestamp/serial? Wont work if we send other events to a client
60 after creating the drag object. Maybe just keep the transient
61 object on the initiator side?
63 - Pointer image issue:
65 - A touch input device doesn't have a pointer; indicate that
70 - copy-n-paste, store data in server (only one mime-type available)
71 or do X style (content mime-type negotiation, but data goes away
74 - Discard buffer, as in "wayland discarded your buffer, it's no
75 longer visible, you can stop updating it now.", reattach, as in "oh
76 hey, I'm about to show your buffer that I threw away, what was it
77 again?". for wayland system compositor vt switcing, for example,
78 to be able to throw away the surfaces in the session we're
79 switching away from. for minimized windows that we don't want live
82 - Initial placement of surfaces. Guess we can do, 1)
83 surface-relative (menus), 2) pointer-relative (tooltips and
84 right-click menus) or 3) server-decides (all other top-levels).
86 - When a surface is the size of the screen and on top, we can set the
87 scanout buffer to that surface directly. Like compiz unredirect
88 top-level window feature. Except it won't have any protocol state
89 side-effects and the client that owns the surface won't know. We
90 lose control of updates. Should work well for X server root window
91 under wayland. Should be possible for yuv overlays as well.
93 - what about cursors then? maybe use hw cursors if the cursor
94 satisfies hw limitations (64x64, only one cursor), switch to
95 composited cursors if not.
97 - clients needs to allocate the surface to be suitable for
98 scanout, which they can do whenever they go fullscreen.
100 - multihead, screen geometry and crtc layout protocol, hotplug
102 - input device discovery, hotplug
104 - Advertise axes as part of the discovery, use something like
105 "org.wayland.input.x" to identify the axes.
107 - keyboard state, layout events at connect time and when it
108 changes, keyboard leds
114 - synaptics, 3-button emulation, scim
116 - Figure out if we need the batch/commit scheme and what to do
117 instead. Since dropping the "copy" request, we have a race between
118 copy from back to front and reporting damage. "copy" did this
119 atomically, but copy is a rendering operation (wayland doesn't do
120 rendering) and requires synchronization between server and client
121 before client can reuse backbuffer.
123 The race condition happens when a client copies new content into
124 its window and then, before the client reports the damage, the
125 compositor then does a partial repaint (triggered by another
126 client) that only pulls in part of the repainted area. It's only a
127 one-frame glitch, as the client will submit the damage and the
128 compositor will repaint the damaged area next frame. And ideally
129 clients should do all rendering as early in the frame as possible
132 - auth; We need to generate a random socket name and advertise that
133 on dbus along with a connection cookie. Something like a method
134 that returns the socket name and a connection cookie. The
135 connection cookie is just another random string that the client
136 must pass to the wayland server to become authenticated. The
137 Wayland server generates the cookie on demand when the dbus method
138 is called and expires it after 5s or so.
140 - or just pass the fd over dbus
142 - drm bo access control, authentication, flink_to
144 - Range protocol may not be sufficient... if a server cycles through
145 2^32 object IDs we don't have a way to handle wrapping. And since
146 we hand out a range of 256 IDs to each new clients, we're just
147 talking about 2^24 clients. That's 31 years with a new client
148 every minute... Maybe just use bigger ranges, then it's feasible
149 to track and garbage collect them when a client dies.
151 - Add protocol to let applications specify the effective/logical
152 surface rectangle, that is, the edge of the window, ignoring drop
153 shadows and other padding. The compositor needs this for snapping
154 and constraining window motion. Also, maybe communicate the opaque
155 region of the window (or just a conservative, simple estimate), to
156 let the compositor reduce overdraw.
158 - multi gpu, needs queue and seqno to wait on in requests
164 - eek, so much X legacy stuff there...
166 - draw window decorations in gtkwindow.c
168 - start from alexl's client-side-windows branch
170 - Details about pointer grabs. wayland doesn't have active grabs,
171 menus will behave subtly different. Under X, clicking a menu
172 open grabs the pointer and clicking outside the window pops down
173 the menu and swallows the click. without active grabs we can't
174 swallow the click. I'm sure there much more...
176 - Port Qt? There's already talk about this on the list.
180 - move most of the code from xf86-video-intel into a Xorg wayland
183 - don't ask KMS for available output and modes, use the info from
184 the wayland server. then stop mooching off of drmmode.c.
186 - map multiple wayland input devices to MPX in Xorg.
188 - rootless; avoid allocating and setting the front buffer, draw
189 window decorations in the X server (!), how to map input?
191 - gnome-shell as a wayland session compositor
193 - runs as a client of the wayland session compositor, uses
194 clutter+egl on wayland
196 - talks to an Xorg server as the compositing and window manager
197 for that server and renders the output to a wayland surface.
198 the Xorg server should be modified to take input from the system
199 compositor through gnome-shell, but not allocate a front buffer.
201 - make gnome-shell itself a nested wayland server and allow native
202 wayland clients to connect and can native wayland windows with
203 the windows from the X server.
205 - qemu as a wayland client; session surface as X case
207 - qemu has too simple acceleration, so a Wayland backend like the
208 SDL/VNC ones it has now is trivial.
210 - paravirt: forward wayland screen info as mmio, expose gem ioctls as mmio
212 - mapping vmem is tricky, should try to only use ioctl (pwrite+pread)
214 - not useful for Windows without a windows paravirt driver.
216 - two approaches: 1) do a toplevel qemu window, or 2) expose a
217 wayland server in the guest that forwards to the host wayland
218 server, ie a "remote" compositor, but with the gem buffers
219 shared. could do a wl_connection directly on mmio memory, with
220 head and tail pointers. use an alloc_head register to indicate
221 desired data to write, if it overwrites tail, block guest. just
222 a socket would be easier.
224 - moblin as a wayland compositor
226 - clutter as a wayland compositors