<div dir="ltr">Hi pq,<div> </div><div>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.</div><div> </div><div>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.</div><div> </div><div>Thanks again and have a great weekend,</div><div>Lonnie</div><div> </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 31, 2020 at 9:59 AM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 21 Jul 2020 13:17:25 -0400 Lonnie Cumberland <<a href="mailto:lonnie@outstep.com" target="_blank">lonnie@outstep.com</a>> 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 <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: > > > On Sun, 19 Jul 2020 19:55:01 -0400 > > Lonnie Cumberland <<a href="mailto:lonnie@outstep.com" target="_blank">lonnie@outstep.com</a>> 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] <a href="https://en.wikipedia.org/wiki/DirectFB" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/DirectFB</a> > > > > Thanks, > > pq > > </blockquote></div>