Printable View
Phoronix: What NVIDIA's Linux Customers Want
Last week when talking about NVIDIA looking to expand its Linux team (hire more engineers), I asked what else NVIDIA Linux customers wanted that already wasn't offered by the proprietary driver for Linux / BSD / Solaris operating systems. Aside from the obvious one, of many desktop users wanting NVIDIA to support some sort of an open-source strategy, other expressed views are listed below...
http://www.phoronix.com/vr.php?view=OTExMQ
The Nvidia blob already uses kernel modesetting. What people want is for nvidia to use the same form of KMS that is used by the open drivers. And that is never going to happen, because attempting to implement it would cause a massive regression in features, performance, and stability for the nvidia driver.
Like a lot of Linux/Nvidia desktop users, I'm sure, I really don't care about a lot of these features.
- randr: nvidia-settings does the job just about and I don't have to worry about hot-plugging monitors because it's a desktop
- KMS: I only restart when I have to. Plymouth (through proper KMS) does look nice but I'm really not that fussed. The native-mode TTYs, again, look pretty, but I'm not going to cry myself to sleep at night without them.
- Optimus: This does bug me because it essentially limits what products I can buy. I can only see dual-video cards in laptops getting more popular (they're a good idea, after all) and while the problem really lies in X, any product that uses this sort of technology is a product I won't be buying. This essentially means I either end up with: no product, a worse product and/or a product that costs a lot more.
Feature support is a given. As is performance. I think Nvidia is pretty good at keeping ahead of the masses on this one (I know a few people have bought hardware on the day of release and been disappointed - just as people who like to run on the mythical pre-alpha X v2 source tree).
My message to Nvidia would be:
Keep up the good work. Make the driver even faster. And open source it if you get a spare minute. Thanks.
As I said in the other thread, the problem with nvidia-settings is that those settings are not remembered across sessions, while randr 1.2+ clients generally seem to have implemented this pretty basic feature. So the advantage of randr 1.2 support is not just using native clients, it is getting basic features that nvidia has not bothered to implement in their own gui configuration tool. Nvidia seems to assume that everyone has root privileges and uses an xorg.conf, neither of which is necessarily the case.
This is true. What we should be asking for instead is either a framebuffer driver for the pretty bootup stuff or an egl driver for wayland.Quote:
Originally Posted by thefirstm
What I really want is KDE window resize to stop sucking with the NVIDIA driver. I don't know why, but it's definitely not smooth - I can see the windows slowly repaint.
Optimus support will likely never come to the blob. Essentially it would require Nvidia to integrate an Intel driver into the blob. Since the way Optimus works is that the Nvidia GPU does all its rendering to the framebuffer of the Intel GPU (after a frame is done a memcpy to the Intel framebuffer happens). The Intel GPU does all the presentation of the to the main display, so a full Intel 2D driver including mode switching all the other hell is needed.
There are several items that need attention that people are reporting at nvnews.net:Quote:
Originally Posted by phoronix
- Overclocking on GeForce 8 series cards is broken
- Twinview does not work properly with the 200 series and up drivers.
- 2D Performance is awful on the GeForce 7 series (e.g. my GeForce Go 7900 GS)
You could probably find more if you looked. Anyway, it seems that Nvidia's current development resources cannot support more architectures, add more features and fix all of these issues at once. With that in mind, it does not surprise me that they are asking for help.
I also vote for EGL support with an OpenGL ES 2.0 driver.Quote:
Originally Posted by patstew
Its not possible to fill the gap between fixing stuff and new api breakages in linux kernel and xserver or just new features what you wanna call it, not even the drivers also the core components of the kernel changes all the time.
And the lines of code changes each day increases linaraly so nvidia will maybe close for a short time the gap a bit with some new developers but they fight a lost battle, bring youre CODE in the kernel or you will loose against the change speed of opensource especialy the kernel.