Wayland Direct Framebuffer (FreeBSD)

[Pekka Paalanen]

On Sun, 19 Jul 2020 19:55:01 -0400
Lonnie Cumberland <lonnie at outstep.com> wrote:

> Hi All,
> 
> I am working on a speciality project for a super ultra-thin distro that
> will basically run just a single graphical application in a type of Kiosk
> (fullscreen) mode and Xorg is just WAY too large for what I want to do.
> 
> I am using FreeBSD and have started to look heavily into Direct Framebuffer
> (DRM) approaches.

Hi,

sorry, DRM stands for Direct Rendering Manager. Direct Framebuffer
sounds more like DirectFB [1] which is something completely
different.

Are you really talking about Xorg alone, or are you perhaps
thinking of some mainstream desktop environment when you say it's
way too large? The difference between the two can be absolutely
huge.

> With that in mind, I have just learned that Waylan may support Direct
> Framebuffers and wanted to find out more about this if possible.

What do you mean by Direct Framebuffers?

> The application that I will be using on the OS is just an RDP (or VNC)
> client and really nothing more.
> 
> My questions are if Wayland can render to the Framebuffer and also how
> large of a footprint are we talking about?

Think of Wayland as a design architecture. It's not an
implementation. For an implementation of Wayland, you need a Wayland
compositor and a Wayland client (e.g. an application using a
Wayland-supporting toolkit).

Wayland compares to X11; Xorg is a server implementation of X11.

A part of Wayland design is that the display server is a
compositor. This is unlike with Xorg where you have the option of
running the display server without a compositor. Any correctly
implemented Wayland stack will probably use more memory than a X11
stack *without* compositing, because there is necessarily
double-buffering for KMS to avoid graphical glitches.

Traditional X11 architecture is fundamentally about drawing into
the single framebuffer that is being scanned out (front-buffer
rendering). This uses the minimum amount of memory possible with the
caveat that you can see incomplete drawing on the screen at times.

Wayland OTOH bans front-buffer rendering exactly because of the
glitches, hence it needs at least one additional framebuffer
compared to a minimal X11 setup.

However, just because Wayland bans something does not mean that
some implementation cannot do exactly that. They could, if they want
to bring back the glitches that Wayland was designed to avoid.

> I started investigating DirectFB which can be loaded and am guessing that
> Wayland (if it supports FB) would be loaded on top.

I am not aware of any Wayland compositor that would run on top of
DirectFB. Most Wayland compositors use DRM/KMS instead along with
some rendering API (OpenGL, Vulkan, Pixman, QtPainter(?), etc.).

How much resources a Wayland-based stack consumes depends on the
implementation and its details on the specific hardware platform.

Some Wayland compositors: sway, weston, kwin, mutter,
enlightenment, ...

Some Wayland-spporting toolkits: Qt, GTK, SDL2, GLFW, ...


[1] https://en.wikipedia.org/wiki/DirectFB

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200720/b193d23b/attachment.sig>