Display Manager Fail-Safe Measures about winesapos HOT 11 CLOSED

Hey @wallentx , thanks so much for your interest in winesapOS! That is a very interesting use-case that I have not thought of. I know that the NVIDIA proprietary driver packages love to hijack the Xorg configuration which can break Xorg usage for Mesa drivers for AMD and Intel.

My initial plan for better NVIDIA support was to simply wait for the Mesa drivers to mature. With NVK for Vulkan support being worked on, I expect that to all be working by the end of this year. The Mesa driver is almost fully Vulkan 1.3 compliant, the re-clocking / GSP firmware support is being reviewed for the Linux kernel, and we are now just waiting for the Linux kernel side of the NVK driver to be completed. Collabora said they want to support NVK all the way back to Kepler cards, too. Amazing! I've got a prototype build of winesapOS with gamescope-session working where we replicate the "Game Mode" from Steam Deck. However, it does not (and will not ever) work with the proprietary NVIDIA driver. That being said, these open source drivers will lack things such as CUDA (and, by extension, DLSS) and vGPU support for enterprise-grade cards.

There are a few projects out there to handle laptops by switching the primary GPU to be the internal Intel iGPU or the discrete NVIDIA GPU. I wonder if those can be used out-of-the-box or at least with minor modifications to help in this situation. Nobara, for example, uses supergfxctl.

The reason for selecting the graphics drivers in the first-time setup is mostly historical. winesapOS 3.0.0 used Mesa from SteamOS but it only supported AMD. For Intel, we had to use Mesa from Arch Linux. Nowadays, we default to Arch Linux Mesa and I've also modified my mesa-steamos package on the AUR to re-enable support for all of the other drivers (Intel, VMware, etc.). We technically could (and should) ship all of the Mesa packages. It is smart enough to automatically pick the correct open source driver to load based on the hardware. I can add some logic to see if a NVIDIA GPU is present. If so, we can automatically install the propriety driver. Or at least ask if a user if they prefer to use the open source or proprietary drivers.

Running Xorg -configure at every startup sounds scary to me lol. Maybe if we detect a hardware change? We can cache the current list of "VGA" PCI devices and compare. I really like the idea of having a TTY console fallback. That's a simple and neat trick!

I'm definitely open to anything here. I'd hate for us to re-invent the wheel if someone else has it figured out. It feels like a bigger project that could/would exist outside of winesapOS for the wider Linux community to use. I'd say the first step is to see if GPU switching utilities work. If not, sure, feel free to hack around and open up a PR if you come up with a solid solution. If moving your Arch Linux from system to system is working but winesapOS is not, maybe I'm simply doing something wrong.

Thanks again for reaching out!

from winesapos.

Thanks for the update, @wallentx , and for helping flesh out the LightDM failure case! For what it's worth, winesapOS doesn't touch the Xorg configuration (I loathe the days where I constantly had to re-configure that manually many years ago!). Feel free to open a PR with these systemd service units along with the script once you have something working. I have a wide range of hardware I can help test with, too.

I'm planning to release winesapOS 3.4.0 about a week after SteamOS 3.5 hits the stable update channel on the Steam Deck. I'll be importing, rebasing, and repackaging those on the AUR for use in winesapOS (and Arch Linux in general). Just waiting on Valve Time(TM) so I suspect we can get this in for the release, too. ;-)

from winesapos.

Hey @wallentx , thanks for following up! No worries, I'm busy myself with lots of things going on so I get it. I hope you were able to successful recover your data from that XFS partition!

You should base your fork off of the main branch. I normally use test for testing a batch of a bunch of small unrelated patches.

For historical purposes, winesapOS scripts are written in Zsh instead of Bash. I should probably convert it to Bash soon but, for now, just know that there are some minor differences between the two. The most recent issue a new contributor ran into was with expansion of array variables being different.

For this feature specifically, you probably want to add it somewhere in the desktop environment setup here:

This feature should probably have tests in scripts/winesapos-tests.sh and an idempotent upgrade in scripts/winesapos-upgrade.sh added but I can take care of that busy work for you.

https://github.com/LukeShortCloud/winesapOS/blob/main/CONTRIBUTING.md#adding-applications

I'll add more hints brought up here that are missing (fork the main branch, use Zsh, etc.). Anything else you think I should add to the contributor's guide, let me know!

from winesapos.

No need to apologize! Ironically, I've also been dealing with a leak in my house this past week lol. It almost ruined a few of my test computers but, thankfully, I was able to rescue them in time. I hope your roof doesn't cave in and good luck with the rest of the repairs!🙏

from winesapos.

Ah, I didn't even think about the GPU switching thing! I'm not entirely sure how it works, but I might dig through the code just to satisfy my own curiosity.

An addendum to my first post- the systemd service needed to be a bit different than what I had initially posted:
/usr/lib/systemd/system/lightdm.service

[Unit]
Description=Light Display Manager
Documentation=man:lightdm(1)
[email protected]
[email protected] systemd-user-sessions.service plymouth-quit.service acpid.service
StartLimitInterval=60s
StartLimitBurst=3
OnFailure=lightdm-failure-handler.service

[Service]
ExecStart=/usr/bin/lightdm
Restart=always
RestartSec=5s
IgnoreSIGPIPE=no
BusName=org.freedesktop.DisplayManager

[Install]
Alias=display-manager.service

and I have at /etc/systemd/system/lightdm-failure-handler.service

[Unit]
Description=Handle LightDM failure

[Service]
ExecStart=/usr/bin/chvt 2

[Install]
WantedBy=multi-user.target

