X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=TODO;h=8cb8d346ac73fa83a64342730561c8dfa3ae7aae;hb=a04beb1298d44ec4a6b8e14efeb36353d37445f5;hp=ac4aa98b0a4972ec2f63ef31ae6faa2ad521bac7;hpb=7f075499ead048b3d72e7ec700c775ad11d71b13;p=profile%2Fivi%2Fwayland.git diff --git a/TODO b/TODO index ac4aa98..8cb8d34 100644 --- a/TODO +++ b/TODO @@ -1,183 +1,90 @@ Core wayland protocol - - surface.set_grab_mode(GRAB_OWNER_EVENTS vs GRAB_SURFACE_EVENTS), to - make menus work right: click and drag in a menubar grabs the - pointer to the menubar (which we need for detecting motion into - another menu item), but we need events for the popup menu surface - as well. - - - The message format has to include information about number of fds - in the message so we can skip a message correctly. Or we should - just give up on trying to recover from unknown messages. We need - to make sure you never get a message from an interface you don't - know about (using per-client id space and subscribe) or include - information on number of fds, so marshalling logic can skip. - - - generate pointer_focus (and drag focus) on raise/lower, move - windows, all kinds of changes in surface stacking. + - Maybe try to make remote wayland actually happen, to see if there + is something in the protocol/architecture that makes it harder than + it should be. - - glyph cache +ICCCM - buffer = drm.create_buffer(); /* buffer with stuff in it */ + - 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 - cache.upload(buffer, x, y, width, height, int hash) + - we need a "no kb focus please" mechanism. Or should this be + implicit in a specific surface type? - drm.buffer: id, name, stride etc /* event to announce cache buffer */ +EWMH - cache.image: hash, buffer, x, y, stride /* event to announce - * location in cache */ + - configure should provide dx_left, dx_right, dy_top, dy_bottom, or + dx, dy, width and height. - cache.reject: hash /* no upload for you! */ + - 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? - cache.retire: buffer /* cache has stopped using buffer, please - * reupload whatever you had in that buffer */ + - window move and resize functionality for kb and touch. - - DnD issues: + - 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. - Root window must send NULL type (to decline drop) or - x-wayland/root-something type if the source offers that. But the - target deletes the drag_offer object when drag.pointer_focus leaves - the surface... + - popup placement protocol logic. - How do we animate the drag icon back to the drag origin in case of - a failed drag? + - subsurface mechanism. we need this for cases where we would use an + X subwindow for gl or video other different visual type. - How to handle surfaces from clients that don't know about dnd or - don't care? Maybe the dnd object should have a - dnd.register_surface() method so clients can opt-in the surfaces - that will participate in dnd. Or just assume client is not - participating until we receive an accept request. +EGL/gbm - - Selection/copy+paste issues: is it sufficient to only introduce the - selection offer when a client receives kb focus? Or maybe it is - actually a security feature? Clipboard manager in server for - retained selections? - - - 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. - - - 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. + - Land Robert Braggs EGL extensions: frame age, swap with damage - - Import relevants bits from EWMH spec, stuff like window title, - window class, app groups, icons, lower window, need attention, - fullscreen (maybe different types of fullscreen). + - 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. - - 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(): + - 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. - wl_display_subscribe(display, id, new_id, my_version); - or maybe +Misc - 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 - side-effects and the client that owns the surface won't know. We - lose control of updates. Should work well for X server root window - under wayland. Should be possible for yuv overlays as well. - - - what about cursors then? maybe use hw cursors if the cursor - satisfies hw limitations (64x64, only one cursor), switch to - composited cursors if not. - - - clients needs to allocate the surface to be suitable for - scanout, which they can do whenever they go fullscreen. - - - multihead, screen geometry and crtc layout protocol, hotplug, lcd - subpixel info - - - 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). - - - input device discovery, hotplug + - glyph cache - - Advertise axes as part of the discovery, use something like - "org.wayland.input.x" to identify the axes. + - Needs a mechanism to pass buffers to client. - - keyboard state, layout events at connect time and when it - changes, keyboard leds + buffer = drm.create_buffer(); /* buffer with stuff in it */ - - relative events + cache.upload(buffer, x, y, width, height, int hash) - - multi touch? + drm.buffer: id, name, stride etc /* event to announce cache buffer */ - - synaptics, 3-button emulation, scim + cache.image: hash, buffer, x, y, stride /* event to announce + * location in cache */ - - drm bo access control, authentication, flink_to + cache.reject: hash /* no upload for you! */ - - Range protocol may not be sufficient... if a server cycles through - 2^32 object IDs we don't have a way to handle wrapping. And since - we hand out a range of 256 IDs to each new clients, we're just - talking about 2^24 clients. That's 31 years with a new client - every minute... Maybe just use bigger ranges, then it's feasible - to track and garbage collect them when a client dies. + cache.retire: buffer /* cache has stopped using buffer, please + * reupload whatever you had in that buffer */ - - Add protocol to let applications specify the effective/logical - surface rectangle, that is, the edge of the window, ignoring drop - shadows and other padding. The compositor needs this for snapping - and constraining window motion. Also, maybe communicate the opaque - region of the window (or just a conservative, simple estimate), to - let the compositor reduce overdraw. + - 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. - - multi gpu, needs queue and seqno to wait on in requests Clients and ports @@ -191,56 +98,52 @@ Clients and ports the menu and swallows the click. without active grabs we can't swallow the click. I'm sure there much more... - - Port Qt? There's already talk about this on the list. - - - X on Wayland + - dnd, copy-paste - - move most of the code from xf86-video-intel into a Xorg wayland - module. + - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?) - - don't ask KMS for available output and modes, use the info from - the wayland server. then stop mooching off of drmmode.c. + - SDL port, bnf has work in progress here: + http://cgit.freedesktop.org/~bnf/sdl-wayland/ - - map multiple wayland input devices to MPX in Xorg. - - rootless; avoid allocating and setting the front buffer, draw - window decorations in the X server (!), how to map input? +Ideas - - gnome-shell as a wayland session compositor - - - runs as a client of the wayland session compositor, uses - clutter+egl on wayland + - 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: - - talks to an Xorg server as the compositing and window manager - for that server and renders the output to a wayland surface. - the Xorg server should be modified to take input from the system - compositor through gnome-shell, but not allocate a front buffer. + interface "settings": + event int_value(string name, int value) + event string_value(string name, string value) - - make gnome-shell itself a nested wayland server and allow native - wayland clients to connect and can native wayland windows with - the windows from the X server. + but maybe it's better to just require that clients get that from + somewhere else (gconf/dbus). - - qemu as a wayland client; session surface as X case - - qemu has too simple acceleration, so a Wayland backend like the - SDL/VNC ones it has now is trivial. +Crazy ideas - - paravirt: forward wayland screen info as mmio, expose gem ioctls as mmio + - 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: - - mapping vmem is tricky, should try to only use ioctl (pwrite+pread) + - ioctl(wayland_fd, "surface_attach to object 5 should do a kms page + flip on ctrc 2"); - - not useful for Windows without a windows paravirt driver. + - what about multiple crtcs? what about frame event for other + clients? - - two approaches: 1) do a toplevel qemu window, or 2) expose a - wayland server in the guest that forwards to the host wayland - server, ie a "remote" compositor, but with the gem buffers - shared. could do a wl_connection directly on mmio memory, with - head and tail pointers. use an alloc_head register to indicate - desired data to write, if it overwrites tail, block guest. just - a socket would be easier. + - forward these input devices to the client - - moblin as a wayland compositor + - "scancode 124 pressed or released with scan codes 18,22 and 30 + held down gives control back to userspace wayland. - - clutter as a wayland compositors + - 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? - - argh, mutter + - Probably not worth it.