1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
Core wayland protocol
- We need rotation information in the output (multiples of 90
degress) and we'll need a way for a client to communicate that it
has rendered it's buffer according to the output rotation. The
goal is to be able to pageflip directly to the client buffer, and
for that we need the client to render accordingly and the
compositor needs to know that it did.
- Atomicity. Currently a lot of the atomicity in Wayland relies on
how we batch up all requests in a protocol buffer and only flushes
in the "blockhandler" in the client. Consensus was that we need
something more reliable and explicit. The suggestion is that we
make surface.attach a synchronization point such that everything
before that is batched and applied atomically when the
surface.attach request comes in. For cases where we need atomicity
beyond a surface.attach, we can add an atomic grouping mechanism,
that can group together multiple surface.attach requests into a
bigger atomic change. To be researched a bit.
- We should make pointer sprites regular surfaces. Something like
input_device.set_sprite(surface). This also make client side
animated cursors simple/possible, since we now get a frame event
that can drive the animation.
- Maybe try to make remote wayland actually happen, to see if there
is something in the protocol/architecute that makes it harder than
it should be.
- Key events need a bit more work/thinking/redesign. As it is we need
a mechanism to change and synchronize keymaps, repeat rates. But
as we started talking, we decided that we needed to go back and
research what other systems do instead of just essentially copying
the X model. Sending out unicode events in addition to keycode
events has a lot of benefits (OSK can send out unicode events
instead of fake keycode events, apps become much simpler...) Move
keymap handling and repeat to the server? Needs more research.
- Pointer axis events need modifiers (ctrl-scroll eg), but we either
need to send the modifier state with each axis/scroll event or send
keys down on pointer_focus and subsequent key events... or just key
events for modifier keys... or for the non-repeating subset?
- Add timestamp to touch_cancel, add touch id to touch_cancel (?)
- The output protocol needs to send all the ugly timing details for the modes.
ICCCM
- clipboard manager interface? what's needed? just notification
that the selection has gone away. should the clipboard manager be
able to take over the selection "seamlessly", ie, with the same
timestamp etc? Doesn't seem like we need that, the clipboard will
have to set a new data_source anyway, with the subset of mimetypes
it offers (the clipboad manager may only offer a subset of the
types offered by the original data_source)
The trouble is that when the clipboard manager sets a new data
source, we don't want to renew the timestamp and potentially reject
a newer "real" data source.
- 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
- we need a "no kb focus please" mechanism. Or should this be
implicit in a specific surface type?
EWMH
- configure should provide dx_left, dx_right, dy_top, dy_bottom, or
dx, dy, width and height.
- 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?
- window move and resize functionality for kb and touch.
- dnd loose ends: self-dnd: initiate dnd with a null data-source,
compositor will not offer to other clients, client has to know
internally what's offered and how to transfer data. no fd passing.
- 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.
- popup placement protocol logic.
- subsurface mechanism. we need this for cases where we would use an
X subwindow for gl or video other different visual type.
EGL/gbm
- Don't wl_display_iterate in eglSwapBuffer, send an eventfd fd?
- Land Robert Braggs EGL extensions: frame age, swap with damage
- 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.
- 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.
Misc
- glyph cache
- 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)
drm.buffer: id, name, stride etc /* event to announce cache buffer */
cache.image: hash, buffer, x, y, stride /* event to announce
* location in cache */
cache.reject: hash /* no upload for you! */
cache.retire: buffer /* cache has stopped using buffer, please
* reupload whatever you had in that buffer */
- 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.
Clients and ports
- 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...
- dnd, copy-paste
- Investigate DirectFB on Wayland (or is that Wayland on DirectFB?)
- SDL port, bnf has work in progress here:
http://cgit.freedesktop.org/~bnf/sdl-wayland/
- libva + eglimage + kms integration
Ideas
- 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:
interface "settings":
event int_value(string name, int value)
event string_value(string name, string value)
but maybe it's better to just require that clients get that from
somewhere else (gconf/dbus).
Crazy ideas
- 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:
- ioctl(wayland_fd, "surface_attach to object 5 should do a kms page
flip on ctrc 2");
- what about multiple crtcs? what about frame event for other
clients?
- forward these input devices to the client
- "scancode 124 pressed or released with scan codes 18,22 and 30
held down gives control back to userspace wayland.
- 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?
- Probably not worth it.
|
