AMA about Wayland or the Linux graphics stack, technical or otherwise

(standing offer)

@sir how do i deal with gnome-shell process leaking memory

@sir are there guides for setting it up on ubuntu?

What resources would you recommend to people looking to learn more about the Linux graphics stack?

@hannibal_ad_portas depends on what you're looking for. If you're a kernel hacker writing new GPU drivers, that's one domain. If you're writing a Wayland compositor, that's another. If you're writing video games and want to optimize your shaders, that's yet another. What are you interested in?

@hannibal_ad_portas you'll be interacting with the DRM/KMS and GBM subsystems. My friend Scott has written some early docs on this from the userspace perspective:

But unfortunately your best bet is to read existing implementations. Here's the wlroots DRM backend:

It may also be helpful to reference libdrm and the kernel drivers:

That is, if you're interested in the graphics infrastructure. If you're just interested in writing a Wayland compositor and less so in the deep technical work, check out wlroots:

@sir so, for those of us whose laptops have external outputs hardwired to an Nvidia card... is nouveau an option if we want to use Wayland with an external screen?

@necaris it depends on your GPU, older GPUs (1-2+ years) are generally better supported by nouveau. If nouveau does work, then it's likely that your GPU will work fine with wlroots at least.

Find your GPU's engineering name:

Find the corresponding level of feature support:

@sir Looks like I've got a Pascal GPU and support isn't great. The 2D features are marked WIP in the wiki... so I guess I'm out of luck for now?

@necaris actually I wouldn't be as pessimistic about NV130. Try it, it's free

@sir Is there something to get surface properties, preferably a CLI tool similar to xprop?
Also any recommentations in the wayland MITMs/tracers?

@lanodan nothing similar to xprop that I'm aware of now which works across multiple compositors. Sway has swaymsg -t get_tree, however.

Export WAYLAND_DEBUG=1 to trace any Wayland client or server to stderr.

@sir Thanks for these two, however WAYLAND_DEBUG seems to be quite too spammy, should probably add some context with the application being debugged.

I'm currently getting a bug in my WebKitGTK browser (haven't tried in other GTK things yet, could probably reproduce in a demo code if needed): It manages to resize it's GtkWindow, and so get keyboard+pointer events it shouldn't, without having the borders updated in sway, changing to another window makes it reset to how it should be.

To me it sounds quite like a double bug:
1- Sway should at least update the border and/or forbid the resize.
2- GTK shouldn't do this shit.

@lanodan I don't know if I have anything useful to say to you that deep in the weeds.

@sir what feature(s) are you most interested in for wlroots/sway? that don't exist yet, that is

DRM leasing is gonna be cool. Tablet support in Sway would be nice

@sir is it possible with wayland / sway to have your desktop extend across multiple gpus like windows does, that's my major annoyance with xorg, which limits the amount of screens I connect and use to my desktop to ~3 depending on the GPU.

@sir What is so hard about the Linux graphics stack that no major web browser can efficiently use it? FF/Chromium don't have hardware accelerated video, they have on Android, Win, ChromeOS. FF has to copy back rendered WebGL frames before compositing, yielding in bad performance. Still no proper Wayland support for FF. FF webrender consumes more battery power instead of being more efficient. Smaller projects like epiphany or qutebrowser are locked to 60 FPS. Most seem unable to do proper vsync

Browsers are ambling beasts made of flaming garbage, it sure as shit ain't Linux's fault

@sir I'm not saying it is. But they get it somewhat right on other platforms. Without experience, one might conclude that the platform's interfaces makes it harder to work with.

@sir can you describe how vsync works in Wayland vs. X? What do you think about VESA adaptive sync and will it work with wayland anytime soon?

@grmat there are atomic protocols and buffer locks in place which keep things syncronized on Wayland. I'm not sure how it works (poorly) on X. Adaptive sync will probably come within 2-3 years

@z3ntu this is handled by the compositor directly. Sway is compatible with i3 keybindings

@sir So basically 3rd-party applications can't implement that but the compositor has to do that?

@z3ntu that's the current state of the art, yes

@sir how can i use qemu in sway without the compositor intercepting keybindings?

@sir I am tempted to write a compositor. What are some of the biggest challenges when using wlroots?

@fred it's a lot of work is the main thing. You can get something which works in a day or two of work, but getting something good will take a lot of effort. wlroots does all of the hard parts, so mainly it comes down to investing time in molding what it provides into the sort of experience you want

@sir yes I understand, and I was hoping you could give a more precise answer. For instance, I already know OpenGL will be tricky as I have very little experience with rendering.

@fred I don't know anything about your experience or expertise. Just give it a shot and ask questinos when you get stuck.

@sir Thanks for your answers for now. I've got one more: when a Wayland client opens a window, is it guaranteed that the GPU memory it gets was cleared or would it be possible for it to get hands on previous content? Using X I sometimes see "uninitialised" window content which can then represent stuff like previously visited websites, even after reboots.

@grmat I'm not sure, but I think not. An easy way to find out would be to allocate a framebuffer and try glReadPixels without drawing anything. Or go hardcode and allocate a GBM buffer or stick your fingers into mesa or something

@sir What VSync scheme does sway/wlroots use? How does it achieve VSync without any noticeable input lag? How frequently does it render the screen contents?

We render frames during the downtime between page flips and present them when the display is ready. This means your input will not be seen until the next vblank, e.g. 60 Hz.

@sir Do you render the next frame as soon as a flip has occurred, or do you wait a little to reduce the input lag?

@YaLTeR currently we render as soon as the flip occured to leave us ample time to prepare the new buffer, but there has been discussions about refining the timing more

@sir is there an issue where that had been discussed or something?

@sir @YaLTeR Can vblank rate be variable, to use technologies like VESA Adaptive Sync?

@sir can I save it for another day? I was googling Nvidia Optimus+Wayland, I think I won't need to bother you, but just in case :p

@sir Can wayland surfaces be curved? This is for stuff like VR, for making globes, etc.

@ignaloidas no, at the moment they're always rectangles

@sir Is there something for Input Methods in Wayland/wlroots or like… every toolkit have to be configured to use one? (like {GTK,QT}_IM_MODULE environment variables)
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!