An example problem of proprietary drivers: Nvidia doesn't support the latest KMS/GEM APIs which are needed for smooth-looking boot and (I guess) for future stuff like Wayland. If the driver was open, the community would have ported it.
I disagree with "needed". It's entirely possible to have a modern, "smooth-looking boot" now even with the nVidia drivers as they are.
Wayland support is a valid point though.
Regardless, nVidia remains at the top of the pile in terms of performance and support on Linux. Especially for high-end 3D applications like Maya, CUDA, etc.
nVidia also has fundamental disagreements about the right graphics architecture for the system with many of the Linux folk. I personally think nVidia's concerns about that are valid.
It's unclear whether GEM, etc. are the right long-term approach.
Saying that the nVidia drivers are "at the top of the pile" doesn't say much for the competition.
Just a few of the problems that I have had:
1) In a 2 Monitor setup there is no way to rotate one of the monitors into portrait mode without the other unless you create them as 2 seperate X sessions.
2) Fullscreen almost any OpenGL app/game and it will span across both monitors, which just looks weird.
3) A very odd issue where on my second monitor the fonts will randomly screw up or parts of a window randomly become transparent and I can see the window behind (seems to happen mostly with flash) through it. Only way to fix it is to disable and then re-enable monitor.
Yes, I used to have an ATI card and I can confirm that it had just as many if not more issues.
>> 2) Fullscreen almost any OpenGL app/game and it will span across both monitors, which just looks weird.
This is because the games often use a library like SDL to do the windowing. Their idea of opening a window is called "SetVideoMode", so no wonder it goes wrong.
If a software uses X11 windowing in a way that most apps these days do, using extended window manager hints for fullscreen, etc, this problem would not exist. Btw. I use my window manager's full screen feature to do this. It works a whole lot better for games which allow resizing windows (this often excludes SDL-based games because you explicitly have to tell SDL you want a resizable window) than letting the game set full screen mode (usually via some horrible deprecated X11 legacy api).
The nVidia display driver is not perfect either, it doesn't support Xrandr yet, so expect problems with multiple displays (and rotation) until the situation is corrected.
One of the reasons I always shop for PCs with integrated Intel graphics is because things like multiple-monitors and rotation generally work out of the box, with no configuration needed beyond opening the standard GNOME Monitor Config tool.
Providing documentation sufficient to write an open source driver would not prevent nvidia from also providing a binary driver that does things the "right" way.
Unfortunately I don't think this will ever happen, since from what I know, most of the nvidia binary driver is basically a firmware to run the 'dumb' multi-core gpu hardware. Giving this away would provide valuable knowledge to their competition.
Hmmm. I'm not shedding any tears over the lack of graphical boot. I like to watch the messages.
It's not just about having or not having boot messages, which are still there in framebuffer mode if you want them. In fact, with a graphical console, you can see lots more messages at once, at the perfectly crisp native resolution of your screen, with large fonts if you like.
A major part of the issue is video mode switches causing ugly flickers, with many LCD monitors taking ages to resync and turn the backlight on after a mode change. You can miss a lot of boot messages in those precious seconds. Sometimes my monitor takes so long to sync that I don't even get to see the BIOS screen or GRUB menu.
Meta rant: why do people feel the need to chime in with how much they don't want something when someone else says they do?
What I would love though would be reliable suspend/resume on an OpenGL 4.2 accelerated notebook.
Putting all drivers in the hands of the kernel subsystem maintainers would go a long way toward solving that.
with a graphical console, you can see lots more messages at once, at the perfectly crisp native resolution of your screen
That would be nice.
why do people feel the need to chime in with how much they don't want something when someone else says they do?
In this case, I'll admit I'm not a fan of splash screens in general.
I've been a teeny-tiny bit annoyed over the years at the level of effort I've seen kernel and distro developers put into graphical boot schemes when it seemed to comes at the expense of more basic stuff, like you know, working drivers for things after the boot was complete. But it's their time and energy. If they want to put it into showing a penguin holding a beer that's their business.
To me it's usually a sign of form-over-function, or functions-I-don't-want-over-functions-I-do.
I started working with the Linux framebuffer a long time ago. The penguin boot logo was cool, but the biggest benefit was being able to code in a 128x43 (or bigger) terminal without running X. I see KMS as the long-overdue fulfillment of the dream I had then of decoupling high-end video support from X.org.
Back then I was using links2 in graphical mode, fbi for viewing images, and fbgs for reading PDFs. Since I'm working with web apps and WebGL now, I'm obviously running X.
Entirely agree, I remember my first Linux install (Suse 6.x) seeing all of those messages fly onto the screen , first from the bios and then from Linux. It would go straight to a text login then I would type "startx" to get the GUI up.
Also made it much easier to tell WTF was going on with your system and displayed all those warning messages that I am guessing are just hidden away now unless you happen to look at dmesg.
