Getting pixels on screen on Linux: introduction to Kernel Mode Setting - Simon Ser

[@grahamdonaldson9069]

Really useful and informative!

[@miltiadiskoutsokeras9189]

KMS is actually a very good candidate for computer and console emulation, especially when a CRT monitor is used. Minimal display latency. What I haven't figured out yet is how to use a custom display mode without a custom EDID file, which restricts your runtime options.

[@vaishalithakkar2738]

Very informative talk! 🎉

[@mohammedyassin8706]

Thank you for sharing all this informations :) ! Is it going to work under different Linux desktop enviroments or it only works in Linux test consoles ??

[@voltflake]

Very helpful, thanks!

[@maxf1542]

How does this all relate to the /dev/fb0 I can write to today

[@robertolin4568]

fb0 is created by an old graphic framework in the kernel called fbdev. It’s considered legacy now.

[@raghul1208]

Bravo

[@dipi71]

1:49 What is an »app«? An executable? A binary? A process? A task? Does it have to have graphics, or are bash and grep apps too? Great talk otherwise. Cheers! Edited to add a fun aside: You can compile a kernel without DRM support (as I do), which would mean the device(s) under »/dev/dri« wouldn't be present. The open() function at 9:52 would fail in that case. Yet, X11 still initializes the gfx card correctly (at least in my case), the display manager starts KDE/Pasma, Steam games and in-browser WebGL/ShaderToy stuff work as they should, despite no kernel-space DRI/DRM support. How is that? Do X servers use some other mechanisms?

[@EmerSion]

> What is an »app«? An executable? A binary? A process? A task? I was referring to graphical applications here. CLI tools don't need to draw pixels on screen so they don't need to talk to the compositor (they can just print characters on stdout). > How is that? Do X servers use some other mechanisms? Yes, X.Org's server also supports connecting to fbdev (/dev/fb0). This is a legacy API and it's quite limited, DRM supersedes it. > Great talk otherwise. Cheers! Thanks!

[@dipi71]

@@EmerSion Thank you for clarifying. I have neither the dri nor the fb0 device over here, so my Nvidia driver (or openSUSE, my distro) must use some other black magic to make it work. Baffles me. Frame buffers, DRI/DRM, X and Wayland are as fascinating as well as their history (just watching »The real story behind Wayland and X« from LinuxConf Australia 2013). Cheers!

[@hitaishibarai9062]

@@EmerSion Can you please share the ppt for this one? It seems in the link provided in the description the slides are not available for download anymore...Thank You

[@EmerSion]

@@hitaishibarai9062 Sorry about that, should be fixed now!

[@logangraham2956]

@@EmerSion but thing is, i just need a framebuffer and knowledge of it's resolution for the application i plan to be making. because i'm just going to be using the linux kernel as a temporary test bed for my own kernel functionality as i'm doing osdev, so the concept is to write some kind of wrapper code that will hide the fact that i'm not currently running on my own kernel so that i can develop my graphics library and then port it back to my own kernel (minus the wrapper code of course).

[@Alperic27]

conclusion… whatever the structure of what you are doing, the kernel only deals with a rasterized version of it… a thought: 3 ioctl for something that should be done with… drumrolls… 1 … if the structure passed contained all the data. 🤔 … where did i see something similar… …. right!! got it… it is what was done to vulkan to learn from the inefficiency of opengl. so then… when will drm be modernized??? the funny part is that the atomic part is basically already similar to the vulkan notion of command buffers… … so why not go all the way and also change these 3 ioctls at the start into 1 (and do it everywhere else where applicable)