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. cheers, Lonnie On Mon, Jul 20, 2020 at 8:07 AM Pekka Paalanen <ppaala...@gmail.com> wrote: > On Sun, 19 Jul 2020 19:55:01 -0400 > Lonnie Cumberland <lon...@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 >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
