Steam Deck Platform Driver In No Apparent Rush For Upstreaming Into The Linux Kernel

[phoronix]

Phoronix: Steam Deck Platform Driver In No Apparent Rush For Upstreaming Into The Linux Kernel

Back in February 2022 prior to the Valve Steam Deck being released, a Steam Deck Platform Driver was posted for the Linux kernel. Sadly, more than two years later, this driver still hasn't been upstreamed into the mainline Linux kernel and it looks like it could still be months before it happens...

https://www.phoronix.com/news/Steam-Deck-Platform-Driver-2024

[timofonic]

It's ridicule! Valve invest many money in developers for the Linux ecosystem, yet this and other stuff isn't upstream in Linux kernel.

I tought it was already merged...


Why!!!?!?!??!

[kpedersen]

Why!!!?!?!??!

Perhaps there is more to computing than consumer games consoles?

[ptr1337]

Generally, their support for the kernel is not nice.
Weve worked on the Handheld Variant, and the Steam Deck is the most problematic thing on it at all.

WiFi Driver - is somewhat hacky, which does use different firmware then upstream. This has been also reported recently to ath11k maintainers, and they also wondered were they got the firmware from, and how hacky this is done.
See: https://lore.kernel.org/ath11k/CAFKu...abfbdcc1188ae2

The patches for sensors, Sticks and co are completely outdated from lkml, if https://gitlab.com/evlaV wouldnt copy their complete git to his own somehow, there would be nothing public how they do things. only due evlav it is possible to somehow provide support for these Steam Decks.

Generally, they are doing a good job, but the upstream work is somewhat not existent.

I would really wish, that Steam just opens their Gitlab officially and also trying to upstream more stuff.

[mdedetrich]

Generally, their support for the kernel is not nice.
Weve worked on the Handheld Variant, and the Steam Deck is the most problematic thing on it at all.

WiFi Driver - is somewhat hacky, which does use different firmware then upstream. This has been also reported recently to ath11k maintainers, and they also wondered were they got the firmware from, and how hacky this is done.

The patches for sensors, Sticks and co are completely outdated from lkml, if https://gitlab.com/evlaV wouldnt copy their complete git to his own somehow, there would be nothing public how they do things. only due evlav it is possible to somehow provide support for these Steam Decks.

Generally, they are doing a good job, but the upstream work is somewhat not existent.

Valve has upstreamed in plenty of other places that are relevant in context of Steam Deck, so it may just be a case of Valve wanting to make sure that their internal adjustments to the drivers are stable and working until trying to upstream them.

Upstreaming to Linux can be painful and slow, and Valve's foremost priority is to make sure the Valve Deck works for users. If correct there isn't anything wrong with this mentality as long as they eventually do upstream their stuff.

[pieman]

not upstreaming probably gives valve more control to do quicker changes. as they can push out changes, fixes, when they want to rather than waiting for the newer mainstream kernel being released. the steam deck is valve's first rodeo with a mobile device like this. i'm sure they want more control for the time being with their own internal release schedule.
i'm sure towards the end of life of the steam deck the stuff probably will be mainlined.

its actually one of things i kinda wished about gpu drivers. at first i was really happy with amd drivers being mainlined and apart of the kernel and mesa, but as time has gone on, i kinda wish they were out of tree. still open source, but out of the tree to be on their own release schedule to get amd specific fixes and improvements sooner. like it is on windows.

[pWe00Iri3e7Z9lHOX2Qx]

its actually one of things i kinda wished about gpu drivers. at first i was really happy with amd drivers being mainlined and apart of the kernel and mesa, but as time has gone on, i kinda wish they were out of tree. still open source, but out of the tree to be on their own release schedule to get amd specific fixes and improvements sooner. like it is on windows.

I'm all AMD here in terms of GPUs other than phones and my work MacBook. But the situation is a bit rough for slower moving distros. New GPU generally means new kernel + Mesa, which isn't the easiest thing for those new to Linux. Finding some repo that offers them or building them from source and possibly ending up with a non functional graphics stack on reboot is intimidating for them.

[dos1]

if https://gitlab.com/evlaV wouldnt copy their complete git to his own somehow, there would be nothing public how they do things. only due evlav it is possible to somehow provide support for these Steam Decks.

All their git repos are public, they're just distributed in tar.gz archives that this user then simply pushes to their GitLab account.

[timofonic]

Valve has upstreamed in plenty of other places that are relevant in context of Steam Deck, so it may just be a case of Valve wanting to make sure that their internal adjustments to the drivers are stable and working until trying to upstream them. Upstreaming to Linux can be painful and slow, and Valve's foremost priority is to make sure the Valve Deck works for users. If correct there isn't anything wrong with this mentality as long as they eventually do upstream their stuff.

I'm not the typical user, but not upstreaming changes drives me away from it. They released the hardware in 2022 and not yet into upstream? I'm sorry, that's a no go to me.

[mdedetrich]

its actually one of things i kinda wished about gpu drivers. at first i was really happy with amd drivers being mainlined and apart of the kernel and mesa, but as time has gone on, i kinda wish they were out of tree. still open source, but out of the tree to be on their own release schedule to get amd specific fixes and improvements sooner. like it is on windows.

I'm all AMD here in terms of GPUs other than phones and my work MacBook. But the situation is a bit rough for slower moving distros. New GPU generally means new kernel + Mesa, which isn't the easiest thing for those new to Linux. Finding some repo that offers them or building them from source and possibly ending up with a non functional graphics stack on reboot is intimidating for them.

Yeah I have been harping about this like a broken record and its still amazing to see the amount of cope from diehard Linux OS people trying to justify it. The Linux design where its basically enforces/strongly encourages drivers to sit in the tree has a significant amount of drawbacks (I mean its not surprising, this monolithic design is an outdated one from the 90's and all other major desktop OS's have moved away from it for this exact reason).

And as you rightly pointed out, this has nothing to do with licensing. Out of tree drivers can still be GPL2 (or compatible license) and Linux can still enforce that only GPL2 out of tree drivers can be used in this way, what its strictly about is Linux implementing a graphics ABI that is stable across multiple major Linux versions.

If this was the case, Valve could have easily worked on their graphics drivers outside of the release cadence of the Linux release cycle without having to fork an older stable version of Linux and manually patching it so that it works on Steam Deck properly.

I'm not the typical user, but not upstreaming changes drives me away from it. They released the hardware in 2022 and not yet into upstream? I'm sorry, that's a no go to me.

As you can see from the discussion, this is not Valve's fault but rather Linux's development model is to blame. Linux is the only part of the software stack that Valve is not upstreaming (at the moment), that alone should be indicative enough of where the problem lies.