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 <ppaala...@gmail.com> wrote: > On Tue, 21 Jul 2020 13:17:25 -0400 > Lonnie Cumberland <lon...@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 <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