Without plymouth-openrc-plugin X picks the boot GPU (which is the Intel integrated GPU) as default rendering GPU. `xrandr --setprovideroutputsource 1 0` then allows using the outputs on the dedicated AMD card, and allows rendering on the dedicated AMD card with the DRI_PRIME=1 variable. The Intel card uses the modesetting driver, and the AMD card uses the amdgpu driver. After installing and setting up plymouth-openrc-plugin, the default rendering GPU suddenly is the AMD card, and both the AMD card and the Intel card use the modesetting driver. (This results in an unusable setup because of bug https://gitlab.freedesktop.org/xorg/xserver/-/issues/1018 and bug https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/11) When I try to restore the old behaviour (Intel card as default with modesetting driver, AMD card as secondary with amdgpu driver) with an xorg.conf file I get: [ 8.265] (II) xfree86: Adding drm device (/dev/dri/card0) [ 8.265] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied [ 8.265] (II) xfree86: Adding drm device (/dev/dri/card1) [ 8.265] (EE) /dev/dri/card1: failed to set DRM interface version 1.4: Permission denied and: [ 8.271] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 8.271] (II) AMDGPU: Driver for AMD Radeon: All GPUs supported by the amdgpu kernel driver [ 8.301] (WW) Falling back to old probe method for modesetting [ 8.686] (II) modeset(1): using default device [ 8.686] (II) AMDGPU(2): [KMS] Kernel modesetting enabled. [ 8.687] (EE) Screen 0 deleted because of no matching config section. [ 8.687] (II) UnloadModule: "modesetting" [ 8.687] (EE) Screen 1 deleted because of no matching config section. [ 8.687] (II) UnloadModule: "amdgpu" The problem is twofold: - First, plymouth-openrc-plugin should not change the behaviour of X. The same X/SDDM configuration should result in the same X session regardless of whether plymouth has been run before X or not. - And second, running plymouth should not result in Permission denied errors on /dev/dri/card* (possibly plymouth has not come to a complete stop and released control of the device by the time SDDM/X tries to start?) Running `rc-service xdm restart` after the boot process with plymouth has completed and SDDM has tried to start, results in a normal working X session without needing to alter any configuration (in other words, this issue only occurs when SDDM/X starts *directly* after the plymouth-decorated boot process is completed). See also: https://forums.gentoo.org/viewtopic-t-1121756-highlight-.html
Huh, assigned to the wrong me.
Are you sure this is because of the plugin? All that the plugin does is load Plymouth if it's not _already_ running and send messages to it so you can still get output.
Well I don't use OpenRC or X any more, and I have a different GPU nowadays. So it's difficult to check. But, from memory: - If sys-boot/plymouth-openrc-plugin is not installed, then the default X11 GPU was the boot GPU (integrated Intel), as it should. - If sys-boot/plymouth-openrc-plugin is installed, then the default X11 GPU is the amdgpu. Note that when plymouth runs, it shows boot splash on monitors connected to all GPUs, meaning a framebuffer is initialized on the amdgpu as well as on the integrated Intel boot GPU. Whereas if plymouth is not run at boot then the monitors connected to GPUs that are not the boot GPU stay black, meaning they are first initialized by SDDM/X. This might explain the difference. It might also be an issue caused by some weird behaviour of X. Perhaps it finds the GPU to use as primary by listing all GPUs with an initialized framebuffer alphabetically (then amd would come before intel, but only if plymouth was running). In any case, SDDM under wayland is significantly less of a headache when it comes to multi-monitor, multi-GPU configuration. Since it will just run kwin_wayland with whatever desktop configuration is used for running plasma. Still, with the proper setup (openrc, x11, integrated gpu as boot gpu, dedicated amdgpu) I think this should still be reproducible. Since AFAIK not a lot has changed in this area.
I suppose that the real test here is seeing what happens if we invoke Plymouth without the plugin. I'll eventually get around to firing up a VM to test but have a bunch of other projects to attend to first (and retired my last "real" openRC system a while ago). I suspect that plymouth is the culprit, not the openrc plugin. @prometheanfire: Any thoughts as the Plymouth maintainer?
