|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
It is still designed with a windowed type of desktop in mind, as
|
|
|
|
opposed to fullscreen-all-the-time type of interface.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Everything is direct rendered and composited. No cliprects, no
|
|
|
|
drawing api/protocl between server and client. No
|
|
|
|
pixmaps/windows/drawables, only surfaces (essentially pixmaps). No
|
|
|
|
gcs/fonts, no nested windows. OpenGL is already direct rendered,
|
|
|
|
pixman may be direct rendered which adds the cairo API, or cairo
|
|
|
|
may gain a GL backend.
|
|
|
|
|
|
|
|
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...
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
changing screen resolution, adding monitors.
|
|
|
|
|
|
|
|
What to do when protocol out buffer fills up? Just block on write
|
|
|
|
would work I guess. Clients are supposed to throttle using the bread
|
|
|
|
crumb events, so we shouldn't get into this situation.
|
|
|
|
|
|
|
|
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 unctrolled 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.
|
|
|
|
|
|
|
|
|
|
|
|
RMI
|
|
|
|
|
|
|
|
The wayland protocol is a async object oriented protocol. All
|
|
|
|
requests are method invocations on some object. The request include
|
|
|
|
an object id that uniquely identifies an object on the server. Each
|
|
|
|
object implements an interface and the requests include an opcode that
|
|
|
|
identifies which method in the interface to invoke.
|
|
|
|
|
|
|
|
The server sends back events to the client, each event is emitted from
|
|
|
|
an object. Events can be error conditions. The event includes the
|
|
|
|
object id and the event opcode, from which the client can determine
|
|
|
|
the type of event. Events are generated both in repsonse to a request
|
|
|
|
(in which case the requet and the event constitutes a round trip) or
|
|
|
|
spontanously when the server state changes.
|
|
|
|
|
|
|
|
the get_interface method is called on an object to get an object
|
|
|
|
handle that implements the specified interface.
|