diff options
| -rw-r--r-- | TODO | 98 |
1 files changed, 98 insertions, 0 deletions
@@ -21,6 +21,19 @@ Core wayland protocol - glyph cache + buffer = drm.create_buffer(); /* buffer with stuff in it */ + + cache.upload(buffer, x, y, width, height, int key) + + drm.buffer: id, name, stride etc /* event to announce cache buffer */ + + cache.image: key, buffer, x, y, stride /* event to announce + * location in cache */ + + cache.retire: buffer /* cache has stopped using buffer, please + * reupload whatever you had in that buffer */ + + - DnD issues: Root window must send NULL type (to decline drop) or @@ -37,6 +50,46 @@ Core wayland protocol that will participate in dnd. Or just assume client is not participating until we receive an accept request. + - Selection/copy+paste + + - Similar to dnd, create a selection object for a device to offer + selection data: + + selection = shell.create(input_device) + + Requests: + - selection.offer(type) + - selection.activate(time) + - selection.destroy() + + Events: + - selection.finish(type, fd) + - selection.discard() /* somebody else took the selection */ + + - Notes: no window owner, which seems to be mostly there as a way + to identify the client and to allow None (instead of a release + request). Possibly also to make the selection go away + automatically when the window with the contents go away, or + possibly as a way for the source to distinguish between multiple + selections. Toolkits generally just create a dummy-toplevel for + selections though. + + - Per-device selection. The selection is per device. Different + keyboards copy and paste to different selections. + + - Selection offer object. Introduced just before a surface + receives keyboard_focus event or when somebody claims the + selection and on keyboard_focus? That way only keyboard_focus + owner will know the types... limits pasting to the + keyboard_focus surface. + + Requests: + - selection_offer.receive(type, fd) + + Events: + - selection_offer.offer(type) + - selection_offer.keyboard_focus() + - Pointer image issue: - A touch input device doesn't have a pointer; indicate that @@ -60,6 +113,51 @@ Core wayland protocol surface-relative (menus), 2) pointer-relative (tooltips and right-click menus) or 3) server-decides (all other top-levels). + - Per client id space. Each client has an entire 32 bit id namespace + to itself. On the server side, each struct wl_client has an object + hash table. Object announcements use a server id space and clients + must respond with subscribe request with a client id for the + object. Part of wl_proxy_create_for_id(): + + wl_display_subscribe(display, id, new_id, my_version); + + or maybe + + wl_display_bind(display, id, new_id, my_version); + + Fixes a few things: + + - Maps the global object into the client id space, lets client + allocate the id. All ids are allocated by the client this way, + which fixes the range protocol problem. + + - Tells the server that the client is interested in events from + the object. Lets the server know that a client participates in a + certain protocol (like drag and drop), so the server can account + for whether or not the client is expected to reply + + - Server emits initial object state event(s) in reponse to + receiving the subscribe request. Introduces an extra round trip + at initialization time, but the server will still announces all + objects in one burst and the client can subscribe in a burst as + well. + + - Separates client resources, since each client will have it's own + hash table. It's not longer possible to guess the id of another + surface and access it. + + - Server must track the client id for each client an object is + exposed to. In some cases we know this (a surface is always + only owned by one client), in other cases it provides a way to + track who's interested in the object events. For input device + events, we can look up the client name when it receives pointer + focus or keyboard focus and cache it in the device. + + - Server must know which id to send when passing object references + in events. We could say that any object we're passing to a + client must have a server id, and each client has a server id -> + client id hash. + - When a surface is the size of the screen and on top, we can set the scanout buffer to that surface directly. Like compiz unredirect top-level window feature. Except it won't have any protocol state |