You are not logged in.
I guess it's back to 21.1.18 for me.
1)
dGPU in BIOS, i915 blacklisted in modprobe.d
Result:
everything works
?
@rilian-la-te for recap: seems neither GlxVendorLibrary nor __GLX_VENDOR_LIBRARY_NAME can be used
The latter is ignored and the former inevitably affects the modesetting driver well - w/ the fatal consequences of dragging the nvidia GL library in.
Offline
?
I still want to be able to use iGPU, unless I can somehow conditionally blacklist i915 based on which GPU is set in BIOS. I can check if dGPU is active by running:
nvidia-smi --query-gpu=gpu_name --format=csv,noheaderbefore I start Xorg.
Last edited by karabaja4 (2025-11-06 20:47:53)
Offline
The idea would be to have two bootloader entries but you could also try to unload i915 during the boot (checking for the nvidia GPU being on the PCI bus)
Worst case, check the bus in the initramfs and only have the i915 module on disk so you can still inject a blacklist, but that's getting pretty tedious and cannot really be the general resolution of the problem.
Offline
Yeah that's a good idea with two bootloader entries, I'll use that. Here's my setup with UKIs if anyone wants to do something similar.
/etc/mkinitcpio.d/linux.preset
ALL_kver="/boot/vmlinuz-linux"
PRESETS=('nvidia' 'intel')
nvidia_uki="/boot/EFI/Linux/10-arch-linux-nvidia.efi"
nvidia_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp --cmdline /etc/kernel/nvidia"
intel_uki="/boot/EFI/Linux/20-arch-linux-intel.efi"
intel_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp --cmdline /etc/kernel/intel"/etc/kernel/nvidia
root=PARTUUID=<your_uuid_goes_here> zswap.enabled=0 rw rootfstype=ext4 modprobe.blacklist=i915/etc/kernel/intel
root=PARTUUID=<your_uuid_goes_here> zswap.enabled=0 rw rootfstype=ext4 i915.enable_psr=0and finally
mkinitcpio -POffline
Offline
I'm so confused by the discussion in the issue (not helped by random people coming in and discussing offtopic issues), the code they introduced and that are now reverting. Can someone ELI5?
They ported some new Glamor feature from XWayland to a stable Xorg branch without thoroughly testing the said feature? What was the feature/change designed to do?
Last edited by karabaja4 (2025-11-22 02:38:02)
Offline
Background:
* glamor didn't support some older chips for performing poorly on them
* with those chips you'd be much better off using the old DDX driver
* mesa dropped support for DRI2
* some of the forementioned chips are covered by mesa, not mesa amber and now fell into a complete gap:
trying to use glamor would result in software rendering (swrast), using the DDX driver would result in software GL (llvm)
* the patch enabled glamor for those chips and apparently also brought some performance enhancements according to at least one affected user
What went wrong:
* Idk why, but somehow that patch doesn't just adjust the existing glamor/modesetting stack but ends up unconditionally and early loading glamor glx what at least will run you into problems when running the server on the nvidia driver - the cause of this thread
* There're also report(s) for performance regressions from (AMD) user(s) of the DDX by the glamor glx module
What's to expect:
* patch is gonna be reversed entirely
* this will cause another regression, now for the users of the chips in the mesa gap
* no idea whether there's appetite to re-introduce a sanitized patch into the stable server again
* On top, E. Anholt suggested the patch would allow to remove legacy code from mesa - *ifff* that has already happened and *ifff* that's not reversed, users of older hardware need to brace for the next blow w/ coming mesa updates…
Artistic approximation of the situation:
Offline