Comment # 11 on bug 1231067 from pallas wept

> No, NVIDIA claims 550.120 has fixed that issue.

Sorry, I should have said, all of the *available* drivers. I mean to say, all
the ones I could install from the oss, nvidia or cuda repos. I anticipate that
it will be fixed in .120. 

> > With nvidia_drm.fbdev=1 in the kernel command line (and conf), boots into
> > plasma, without corruption, but with 100% CPU usage and unusably slow
> I guess you're now implicitely using
>  nvidia-drm modeset=0 nvidia_drm.fbdev=1

In this state, fbdev is added to stock, that is the only change. So, modeset=1
should be set by the conf file here. fbdev=1 should be set twice, once in boot
command, once in conf file. This seems true, as with the 550 driver, I see the
boot message that the param is not supported and has been ignored, twice.

Note that the behaviour is different with fbdev=1 specified in both places,
compared to specified only in the conf file.

> 550 closed driver (nvidia repo)  Unmodified is just like 560
> With nvidia_drm.fbdev=1 in the kernel command line (and conf), boots into
> plasma, seems normal

> This sounds unexpected.

It is most unexpected. This is the real problem I am reporting here, the
behaviour of the boot command and modprobe conf files seems inconsistent. 

I don't even know if it's limited to the nvidia packages. We just see it here,
because of the fbdev bug in the driver. It's probably nothing, but it is
potentially major, so I thought I should follow up.

> Mabye you didn't run 'dracut -f' after changinge the config?

In that scenario, I set the boot command with yast, and I'm fairly sure that
rebuilds the initrd, as dracut would? I did not change the modprobe conf, just
kept the stock modeset=1 fbdev=1 from the existing conf file.