How we wound up with Linux's kernel mode setting ('KMS')

I don&#x27;t have anything to say technically, but this ignores the social elephant in the room which is the interesting part of this story. We wound up with KMS because circa &#x27;07 AMD bought ATI and started to execute an Open Source strategy. That meant 2&#x2F;3 of the big graphics providers were open source friendly (ATI&#x2F;AMD &amp; Intel) vs one closed (Nvidia).<p>That was when the bell tolled for X11 (yes, yes, is still tolling), as there was enough OS support to kill of UMS which was really just a mechanism to keep binary drivers a safe distance from the kernel. With key components open sourced, the Linux graphics stack has been reorganising like some sort of enormous mudslide with ripples and aftershocks that keep flowing out today 15 years later. KMS was one part of that.<p>At some point Nvidia, the last interesting closed source holdout &amp; throwback to a bygone era, will cave and open source their damn driver and we can close the book on one of the most interesting episodes in the history of the open source movement.

Some time in late 90s&#x2F;early 2000s there was a project called KGI (kernel graphics interface) and GGI (general graphics interface) which tried to topple X11&#x27;s supremacy too. But they were probably too early in the game and did not have any corporate backing -- and so KGI was denied inclusion in the kernel.<p>But perhaps they paved the way somehow for KMS to be successful.

I really love that the AMDGPU modules are Open Source and well integrated into the kernel. With my 6600XT flickerfree boot works thanks to KMS, Wayland just works (sway), gaming works great, accelerated video decoding and encoding works, smooth video player with hardware accelerated frame interpolation works, PCIe Reset for Hardware Accelerated Windows VM supposidely works (untested for me) and all essentially out of the box (baring setup and installation of the individual components&#x2F;libs).<p>When it comes to linux GPUs, AMDs Open Source Driver strategy paid off, because I bought mine explicitly because of their great linux support.

I remember KMS becoming a thing and wondering why anyone needed or wanted this. I still don&#x27;t exactly know, since it seemed natural to me that the kernel shouldn&#x27;t be doing any graphics things until I actually wanted a graphical console. I suppose this is more of a microkernel view of things, since similarly you could argue that the kernel doesn&#x27;t need to know about disks and filesystems, only programs that need to access pesky files need to do that.

I really was hoping for kmscon to take off, and that it gets merged in the kernel. I guess the current state of the linux console just shows that not even the kernel devs are using it.

Didn&#x27;t the VESA drivers require kernel code to switch to V86 mode to call int10h going all the way back to the 90s? Kernel mode setting might be new to a unform interface for graphics drivers, but using kernel mode (ring0) code to switch graphics modes goes back to the early beginnings and the simplest drivers.

I remember Windows 95 getting a ton of heat for moving the graphics subsystem into the kernel and how that made the system unstable and unsafe and blah blah blah.<p>What I don’t remember was the reception to KMS from this same group of folks. I think there were similar concerns but my memory is fuzzy here. Does anyone remember some details?

It&#x27;s hilarious to me that &quot;KMS&quot; is almost exclusively used to mean &quot;sending OpenGL data to the GPU&quot; and very rarely if ever means &quot;setting the resolution and frequency mode of a display&quot;. Maybe they should change the name to something more meaningful, like &quot;Kernel-side GPU interface&quot; (KSGI)?