Update TODO
[profile/ivi/wayland.git] / TODO
1 Core wayland protocol
2
3  - scanner: wl_* prefix removal: split it out into a namespace part so
4    we can call variables "surface" instead of "wl_surface"?
5
6  - Framebased input event delivery.
7
8  - Protocol for arbitrating access to scanout buffers (physically
9    contiguous memory).  When a client goes fullscreen (or ideally as
10    the compositor starts the animation that will make it fullscreen)
11    we send a "give up your scanout buffer" to the current fullscreen
12    client (if any) and when the client acks that we send a "try to
13    allocate a scanout buffer now" event to the fullscreen-to-be
14    client.
15
16  - Next steps based on EGL_WL_bind_display: create EGLImageKHR from
17    shm buffers? async auth in the implementation of the extension?
18
19  - wayland-egl: lazy-copy-back swapbuffer, sub-window, scanout flags
20    for fullscreen.
21
22  - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
23    dx, dy, width and height.
24
25  - surface.set_grab_mode(GRAB_OWNER_EVENTS vs GRAB_SURFACE_EVENTS), to
26    make menus work right: click and drag in a menubar grabs the
27    pointer to the menubar (which we need for detecting motion into
28    another menu item), but we need events for the popup menu surface
29    as well.
30
31  - The message format has to include information about number of fds
32    in the message so we can skip a message correctly.  Or we should
33    just give up on trying to recover from unknown messages.  We need
34    to make sure you never get a message from an interface you don't
35    know about (using per-client id space and subscribe) or include
36    information on number of fds, so marshalling logic can skip.
37
38  - generate pointer_focus (and drag focus) on raise/lower, move
39    windows, all kinds of changes in surface stacking.
40
41  - glyph cache
42
43       buffer = drm.create_buffer(); /* buffer with stuff in it */
44
45       cache.upload(buffer, x, y, width, height, int hash)
46
47       drm.buffer: id, name, stride etc /* event to announce cache buffer */
48
49       cache.image: hash, buffer, x, y, stride /* event to announce
50                                               * location in cache */
51
52       cache.reject: hash   /* no upload for you! */
53
54       cache.retire: buffer /* cache has stopped using buffer, please
55                             * reupload whatever you had in that buffer */
56
57  - DnD issues:
58
59     - Drag should not be tied to a source surface, just the client.
60       the grab will break if the surface goes away, but the wl_drag
61       struct doesn't need to hold on to the source surface.
62
63     - Root window must send NULL type (to decline drop) or
64       x-wayland/root-something type if the source offers that.  But
65       the target deletes the drag_offer object when drag.pointer_focus
66       leaves the surface...
67
68     - How do we animate the drag icon back to the drag origin in case
69       of a failed drag?  Client should set drag icon separately,
70       compositor can do it then.
71
72     - How to handle surfaces from clients that don't know about dnd or
73       don't care?  Maybe the dnd object should have a
74       dnd.register_surface() method so clients can opt-in the surfaces
75       that will participate in dnd.  Or just assume client is not
76       participating until we receive an accept request.
77
78     - Selection/copy+paste issues: is it sufficient to only introduce
79       the selection offer when a client receives kb focus?  Or maybe
80       it is actually a security feature?  Clipboard manager in server
81       for retained selections?
82
83  - Pointer image issue:
84
85     - A direct touch input device (eg touch screen) doesn't have a
86       pointer; indicate that somehow.
87
88     - Cursor themes, tie in with glyph/image cache.
89
90  - A "please suspend" event from the compositor, to indicate to an
91    application that it's no longer visible/active.  Or maybe discard
92    buffer, as in "wayland discarded your buffer, it's no longer
93    visible, you can stop updating it now.", reattach, as in "oh hey,
94    I'm about to show your buffer that I threw away, what was it
95    again?".  for wayland system compositor vt switcing, for example,
96    to be able to throw away the surfaces in the session we're
97    switching away from.  for minimized windows that we don't want live
98    thumb nails for. etc.
99
100  - Event when a surface moves from one output to another.
101
102  - input device discovery, hotplug
103
104     - Advertise axes as part of the discovery, use something like
105       "org.wayland.input.x" to identify the axes.
106
107     - keyboard state, layout events at connect time and when it
108       changes, keyboard leds
109
110     - relative events
111
112     - multi touch?
113
114     - synaptics, 3-button emulation, scim
115
116  - drm bo access control, authentication, flink_to
117
118  - Add protocol to let applications specify the effective/logical
119    surface rectangle, that is, the edge of the window, ignoring drop
120    shadows and other padding.  The compositor needs this for snapping
121    and constraining window motion.  Also, maybe communicate the opaque
122    region of the window (or just a conservative, simple estimate), to
123    let the compositor reduce overdraw.
124
125  - Protocol for specifying title bar rectangle (for moving
126    unresponsive apps) and a rectangle for the close button (for
127    detecting ignored close clicks).
128
129  - multi gpu, needs queue and seqno to wait on in requests
130
131  - libxkbcommon
132
133     - pull in actions logic from xserver
134
135     - pull in keycode to keysym logic from libX11
136
137     - expose alloc functions in libxkbcommon, drop xserver funcs?
138
139     - pull the logic to write the xkb file from xkb_desc and names
140       into libxkbcommon and just build up the new xkb_desc instead of
141       dump+parse? (XkbWriteXKBKeymapForNames followed by
142       xkb_compile_keymap_from_string in XkbDDXLoadKeymapByNames)
143
144     - pull in keysym defs as XKB_KEY_BackSpace
145
146     - figure out what other X headers we can get rid of, make it not
147       need X at all (except when we gen the keysyms).
148
149     - Sort out namespace pollution (XkbFoo macros, atom funcs etc).
150
151     - Sort out 32 bit vmods and serialization
152
153
154 Clients and ports
155
156  - port gtk+
157
158     - draw window decorations in gtkwindow.c
159
160     - Details about pointer grabs. wayland doesn't have active grabs,
161       menus will behave subtly different.  Under X, clicking a menu
162       open grabs the pointer and clicking outside the window pops down
163       the menu and swallows the click.  without active grabs we can't
164       swallow the click.  I'm sure there much more...
165
166     - dnd, copy-paste
167
168  - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?)
169
170  - SDL port, bnf has work in progress here:
171    http://cgit.freedesktop.org/~bnf/sdl-wayland/
172
173  - libva + eglimage + kms integration
174
175  - X on Wayland
176
177     - map multiple wayland input devices to MPX in Xorg.
178
179     - rootless; avoid allocating and setting the front buffer, draw
180       window decorations in the X server (!), how to map input?
181
182
183 Ideas
184
185  - A wayland settings protocol to tell clients about themes (icons,
186    cursors, widget themes), fonts details (family, hinting
187    preferences) etc.  Just send all settings at connect time, send
188    updates when a setting change.  Getting a little close to gconf
189    here, but could be pretty simple:
190
191      interface "settings":
192        event int_value(string name, int value)
193        event string_value(string name, string value)
194
195    but maybe it's better to just require that clients get that from
196    somewhere else (gconf/dbus).
197
198
199 Crazy ideas
200
201  - AF_WAYLAND - A new socket type.  Eliminate compositor context
202    switch by making kernel understand enough of wayland that it can
203    forward input events as wayland events and do page flipping in
204    response to surface_attach requests:
205
206     - ioctl(wayland_fd, "surface_attach to object 5 should do a kms page
207                          flip on ctrc 2");
208
209     - what about multiple crtcs? what about frame event for other
210       clients?
211
212     - forward these input devices to the client
213
214     - "scancode 124 pressed or released with scan codes 18,22 and 30
215        held down gives control back to userspace wayland.
216
217     - what about maintaining cursor position? what about pointer
218       acceleration?  maybe this only works in "client cursor mode",
219       where wayland hides the cursor and only sends relative events?
220       Solves the composited cursor problem.  How does X show its
221       cursor then?
222
223     - Probably not worth it.