KEYWORDS:
Wayland is a nano display server, relying on drm modesetting, gem
-batchbuffer submission and hw initialization generally in the
-kernel. Wayland is compositing manager and display server in one
-process. window management is largely pushed to the clients, they
-draw their own decorations and move and resize themselves,
-typically implemented in a library. more of the core desktop could
-be pushed into wayland, for example, stock desktop components such
-as the panel or the desktop background.
+batchbuffer submission and hw initialization generally in the kernel.
+Wayland puts the compositing manager and display server in the same
+process. Window management is largely pushed to the clients, they
+draw their own decorations and move and resize themselves, typically
+implemented in a toolkit library. More of the core desktop could be
+pushed into wayland, for example, stock desktop components such as the
+panel or the desktop background.
+
+The actual compositor will define a fair bit of desktop policy and it
+is expected that different use cases (desktop environments, devices,
+appliances) will provide their own custom compositor.
It is still designed with a windowed type of desktop in mind, as
-opposed to fullscreen-all-the-time type of interface.
+opposed to fullscreen-all-the-time type of interface, but should be
+useful wherever several processes contribute content to be composited.
-Current trends goes towards less and less rendering in X server,
-more hardware setup and management in kernel and shared libraries
-allow code sharing without putting it all in a server.
+Current trends goes towards less and less rendering in X server, more
+hardware setup and management in kernel and shared libraries allow
+code sharing without putting it all in a server. freetype,
+fontconfig, cairo all point in this direction, as does direct
+rendering mesa.
Client allocates DRM buffers, draws decorations, and full window
contents and posts entire thing to server along with dimensions.
pixman may be direct rendered which adds the cairo API, or cairo
may gain a GL backend.
-ISSUES:
-
-Include panel and desktop background in wayland?
-
-How does clients move their surfaces? set a full tri-mesh every time?
-
-How does the server apply transformations to a surface behind the
-clients back? (wobbly, minimize, zoom) Maybe wobble is client side?
-
-How do apps share the glyph cache?
-
-Input handling - keyboard focus, multiple input devices, multiple
-pointers, multi touch.
-
-Drawing cursors, moving them, cursor themes, attaching surfaces to
-cursors. How do you change cursors when you mouse over a text
-field if you don't have subwindows?
-
-synaptics, 3-button emulation, xkb, scim
-
-RMI
-
-the get_interface method is called on an object to get an object
-handle that implements the specified interface.
\ No newline at end of file
+Could be a "shell" for launching gdm X server, user session servers,
+safe mode xservers, graphics text console. From gdm, we could also
+launch a rdp session, solid ice sessions.
+
+All surface commands (copy, attach, map=set quads) are buffered until
+the client sends a commit command, which executes everything
+atomically. The commit command includes a cookie, which will be
+returned in an event generated by the server once the commit has been
+executed. This allows clients to throttle themselves against the
+server and implement smooth animations.
+
+Throttling/scheduling - there is currently no mechanism for scheduling
+clients to prevent greedy clients from spamming the server and
+starving other clients. On the other hand, now that recompositing is
+done in the idle handler (and eventually at vertical retrace time),
+there's nothing a client can do to hog the server. Unless we include
+a copyregion type request, to let a client update it's surface
+contents by asking the server to atomically copy a region from some
+other buffer to the surface buffer.
+
+Atomicity - we have the map and the attach requests which sometimes
+will have to be executed atomically. Moving the window is done using
+the map request and will not involve an attach requet. Updating the
+window contents will use an attach request but no map. Resizing,
+however, will use both and in that case must be executed atomically.
+One way to do this is to have the server always batch up requests and
+then introduce a kind of "commit" request, which will push the batched
+changes into effect. This is easier than it sounds, since we only
+have to remember the most recent map and most recent attach. The
+commit request will generate an corresponding commit event once the
+committed changes become visible on screen. The client can provide a
+bread-crumb id in the commit request, which will be sent back in the
+commit event.
+
+ - is batching+commit per client or per surface? Much more convenient
+ if per-client, since a client can batch up a bunch of stuff and get
+ atomic updates to multiple windows. Also nice to only get one
+ commit event for changes to a bunch of windows. Is a little more
+ tricky server-side, since we now have to keep a list of windows
+ with pending changes in the wl_client struct.
+
+ - batching+commit also lets a client reuse parts of the surface
+ buffer without allocating a new full-size back buffer. For
+ scrolling, for example, the client can render just the newly
+ exposed part of the page to a smaller temporary buffer, then issue
+ a copy request to copy the preserved part of the page up, and the
+ new part of the page into the exposed area.
+
+ - This does let a client batch up an uncontrolled amount of copy
+ requests that the server has to execute when it gets the commit
+ request. This could potentially lock up the server for a while,
+ leading to lost frames. Should never cause tearing though, we're
+ changing the surface contents, not the server back buffer which is
+ what is scheduled for blitting at vsync time.
projects / profile / ivi / wayland.git / blobdiff