Black/weird screen when switchting between X and TTY

[johnpatcher]

Hi,

my graphics card is a NVIDIA 310M. I'm running the latest NVIDIA driver (version 302.17) on top of a 3.4.4 kernel. I can definitively say that these issues were already present in older versions of the NVIDIA driver, although I haven't kept any records, because I was using the nouveau driver in the meantime, which is working fine with regard to these problems.

The first (minor) issue I've got is during boot up, where some messages on the screen get screwed up and look *really* weird. Basically they can't be read any more. It doesn't apply to all messages, but in general makes the boot process pretty much inexplicable.

The other (major) issue is that once X gets started, I can't switch back to any TTY any more. When trying to switch between X and TTY the very first time after having rebooted the machine, the screen turns totally black with the backlight disabled. However I can switch back to X and don't experience any abnormalities. On any consecutive switch to TTY the screen doesn't get totally black any more, but there are some bars with brighter regions and some bars with darker ones (although it is hard to make them out). The backlight stays on. I still can switch back to X and use it normally.

My best guess would be that these issues are related to each other and have something to do with the framebuffer. I was using uvesafb in the past to circumvent both of the above issues, but this can't be considered as a real solution, as it sucks to run these kind of things in userspace to have something as basic as working consoles.

As said above, it works fine with the open-source nouveau driver, so there is definitely something wrong with the NVIDIA one and not with my hardware.

I'm aware of the fact that pictures taken with a camera might be a little bit unprofessional, but maybe it helps you to understand what is going on, because it is pretty hard to describe it with words as I'm not a native speaker. I'm also attaching the nvidia-bug-report.log.gz generated by nvidia-bug-report.

Let me know if there is anything else you need to know in order to narrow this down.

Best regards,
Karol Babioch

[artem]

This topic has been brought up like 20 times on these forums already.

Stop using vesafb or any other framebuffer and you'll be fine.

It's a known regression, but NVIDIA so far has been unable to fix it, and they may as well never fix it.

[RealNC]

I really miss my 1920x1080 framebuffer console ever since I switched to an NVidia card :-( I now have an 80x25 console with giant, stretched, distorted and blurry characters and the boot-up graphics don't work anymore. Booting the machine is like in the bad old MS-DOS days.

Is providing a framebuffer driver that cooperates well with the X driver really that difficult?

[artem]

Originally Posted by RealNC

I really miss my 1920x1080 framebuffer console ever since I switched to an NVidia card :-( I now have an 80x25 console with giant, stretched, distorted and blurry characters and the boot-up graphics don't work anymore. Booting the machine is like in the bad old MS-DOS days.

Is providing a framebuffer driver that cooperates well with the X driver really that difficult?

To solve this problem NVIDIA has either to revert some changes or they have to implement KMS - but they were firm in stating that KMS wouldn't be supported at least in the nearest future.

[Gusar]

Originally Posted by artem

or they have to implement KMS

No they don't. What they need to do is put a fbcon driver into their module.

It's not KMS that magically gives you a high-res console. It's the fbcon driver built into it.

[johnc]

Originally Posted by RealNC

I really miss my 1920x1080 framebuffer console ever since I switched to an NVidia card :-( I now have an 80x25 console with giant, stretched, distorted and blurry characters and the boot-up graphics don't work anymore. Booting the machine is like in the bad old MS-DOS days.

Is providing a framebuffer driver that cooperates well with the X driver really that difficult?

You have a Fermi card, right? I know it's not officially supported, but so far I haven't had any problems w/ vesafb on Fermi and 302.17... but, of course, YMMV. And so far I haven't had any problems with a GeForce 210 and 295.* and down. And only tangential problems with a 7950 GX2 w/ 290ish on down (random suspend hangs, may or may not be fb related).

I forget the exact resolution but I think I can get 1280x1024 out of vesafb and some Plymouth graphics, which isn't too bad.

[professorll]

Originally Posted by artem

This topic has been brought up like 20 times on these forums already.

Stop using vesafb or any other framebuffer and you'll be fine.

It's a known regression, but NVIDIA so far has been unable to fix it, and they may as well never fix it.

This seems to occur regardless of whether a framebuffer is in use or not. Do you mean something that isn't immediately obvious?

[artem]

Originally Posted by professorll

This seems to occur regardless of whether a framebuffer is in use or not. Do you mean something that isn't immediately obvious?

Everyone with this problem uses the framebuffer. Any questions? ;-)

[Gusar]

Originally Posted by artem

Everyone with this problem uses the framebuffer. Any questions? ;-)

Nope. Some don't have any consoles, framebuffer or otherwise. It's very limited though, from what I've seen, to Geforce 8 cards.

[superlex88]

Hi.
I've got the same problem. Both with linux 3.4 that linux 3.0.
Nvidia 8400M GT, driver version 302.17. With or without framebuffer the situation is the same.
With or without plymouth too.

If you need additional informations please ask me.

Regards.