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
pgpXWjuJ7lK47.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
