It is like you are pushing a Mazerrati with your hands from the garage , and then you can start it outside your house . So starting Linux today uvesa is not elegant at all . We hope , that we should find a solution from this primtiv Problem . it seems for me as i have DOS on my System .lol
AFAIK nvidia can’t use linux kernel mode settings due to licensing issues, and that will not change till they opensource their driver.
Better you know that even using uvesa will make your help request useless, since nvidia does not support graphics framebuffers.
I don’t know if that changed lately, but the driver has problem when UEFI systems set a different resolution at boot.
In the end you have to be stick with a text console or use nouveau.
My Question is :
can i use my intel " integrated Graphic on Board " for booting and starting the desktop . When it finisched it wakes up the nvidia Beast ?
I believe you should be able to as I’ve seen at least one other user that accomplished this. This assumes you have a desktop and not a laptop. For laptops, I’ve used bumblebee http://bumblebee-project.org for a while and it works decently.
Nvidia has been doing modesetting in the kernel since way before KMS existed. So why don’t you have a high-res console with the Nvidia driver? Simple, KMS drivers have a built-in fbcon driver, Nvidia’s kernel modesetting does not. And the reason for that is also simple: no incentive to provide it, since their primary customers - workstations - don’t need it.
Is is really so important how the machine looks when it’s booting? You’ll see the boot process for a few seconds, and then you’ll be at the machine… definitely a lot longer than a few seconds. So I don’t get this fascination with boot-time looks. Do you guys realize that Windows also has a low-res bootsplash (well, I don’t know about Win8, but everything up to Win7 has a low-res one). And yet, I don’t think Windows users feel that they “have DOS on the System”.
Well it does add a certain sense of professionalism, but I’m not sure it’s so easy to implement. Isn’t the nvidia module loaded when X.org is loaded and that only happens when the display manager kicks it off, which happens usually after the system has completely come up?
Windows users have smooth boot process without screen flickering, artifacts and without kernel messages. It is much better, even if low-res. In linux we need such boot too, especially for distributions targeted for industrial devices such as kiosks, cash desks, etc. Black boot screen with text kernel messages looks terrible and unprofessional and customers usually don’t want to see it.
However, in such configurations (kiosks, cash desks and so on), investing money in an nvidia card would be worthless.
Using an integrated intel card (linux kms, stability, OS integration, power consumption) is the way to go.
I don’t mean to necro this thread but I had to respond to this because it’s somewhat inaccurate point and here’s why.
The framebuffer for console decorations is more than just viewing for early print kernel and init scripts. While it is a crucial aspect of the system boot process for visual inspection in which a problem may arise this isn;t why we want the eye candy or just smooth rendering. We could always check dmesg or various log files in /var/log/.
Here’s where it does affect the user experience, consoles for shell work especially for hours in some cases. Linux users don’t always rely on a X server or GUI (like Windows explorer.exe or old progman). In many cases it’s literally not necessary to even boot into Desktop Environment and is completely optional at the users discretion.
Sometimes I remove xdm from loading by default via init scripts, or simply enter interactive boot and remain in the shell tty1-12. Which I and many others have gone out of their way using tools like fbcondecor aka splashutils coupled with a uvesa frame buffer device.
You’re forced to use if using the proprietary nvidia driver for high resolutions and other related modes.
Which is fine I have no quarrels with this IF it functions as intended however I just recently read that Nvidia is indeed working on a KMS nvidia implementation not just because it will be nice for shell users but for Wayland and Mir.
Related: and also propose new EGL extensions for better driver interoperability with Wayland/Mir, and to support the KMS APIs by their driver.NVIDIA’s binary driver will support the KMS APIs/ioctls but will be using their own implementation of kernel mode-setting. The EGL improvements came this past fall I think in their closed-source driver while the other changes probably won’t be seen until sometime year.
If it’s any consolation it appears that Valve has resolved the boot transition issues, but I’m not sure if it’ll ever make it to desktop Linux. I don’t think it would benefit the virtual consoles either. I suppose those will still rely on some kind of vesa fb driver.
Would you even want a virtual console driver implemented in the nvidia driver? In the rare extremely common case of having L4D2 hang the video driver / X, how would you ever kill the process if you couldn’t flip over to a virtual console?
There’s nothing inaccurate about my point, which addressed the OP talking explicitly about “starting Linux”, so boot-time looks. What you’ve presented is an entirely different point - the use of the console as a tool, rather than just something that briefly appears before the graphical environment (which the OP seems to consider the “real” or “actual” system) starts.
Ahh okay I guess to me it came off as a generalized point of view, then yes I would agree as far as just eye candy it’s basically pointless especially like my setup I can barely see the init scripts run on boot and boots so fast on a SSD and even more so on my windows install with a raid0 via 2 SSD’s.
“Is is really so important how the machine looks when it’s booting?”
If it’s just ugliness, I really wouldn’t care - but over here on my end, inside the linux framebuffer I
- have no output at all on my main monitor
- only have sideways output on my side monitor (it is in portrait mode, but the framebuffer does not care)
- the resolution on the side monitor is wrong (it cuts off, like it thinks the screen is higher than it is)
So during boot and login (or if debugging something low-level), I have to strain and hurt my neck to read the sideways text on my secondary monitor, while also typing ‘clear’ every few lines so I can still see what I’m typing; all the while the main monitor sits around showing nothing at all.
AMD’s drivers manage this fine, so I’m not really sure what’s stopping nvidia.
big thanx 2 Aaron and nvidia devs for integrating KMS .
Just to set expectations, the new nvidia-modeset.ko kernel module does not implement the kernel’s framebuffer console interface or the DRM-KMS API. It just centralizes and revamps the code that handles the display to pave the way for future improvements.
thank u anyway Mr Aaron.
I wish i could do this implementation , but my brain is like a stone .