This seems to work as expected in my one test of swapping systems.

Looking back on things, I do believe that so long as the appropriate drivers are present, everything seems to work fine, unless you have a config in xorg.conf.d that would result in a failure if it contains instructions that would cause it to fail if a GPU were absent. I'm working on a script that attempts to check for this kind of behavior, and makes adjustments if needed.

from winesapos.

Hey @wallentx , I've ran into a few last minute blockers but should have winesapOS 3.4.0 out by next week. Do you want to at least get the LightDM fail over to a TTY console merged in for the upcoming release?

Either I can give you some pointers of where the code can go or I can add it myself and give you credit in the release notes. I'm fine either way, just let me know!

from winesapos.

Hey @LukeShortCloud, sorry I let this slip! I misplaced the superblock for my XFS filesystem, and got distracted trying to recover data. Let me take a look at this tonight and see what I can come up with.

from winesapos.

@LukeShortCloud I assume the branch on my fork should be based off of the test branch?

from winesapos.

PR coming shortly for just the failover for lightdm bits.
With regard to our prior convo about possibly detecting which card is present in the system:

I wasn't sure how systemd drop-in configs worked until doing this.. and now that I know how they work, I also understand how the /usr/share/X11/xorg.conf.d/ drop-in configs work as well, and I believe that by default, this all should just work. Maybe I made/modified one of these files myself and forgot about it, but feel free to verify on your end-

/usr/share/X11/xorg.conf.d/ contains

10-amdgpu.conf
10-nvidia-drm-outputclass.conf
10-quirks.conf
40-libinput.conf

Looking at my Xorg.0.logs (possibly for the first time actually understanding what is happening), I think that all we have to do is nothing.

(==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 18 22:45:27 2023
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |-->Screen "Default Screen Section" (0)
(**) |   |-->Monitor "<default monitor>"
(==) No monitor specified for screen "Default Screen Section".
     Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(==) Automatically adding GPU devices
(==) Automatically binding GPU devices
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) The server relies on udev to provide the list of input devices.
     If no devices become available, reconfigure udev or disable AutoAddDevices.
(II) Module ABI versions:
     X.Org ANSI C Emulation: 0.4
     X.Org Video Driver: 25.2
     X.Org XInput driver : 24.4
     X.Org Server Extension : 10.0
(++) using VT number 7
(II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
(II) xfree86: Adding drm device (/dev/dri/card1)
(II) Platform probe for /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
(II) xfree86: Adding drm device (/dev/dri/card0)
(II) Platform probe for /sys/devices/platform/simple-framebuffer.0/drm/card0
(**) OutputClass "nvidia" ModulePath extended to "/usr/lib/nvidia/xorg,/usr/lib/xorg/modules,/usr/lib/xorg/modules"
(--) PCI:*(1@0:0:0) 10de:2520:1462:1305 rev 161, Mem @ 0x74000000/16777216, 0x4000000000/8589934592, 0x4200000000/33554432, I/O @ 0x00005000/128, BIOS @ 0x????????/131072
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="X.Org Foundation"
     compiled for 1.21.1.10, module version = 1.0.0
     ABI class: X.Org Server Extension, version 10.0
(II) Applying OutputClass "nvidia" to /dev/dri/card1
     loading driver: nvidia

and from udevadm info -a /dev/dri/card1, it basically tells us exactly how it is gathering which card is present:

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1':
    KERNEL=="card1"
    SUBSYSTEM=="drm"
    DRIVER==""
    ATTR{power/control}=="auto"
    ATTR{power/runtime_active_time}=="0"
    ATTR{power/runtime_status}=="unsupported"
    ATTR{power/runtime_suspended_time}=="0"

  looking at parent device '/devices/pci0000:00/0000:00:01.0/0000:01:00.0':
    KERNELS=="0000:01:00.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="nvidia"
    ...

The only time that a problem might arise, is if the user decides to try and tinker with nvidia-settings, that creates an Xorg.conf that puts in some nvidia-specific values, and switches to a host with an AMD (or Intel, I suppose) GPU. Or visa versa of what I just described. That is technically on the user at that point, and I'm pointing the finger at myself, since that's how I arrived at making this issue 😅

I think what the user should do (and what I now know I should do), is to put any GPU specific customization in the appropriate drop-in conf file at /usr/share/X11/xorg.conf.d/10-<amdgpu/nvidia-drm-outputclass>.conf. I believe that these are conditionally loaded via the MatchDriver value.

In any case, any failure with xorg would result in lightdm failing, and the solution that we are providing allows the user to understand that it is failing, and provides them with an opportunity to resolve it.

I even thought of a neat trick,t where prior to switching the user to TTY2, we could write out a little MOTD-like message to /etc/issue.d/lightdm-failover.issue, which then prints that message above the login prompt in the TTY.

from winesapos.

Hey @wallentx , thanks for the update! That all sounds good to me. The trade-off of GPU customizations via Xorg being not straightforward is okay as long as we at least document it in the README.md file. I like your idea of doing a MOTD or running wall to give the user a hint if they happen to get dropped into the TTY. Good stuff!

from winesapos.

Hey, @LukeShortCloud sorry, I feel terrible for holding this hostage. I've spent the past 3 days on my roof fixing a leak. I really hope I fixed it 🤞

I've went ahead and drafted a PR with the systemd service files, and will work on adding them into the install script now. I just wanted to make sure that what I've done is out and available, in the event that my roof caves in and I go afk for an undetermined amount of time.

I don't live in squalor, btw. Texas storms did a number on the trees around here 😛

from winesapos.