So I would like to create a compositor for wayland which supports 3D effects for windows(something resembling compiz, but on wayland). I already saw this question: Where do I start if I want to write a wayland compositor? but the only answer points to SWC(https://github.com/michaelforney/swc), which is not applicable in my case as I want to use OpenGL and because SWC doesn't support 3D easily. So is there some project/library/book/tutorial/etc where I can learn the necessary things for writing my own WM on wayland? Thanks in advance.
The only purpose of the wayland protocol is the communication between client and server. The server provides the client with input events and the client provides the server with a buffer (that can be mapped to an OpenGL texture). Where the server/compositor gets its input events from and what it does with the buffer is completely up to the compositor.
So the compositor itself needs a source for input events and a way to draw its result. That's why many wayland compositors have multiple backends: they can run on top of X11, directly on top of the Linux kernel or even on top on another wayland server.
The answer to your question really depends on where you want to run your compositor. Writing a compositor that runs on top of X11 might be the easiest way to get started if you're already familiar with how to get an OpenGL app up and running there. If you want to run your compositor directly on top of the Linux kernel you'd probably want to look into evdev and libinput for input and DRM/KMS together with EGL on top of GBM in order to create an OpenGL context and show the result on your monitor. There are also rendering libraries (e.g. evas) that can run directly on top of the Linux kernel but I don't know how far they let you inject your own OpenGL code.
Once you have decided where you want to run your compositor you can start by just writing a regular OpenGL app and then go on and integrate a wayland server in order to display and interact with actual client windows.
Related
I understand that in Linux a windowing system (X11, Wayland etc.) is responsible for rendering applications on the screen. I experimented with X11 but never got past obtaining single windows. I also read about Wayland. My question is, if I want to write an application that grabs whatever is shown on the screen, is there a way to get it on such a low-level (drm, dri, kms) that I am not dependent on the windowing system? What choices do these low-level APIs give me compared to the windowing system?
EDIT: I realized reading this that "One of the features of Wayland is its security design, which helps to guard the user against malicious apps. Apps can no longer see everything on the screen and spy on you. But that also means you cannot run a common application (like shutter or gtk-recordmydesktop) and use it to make a screenshot or a screencast of your desktop".
I am trying to make an embedded system that is basically a graphical app running on Raspberry Pi with a touchscreen. It seems that Wayland is the best choice, but the documentation for it is lacking at best and uncomprehensible, outdated and awful at worst.
Therefore I'm asking here, how does one make the most basic implementation of Wayland that will allow me to just launch a single fullscreen app and basically draw and rotate a model?
I'm already familliar with OpenGL from using WebGL, so what I need the most is the Wayland part of things.
I am trying to understand Wayland protocol but can't grasp that a window manager tells display server where each windows are. So is display server a renderer or compositor?
I've been searching for the answer myself for quite some time now as well.
I will try to provide a partial answer.
Reading the official docs it seems to me that, using the wayland protocol, the display server, window manager, and the compositor become one single program.
For example, xorg is a display server, i3 is a window manager, picom is a compositor but sway is all three.
I've got the idea that in old days, XFree86 used /dev/fb* framebuffer devices. But now looks like the GUI system uses OpenGL, which is an open standard. So is OpenGL the lowest level open API? By 'open', I mean no obscure private ioctl or closed-source stuff.
Update:
I've got what I need after discussions with #datenwolf, who also provides a great answers.
In case anyone wants more coding detail: The X server driver is the lowest common level for the X system on top of any GPUs. To know what kind of interface an X server driver must implement: refer to DDX Design, it is a detailed doc for the latest X.org that tells you how to write an X driver.
In Linux there is no "lowest level API" exposed by the kernel that does graphics operations. All graphics drivers are actually implemented in the user space by so called "state trackers", which use special kernel functions to talk directly with the graphics hardware¹. The open source drivers implemented as part of the Mesa project use the Linux specific DRM API to talk to the hardware. The proprietary drivers from NVidia and AMD each use their very specific kernel module instead.
Now when it comes to end program usability Mesa and the proprietary drivers differ a bit:
NVidia's and AMD/ATI's proprietary drivers offer no API at all to end user programs to use for. Instead they're implemented as modules to load by the X server; the X server expects the driver modules to follow a specific scheme, which usually changes with major changes in the X server, so each X server major version bump usually required to update the driver modules as well.
The X server in turn provides a well known command stream based graphics API. Graphics commands sent over this API are scheduled by the X server and dispatched into called to the right functions of the driver module. The driver module in turn contains the whole intelligence for talking with the GPU and turns the commands coming from the X server into commands toward the GPU.
So to speak the X server is the lowest level universal graphics API currently available to Linux programs (except for programs that would go the length to implement everything to use the X driver modules directly).
When it comes to X11, the drivers that are part of the Mesa project are no different than the proprietary drivers. However because Mesa is open source its developers began implementing ways that programs could use Mesa and its drivers directly without having talk to it through the X server. For that they choose to expose an API conformant with the EGL specification. Unfortunately EGL is rather useless on its own because it requires an external display system to be present (or you can do only off-screen rendering).
This is where Wayland enters the picture. Wayland is not a display system. It is however a protocol that allows the building blocks of a display system to talk with each other. One central component of a Wayland based display system is the compositor which actually takes hold of the so called "seat" (= display device and associated input devices). Programs that want to display something on the screen use Wayland to open a connection with the compositor, which gives them a display to use EGL on. That they then can use to create actual drawing surfaces to do their graphics on.
[1]: Actually for some drivers (of legacy hardware) the X server must be started with root privileges, so that it can use the special function ioperm(…) to gain direct access to the hardware using the out*(…) and in*(…) functions and open /dev/mem for memory access. In this case there is zero support by the kernel regarding the communication with the graphics hardware. But for security and performance reasons nobody does (program) that anymore.
DRM and KMS, at least for the open-source driver stacks.
You need to build your own GPU-accelerated renderer, or use GLX
The lowest level access to the GPU is via X renderering backends.
The lowest level backend available to X is GLX.
GLX renders X directly to the GPU-accelerated OpenGL pipeline.
The default framebuffered xrender backend is unaccelerated.
Compton is an opensource compositor for X that uses the GLX backend.
It is a good example of using OpenGL to accelerate X.
GLX should be getting bindings for Vulkan, providing multiple OpenGL pipelines.
GLX only accelerates X in 2D, because X is a 2D app.
For 3D apps, a custom renderer is required.
The DRM GPU driver.
is the open...
And if so why? What does X do for me beyond piping my rendering commands to the graphics card driver?
I'm not clear on the relationship X - OpenGL. I've searched the internet but couldn't find a concise answer.
If it matters, assuming a minimal modern distribution, like a headless Ubuntu 13 machine.
With the current drivers: Yes.
And if so why?
Because the X server is the host for the actual graphics driver talking to the GPU. At the moment Linux GPU drivers require a X server that gives them an environment to live in and a channel to the kernel interfaces to talk through with the GPU.
On the DRI/DRM/Gallium front a new driver model has been created that allows to use the GPU without an X server, for example using the EGL-API. However only a small range of GPUs is supported by this right now; most Intel and AMD; none NVidia.
I'm not clear on the relationship X - OpenGL
I covered that in detail in the SO answers found at https://stackoverflow.com/a/7967211/524368 and https://stackoverflow.com/a/8777891/524368
In short the X server acts like a "proxy" to the GPU. You send the X server commands like "open a window" or "draw a line there". And there's an extension to the X protocol called "GLX", where each OpenGL command gets translated into a stream of GLX/X opcodes and the X server executes those commands on the GPU on behalf of the calling client. Also most OpenGL/GLX implementations provide a mechanism to bypass the X server if the client process could actually talk directly to the GPU (because it runs on the same machine as the X server and has permissions to access the kernel API); that is called Direct Rendering. It however still requires the X server for opening the window, creating the context and to general housekeeping.
Update due to comment
Also if you can live without GPU acceleration, you can use Mesa3D using the osmesa (off-screen mesa) mode and the LLVMpipe software rasterizer.
With Linux 3.12: Not any more.
Offscreen rendering is what DRM render nodes are for, according to the commit. See the developer's blog for a better explanation.
TLDR:
A render node (/dev/dri/renderD<num>) appears as a GPU with no screens attached.
As for how exactly one is supposed to make use of this, the (kernel) developer only has very general advice for userspace infrastructure. Nevertheless, it is fair to assume the feature to be nothing short of a show-enabler for Wayland and Mir, as clients won't be able to render on-screen any more.
The wikipedia entry has some more pointers.