Core wayland protocol
- - scanner: wl_* prefix removal: split it out into a namespace part so
- we can call variables "surface" instead of "wl_surface"?
-
- - 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
+ is something in the protocol/architecture that makes it harder than
it should be.
- - Reconsider data types for coordinates in events. double, floats or
- fixed point. Transformed and/or accelerated input generates
- sub-pixel positions. 24.8 fixed point could work. Need to think
- about the range of coordinates we need. Different from X problem,
- since we don't have sub-windows, which is where X hits the 16 bit
- limitations. Monitor and window sizes haven't yet out-grown the 16
- bit range.
-
- - 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?
-
- - Input protocol restructuring: break up events into wl_pointer
- (enter/leave/motion/button/axis events, set_pointer_surface
- request), wl_keyboard (enter/leave/key events... what
- else... unicode event, set_map request? pending kb work), and
- wl_touch (down/up/motion/cancel events) interfaces. Rename
- wl_input_device to wl_seat. wl_seat has zero or one of each, and
- will announce this at bind time. Raw devices are also tied to a
- wl_seat, but we may not do that for 1.0, we just need to make sure
- wl_seat has a forward compatible way to announce them.
-
- - 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)
-
- 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
- - TRANSIENT_FOR handled by wl_shell_surface, WM_CLASS replaced by
- .desktop file filename (absolute path if non-standard location)
- WM_CLASS used for grouping windows in one button in a panel, for
- example. So we'll need a request to set that.
-
- we need a "no kb focus please" mechanism. Or should this be
implicit in a specific surface type?
- configure should provide dx_left, dx_right, dy_top, dy_bottom, or
dx, dy, width and height.
- - _NET_WM_NAME (shell_surface.set_title(utf8)), _NET_WM_ICON Is this
- just another wl_surface? Do we need this if we have the .desktop
- file? How to set multiple sizes?
-
- 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
- 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
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.
allocate a scanout buffer now" event to the fullscreen-to-be
client.
+
Misc
- glyph cache
switching away from. for minimized windows that we don't want live
thumb nails for. etc.
-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
- SDL port, bnf has work in progress here:
http://cgit.freedesktop.org/~bnf/sdl-wayland/
- - libva + eglimage + kms integration
-
Ideas
projects / profile / ivi / wayland.git / blobdiff