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.
I see exactly the same with my F36 system and the nvidia 510.68.02 driver from rpmfusion.
I am using the Nouveau driver and I cannot see the issue. It looks like this only affects the proprietary driver.
I have mostly problems with gdm and sometimes X. The VTs are a smaller problem.
I am going to stick with the f35 kernel.
That’s correct, yes.
@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.
@javierm I updated the description. Does it look reasonable?
For me it is only the VT. As long as I do not try to switch to a virtual terminal with ctrl-alt-F[2-6] but remain in the grahical interface everything works.
When I use ctrl-alt-F2 the screen goes totally black and if I wait the monitor turns off.
Ctrl-alt-F1 brings back the graphical screen as normal.
I gave up and ordered a Radeon card.
This was certainly my most expensive Fedora upgrade 
I like your devotion 
I’ve proposed the following workaround: drivers/firmware: skip simpledrm if nvidia-drm.modeset=1 is set (!1788) · Merge requests · cki-project / kernel-ark · GitLab.
TL; DR the kernel will choose to either register a platform device that binds to simpledrm or {efi,vesa}fb depending on whether nvidia-drm.modeset=1 is set or not.
Sorry, missed your comment before. Yes, it does look good to me.
Fedora + CSM + nvidia proprietary drivers
In Fedora34 I have options video=vesa:off and vga=0x034d.
Fullhd bootlog and consoles without artifacts and freezes.
And, of course working X.
In Fedora36:
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.
Do you keep in mind that system can use both, nvidia and intel card drivers at the same time?
Yes, but that shouldn’t be relevant for this particular issue. Basically what the workaround does is just to revert to the old behaviour when nvidia-drm.modeset=1 is set.
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?
It can’t matter yet, because the patched kernel build is not yet available. Please follow the linked bugzilla tickets to learn when they are and provide feedback there, thanks.
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:
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).
