summaryrefslogtreecommitdiff
path: root/TODO
blob: 2d24e76c509b42e788b9052130b2649128f42845 (plain)
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
Core wayland protocol

 - scanner: wl_* prefix removal: split it out into a namespace part so
   we can call variables "surface" instead of "wl_surface"?

 - 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.

 - Next steps based on EGL_WL_bind_display: create EGLImageKHR from
   shm buffers? async auth in the implementation of the extension?

 - wayland-egl: lazy-copy-back swapbuffer, sub-window.

 - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
   dx, dy, width and height.

 - 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 */

 - Pointer image issue:

    - A direct touch input device (eg touch screen) doesn't have a
      pointer; indicate that somehow.

    - Cursor themes, tie in with glyph/image cache.

 - 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.

 - Event when a surface moves from one output to another.

 - 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

 - multi gpu, needs queue and seqno to wait on in requests

Destkop/EWMH type protocol

 - Protocol for specifying title bar rectangle (for moving
   unresponsive apps) and a rectangle for the close button (for
   detecting ignored close clicks).

libxkbcommon

  - pull in actions logic from xserver

  - pull in keycode to keysym logic from libX11

  - expose alloc functions in libxkbcommon, drop xserver funcs?

  - pull the logic to write the xkb file from xkb_desc and names into
    libxkbcommon and just build up the new xkb_desc instead of
    dump+parse? (XkbWriteXKBKeymapForNames followed by
    xkb_compile_keymap_from_string in XkbDDXLoadKeymapByNames)

  - pull in keysym defs as XKB_KEY_BackSpace

  - figure out what other X headers we can get rid of, make it not
    need X at all (except when we gen the keysyms).

  - Sort out namespace pollution (XkbFoo macros, atom funcs etc).

  - Sort out 32 bit vmods and serialization


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.