Wayland Direct Framebuffer (FreeBSD)

Fri Jul 31 14:28:02 UTC 2020

Hi pq,

Thanks so very much for the clarification as I am totally new to the
Wayland world across all of the platforms. In the past, I have used a lot
of Linux and other similar flavors, but for this particular project, I am
jumping into the FreeBSD and illumos-based (i.e. OpenIndiana, OmniOS, and
SmartOS) world to take advantage of some of the other builtin kernel
features as well.

I will try to figure out a possible way to use Wayland with DRM KMS and to
see what it will take to get running.

Thanks again and have a great weekend,
Lonnie

On Fri, Jul 31, 2020 at 9:59 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 21 Jul 2020 13:17:25 -0400
> Lonnie Cumberland <lonnie at outstep.com> wrote:
>
> > 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.
>
> Hi,
>
> I think you should look into DRM KMS. I believe some of that has been
> ported to some BSDs from Linux, it is the display driver framework.
> Most Wayland compositors use KMS when running on bare hardware.
> DirectFB would be just an unnecessary layer in between.
>
> I didn't realize you wanted to save disk space foremost, so I explained
> things about the runtime memory usage instead.
>
> I would like to say that Wayland solutions never run on top of Xorg,
> but that is a bit of a lie. Some Wayland compositors have the
> capability to run nested, as a window, on Xorg. That mode of operation
> is not the usual one though, but merely a quick'n'dirty testing mode
> for developers whose production desktop is still on Xorg. The normal
> mode of operation is to run on bare hardware, talking "directly" to the
> kernel display drivers via DRM KMS API.
>
>
> Thanks,
> pq
>
> >
> > This is the basic goal that I am trying to achieve.
> > cheers,
> > Lonnie
> >
> >
> > 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/20200731/19f767a3/attachment-0001.htm>