Due to an influx of spam, we have had to temporarily disable account registrations. Please write an email to accountsupport@archlinux.org, with your desired username, if you want to get access. Sorry for the inconvenience.
I see. The thing is, that it seems there is some kind of conflict, when fbdev=1 is not set together with simplefb.
This is also the reason why Fedora was able to drop the patch - the current situation without the simplefb skip patch and without having fbdev=1 enabled is not good. But lets wait then for nvidia
I agree with you nvidia_drm.fbdev=1 does seem to be needed. But then we'll get folks complaining about enabling experimental features by default (see #14 (closed)).. which is why we need the clarity.
Regarding whether it should have just modeset or both fbdev and modeset, that's a question of whether you think you're breaking more setups by adding fbdev rather than doing nothing.
On one hand, fbdev has been out for quite some time (since 545 series), but on another hand, every new series release it gets a fix, 560 included... maybe it's good enough nowadays?
I imagine quite a lot of people use Nvidia, Wayland and the stable kernel, now that Explicit Sync is there.
It broke my setup too, am on LTS kernel atm.
The user can overwrite the patched file on their own putting into /etc/modprobe.d/nvidia.conf for example. This will overwrite the patched module.
Fedora is actually also handling it like that. See in MR:
!13 (merged)
I think fbdev has been pretty battle tested over the recent months. Its pretty important for archlinux enabling fbdev, since otherwise simplefb does conflict and the wayland session is broken.
I don't see the benefits of patching Nvidia source, just the maintenance burden, am I missing something?
It is also more complex to tell users to start creating override files, or creating bootloader parameters, over pointing them to an existing configuration file.
The main benefit is there, that any file set by the user (either /usr/lib/modprobe.d, /etc/modprobe.d or kernel cmdline) will be overwritten, but besides not that much.
Likely, mainly following the fedora way. It does not care in the end
any file set by the user (either /usr/lib/modprobe.d, /etc/modprobe.d or kernel cmdline) will be overwritten
user can overwrite the patched file on their own putting into /etc/modprobe.d/nvidia.conf for example
I may be just tired, aren't those contradicting each other?
User can override the default option by editing modprobe.d in either case, I don't see how user files would be overwritten.
Editing source code over creating a modprobe.d file just seems bad to me for both the developer and the user alike, except for saving some time in the short term because Fedora already wrote the patch.
No, if they edit the modprobe.d provided by the package, it will be overwritten with every update. This is not the correct way.
If then we need to put it into /usr/lib/modprobe.d/nvidia.conf and the user can override it with /etc/modprobe.d/nvidia.conf to have this overwrite properly set and not overwritten with every update of nvidia-utils.
backup array needs to be enabled then. But still - /usr/lib/modprobe.d should be not touched by the user. The user should touch only /etc/modprobe.d, which is used as override.
If then we need to put it into /usr/lib/modprobe.d/nvidia.conf and the user can override it with /etc/modprobe.d/nvidia.conf to have this overwrite properly set and not overwritten with every update of nvidia-utils.
Well from my side enabling the options via modprobe.d is a more correct approach.