This is a discussion topic for the following Common Issue:
You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.
If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here and tag @common-issues-triage team.
@javierm Thanks for creating this topic! Can you please clarify whether the “display off” problem is only related to VT, or whether it affects graphical sessions as well? Because bug 2071209 seems to claim that even GNOME session doesn’t enable the display. This topic only talks about VTs, though.
@kparal it depends on whether the user is using the rpmfusion provided Nvidia binary driver or from somewhere else.
The rpmfusion akmod has a fix to remove conflicting framebuffers (i.e: simpledrm) so only VT shouldn’t work (because depend on efifb). But if the Nvidia driver comes from somewhere else, then it may other issues that prevent the graphical session to work.
In Fedora34 I have options video=vesa:off and vga=0x034d.
Fullhd bootlog and consoles without artifacts and freezes.
And, of course working X.
nvidia-drm.modeset=1 or 0 — does not matter.
video=vesa:off and vga=0x034d gives fullhd boot log and VTs (boot log draws an artfact: colored line during a few seconds while boot), X shows black screen
initcall_blacklist=simpledrm_platform_driver_init gives not text while booti process and in VTs (colored line only) but working X (well, no frame buffer in this case)
removing video=vesa:off and vga=0x034d gives low-resolution boot log and console, which freezes after exiting from mc and some other commands (old clean/clear console bug?), and working X.
Somehow I’ve got 1280x1024 console at secondary display (HDMI-1-1, not primary DP-4), but not sure how to reproduce it. No VTs at primary display in this case, but X always starts at primary one. UP: this works if both nvidia-drm.modeset and i915.modeset=1, i915 needed for secondary monitor which pluged-in to motherboard, intel card works like a proxy for nvidia.
The question is: is it possible to get in Fedora 36 behavior of Fedora 34 which works fine? Atm VTs of Fedora 36 are unusable and looks ugly, if you want to use X.
Ok, In the situation where nvidia-drm and i915 have modesetes set to 1 and display connected to nvidia card shows _ (lowline «cursor») in VT while display connected to motherboard (intel card as a proxy to nvidia one) shows normal VT (maximal resolution, no freezes)… Is there any solution for this situation to get working VT at nvidia display in maximal resolution without freezes as it was in Fedora 34 with fbdev? Or the only option is to wait while nvidia add support for simpledrm/whatever to drivers?
Since I wanted to promote the topic to the main #common-issues category, I transferred the whole discussion here into the “Talk” page. When the new workaround is available, feel free to ping me and I’ll update the issue description.
I’ve noticed something similar, but I don’t know, if it is related.
Hardware and software:
OS: Fedora 36 Silverblue
AMD Ryzen 5 2600
nVidia Geforce GTX 1060 6gb
16gb 3200mHz DDR4 RAM
When I switch to a virtual terminal, not exactly a black screen but weird graphical glitches are shown. The login screen and the Gnome session are working just fine (although the latter freezes from time to time under heavier load). These glitches are happening both with the nouveau and the proprietary nVidia driver (I did a rollback to an earlier deployment from before I installed the driver from RPMFusion).