Wayland Direct Framebuffer (FreeBSD)

Lonnie Cumberland lonnie at outstep.com
Tue Jul 21 17:17:25 UTC 2020

Hi pq,

Thanks for your question on my post and I am sorry that I was not clearer
on the information.

Yes, you are correct in that the Direct Framebuffer approach that I am
thinking about is how it might be possible to compile Weston compositor of
the Wayland protocol to use the DirectFB (direct framebuffer) backend on
FreeBSD since I am looking for a possible Wayland solution that does not
use Xorg and is absolutely as small as possible just to display a single
application "wlfreerdp" which is the Wayland compiled RDP client from the
FreeRDP project.

This is the basic goal that I am trying to achieve.

On Mon, Jul 20, 2020 at 8:07 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200721/15062ce2/attachment.htm>

More information about the wayland-devel mailing list