Framebuffer Device Driver from NVIDIA

[mklemm]

Hi,

NVIDIA seems to be one of the few hardware manufacturers that really take linux serious. No other company offers such up-to-date and high quality drivers for their hardware products. I am very happy with that.
Unfortunately, everything is closed-source, which is in a way understandable considering the products NVIDIA makes.
The problem I have is for one half a general linux problem and for the other half an NVIDIA problem.

In my opinion, linux's graphics system is a bit convoluted.
Instead of a clean layer model there exist two or even more parallel graphics systems, the most important of which are X11 and fbdev.
In a clean layered model, fbdev would lie underneath everything that does graphics in the system. It would do all the low-level, hardware-dependent stuff and would expose an API that allows for complete control and utilisation of all hardware features in a hardware-independent way.
An X server would build on that and would not require its own hardware drivers.
Because things just are that way for the moment, I am quite unhappy with the situation that NVIDIA certainly makes excellent X11 drivers, but interoperation with a hardware-accelerated frame buffer driver is nearly impossible.
For now, I would like it very much if NVIDIA could distribute an accelerated framebuffer driver, which can be compiled into the kernel and used from boot time on along with the X11 driver.
I know that there exists a "rivafb", but this one's all but perfect and cannot be used while running NVIDIAs X driver.
I like the fbdev because it allows for lightweight apps and is ideal for special purposes such as embedded systems, kiosks, and "single usage" machines. You can build your own DVD player with that, and this thing wouldn't require hours for booting.
Of course, all features of th X driver (Mpeg, TV, Dual-Head, OpenGL) should be in that fb driver, too.

Regards,
Mirko

[bwkaz]

Whoa, deja vu. Oh wait, that's because this is a double post. :rolleyes: Well, something I wanted to say the first time around:

Originally posted by mklemm
In a clean layered model, fbdev would lie underneath everything that does graphics in the system. It would do all the low-level, hardware-dependent stuff and would expose an API that allows for complete control and utilisation of all hardware features in a hardware-independent way. An X server would build on that and would not require its own hardware drivers. Bzzt, wrong. Sorry, XFree86 is portable. This means it gets built on more systems than just Linux. It works on every *nix, pretty much, and even OS/2, and none of those have a separate "layer" like this that I'm aware of. You will still need to have the various hardware drivers. So, you gain nothing in terms of XFree86, and you add bloat to the kernel's framebuffer drivers. What's the win here, again?

Besides, what's the problem with vesafb anyway?

[mklemm]

Yes, XF86 is portable. And on many systems other than linux and maybe *BSD it builds on exactly what I mean with this "layer" model. XF86 for OS/2 and MS and I think for Darwin, too, doesn't need hardware dependent driver stuff compiled in (or even dynamically linked with - as in XF86) the X Server. XF86 for these platforms sits on top of the OS's native graphic interface.
VesaFB is good as long as you can go with a fixed set of resolutions/timings and without 2D or 3D acceleration.
What you win with a generic graphics interface is that you can run alternatives to XF86 without re-programming hardware dependent stuff. XF86 is IMHO the best X11 implementation around, but it is an X11 implementation and not everyone likes that. It has its quirks, and I'm sure you can imagine some applications that do graphics but don't need a windowing system at all.
I don't say that all of the low-level (or "generic") graphics interface should be done in kernel space, but it should be generic enough that it is independent of thefact which - if any - windowing system is to be used. This is just the idea of linux as an open OS taken seriously.

[puddpunk]

Besides, what's the problem with vesafb anyway?

Vesafb is not accelerated for nvidia cards. rivafb is, BUT, this thing packs it's pants when you try to use it with the nvidia kernel/xfree driver.

Try watching a movie using mplayer fb driver on the different vesa/riva framebuffers, and you will see the difference.

[bwkaz]

Why would I need to use mplayer's framebuffer output, when I can use its xv/sdl/GL outputs? Even -vo x11 is faster than framebuffer, from what I've seen.

[mklemm]

Why would I need to use mplayer's framebuffer output, when I can use its xv/sdl/GL outputs?
Because there are embedded devices (let's call it a DVD player here) that, let's say, run MPlayer as the only application. Why should you want to waste memory, disk space, and administration effort running X and installing a whole bunch of libraries that you simply never need? Why would you want to wait for minutes for X to be started if you could just boot into your DVD menu?

[bwkaz]

But I don't do that. It's a waste for me to have the functionality there if I'll provably never use it.

To someone else, perhaps not, but I'd think (I don't know for sure) that nVidia's bigger customer base is normal users, not embedded "stuff" (the Xbox notwithstanding -- it doesn't even run Linux).

Your point is valid, assuming that most of the people buying cards are going to use them in an embedded DVD player (or whatever). I don't think this is the case.