Feature Request: KMS support

[autocrosser]

I wonder when we can see/expect KMS support in the drivers...Plymouth looks to be the future boot splash system for Linux & I for one would like to see it instead of a text-only boot....

[perfectska04]

+1

Not only for plymouth, but having flicker-free transitions and faster boot-time is a must. I've read there's some issues regarding the closed-source nature of the Nvidia driver that have been holding back KMS for nvidia, but I hope the developers come to some sort of agreement in order for us to have this feature.

[autocrosser]

Agreed...We need to be "on a par" with the other OS's out there & as long as there is a wait until you can use the desktop, we need to have a polished as possible look to attract new users from those same "other OS's".

GNU/Linux has made great strides in the last few years & we really need everyone to help.....I realize that nVidia has really helped in the last few years, but is it so much to ask to match what ATI & Intel are moving forward with? I have stayed with nVidia for years & really want to continue into the future---I just would really like nVidia to give the same user experience as the others are willing to give.

[Tomasu]

KMS symbols are GPL. NVidia can't legally use them. They'll likely have to reinvent the wheel (again, most of their driver re implements many existing features of the kernel and X. "Not Invented Here" syndrome much?) if they continue to stubbornly refuse to release a proper open driver.

[AaronP]

I actually looked into this a little bit, and it looks like "KMS" is one of those things like AIGLX where we already have what the acronym stands for and what people really want is something else. Here, what people seem to be asking for are two things:

1. An fbdev driver.
2. A seamless transition from the fbdev console to X.

Step 2 would be implemented entirely within our driver and shouldn't be too much trouble, at least for modern GPUs. Step 1 requires some more research and we're investigating whether it's possible and worth it. Other things people have been talking about, such as a graphical kernel crash dump, will require some more work and I've been discussing it with some of the X folks to make sure it can work reliably.

@perfectska04, I'm not sure who told you that KMS will improve boot times. I wouldn't expect boot times to change at all, except for them possibly slowing down a bit due to the extra workload induced by Plymouth.

[gbil]

Interesting news.

More or less my understanding of plymouth is that is will make the transition easier, minimizing the current flickering and thus presenting the user with a feel of better integration and speed. Nevertheless this is not a must just an addition.

On the other hand KMS is something bigger which I believe leads to getting the hardware handle out of X server and into the kernel.

[Tomasu]

Originally Posted by AaronP

I actually looked into this a little bit, and it looks like "KMS" is one of those things like AIGLX where we already have what the acronym stands for and what people really want is something else. Here, what people seem to be asking for are two things:

1. An fbdev driver.
2. A seamless transition from the fbdev console to X.

Step 2 would be implemented entirely within our driver and shouldn't be too much trouble, at least for modern GPUs. Step 1 requires some more research and we're investigating whether it's possible and worth it. Other things people have been talking about, such as a graphical kernel crash dump, will require some more work and I've been discussing it with some of the X folks to make sure it can work reliably.

I'm sure it could be implemented that way, but I don't think thats what it is at all. KMS/GEM/DRI2 means the kernel is responsible for all device access. Mode setting, memory/object management. Userspace no longer makes ANY direct device access, and X can run as a regular user.

The KMS part of the solution is mainly mode setting. It makes the kernel manage the graphics card, such that it does the actual mode setting, and now that userspace isn't involved, it'll also support proper kernel level sleep and hibernate (its really hard to do when userspace has its hands in the pie), it also means the kernel can print useful diagnostic messages to your screen, even with graphics running.

Have you looked at Waland yet, and what its aiming to do? If you haven't you probably should.

@perfectska04, I'm not sure who told you that KMS will improve boot times. I wouldn't expect boot times to change at all, except for them possibly slowing down a bit due to the extra workload induced by Plymouth.

It will prove perceived boot times in most cases. No ugly flickering, just a steady (potentially very pretty) progress display.

One of the distros has also played with moving XDM/KDM/GDMs startup to before most services, so perceived boot time goes way down, even if total boot time actually goes up.

[AaronP]

Originally Posted by gbil

More or less my understanding of plymouth is that is will make the transition easier, minimizing the current flickering and thus presenting the user with a feel of better integration and speed. Nevertheless this is not a must just an addition.

It'll make the transition smoother, sure, and that's clearly why people want it.

Originally Posted by gbil

On the other hand KMS is something bigger which I believe leads to getting the hardware handle out of X server and into the kernel.

This is an implementation detail that's specific to DRI/GEM and has nothing to do with the NVIDIA driver.

[Tomasu]

Originally Posted by AaronP

It'll make the transition smoother, sure, and that's clearly why people want it.


This is an implementation detail that's specific to DRI/GEM and has nothing to do with the NVIDIA driver.

Indeed. But you have to admit, given any OS, theres a Right way, and a Wrong way to do things.

And on OUR OS, hardware access does NOT belong in userspace. Period. Userspace apps like the X server should NOT run as root. period.

What people actually want is for the graphics card to work as advertised with their OS. Which means performance, little or no bugs, and things like sleep and hibernate must work all the time.

Smooth transitioning and graphical OOPS reporting are gravy, but very very very nice gravy, and its something people are going to not only want, but expect. And given the amount of time its taken nvidia to support XRandR 1.2 (1.3 is out now, did you know? 3 years is a long time to waffle on an important feature).

While I'm very glad nvidia is picking up speed on driver releases, historically nvidia has shown that its not very interested in supporting linux very well. Glaring bugs stick around for months or years, important features lay unimplemented for far longer. And even with the new found support, all that seems to being worked on is GL3 and VDPAU. Bugs and desktop enhancement features seem to lag behind for ages.

I've been very disappointed with my 8800. And unless something changes, I probably can't be convinced to buy another nvidia graphics card. I Just don't think nvidia appreciates the business.

[AaronP]

Originally Posted by Tomasu

And on OUR OS, hardware access does NOT belong in userspace. Period. Userspace apps like the X server should NOT run as root. period.

Oh don't get me wrong, I'm not arguing that running as root is necessary. In fact, I'm pretty sure we removed the last thing that required root access from our X driver ages ago, though I don't think anybody's tried it since the X server still uses things like iopl() that do require root. We just need access to the /dev/nvidia* device files.

[Tomasu]

Originally Posted by AaronP

Oh don't get me wrong, I'm not arguing that running as root is necessary. In fact, I'm pretty sure we removed the last thing that required root access from our X driver ages ago, though I don't think anybody's tried it since the X server still uses things like iopl() that do require root. We just need access to the /dev/nvidia* device files.

Good to hear. Now how about the rest of my points?

[robhancock]

It's true that a lot of the work being done with nouveau and KMS isn't really applicable to the way that the nvidia driver does things. It's already doing mode setting in the kernel - but it doesn't do frame buffer support, seamless VT switching, allow kernel oops display while in X, etc. like the real KMS support does or promises to allow, which are the real things it's missing.

I think the nvidia driver largely has the opposite problem to a lot of the existing open-source drivers - it tries to do far TOO much in the kernel. Look at the size of the nvidia kernel module, it's as big or larger than the rest of the kernel combined! Maybe in Windows' graphics architecture all that junk needs to be in kernel space, but on Linux surely a lot of stuff could be moved into userspace. The KMS drivers seem to be doing it right - have what needs to be in the kernel in the kernel, and nothing more. If NVidia went down this approach of moving code out of the kernel part, maybe they could even get all the closed-source part out of the kernel, which is the biggest pain in the butt..