Some hardware stuck at 15W TDP in gamescope-session
Writing this here so we have a place to track this.
@d3Xt3r has this issue and we confirmed earlier today it is not related to https://github.com/ublue-os/bazzite/issues/320
ENABLE_HARDWARE_CONTROL_ON_NON_DECK_HARDWARE is set to 0 so /usr/bin/steamos-polkit-helpers/steamos-priv-write is disabled, yet the TDP gets set to 15W in gamescope.
They are currently using the dirty workaround from the #320 issue until we can track down the cause.
@d3Xt3r if you could provide rpm-ostree status, rpm-ostree kargs and also the hardware of the affected system it might help to get us started on looking into this.
For now, if anyone stumbles upon this issue, use the workaround provided here: https://github.com/ublue-os/bazzite/issues/320#issuecomment-1725206390GitHub
HTPC (bazzite-deck) amdgpu stuck at 15W (with workaround) · Issue #...
so i recently moved my old htpc/guestPC build from chimeraOS to bazzite deck as i wanted something that mimicks the steamdeck more closely in terms of desktop ui as my friends understand kde better...
Solution:
Jump to solution
I can confirm that the fix works 🙂 TDP is back to normal, permissions stay on 644. Tried going in and out of game mode as well as launching different games. This was tested without LACT.
Afterwards I installed LACT and tested - good news is that I can still change the TDP via LACT and the value persists after a reboot. 🙂...
303 Replies
@Kyle Gospo any thoughts about how this could happen, since this is the 2nd person it has happened to now? since i thought this was only done through
steamos-priv-write 🤔
might need help tracking this down when youre back from scale and d3xt3r provides us with the details i asked for 🙂
and if we dont find it out, i can make an ujust command for the dirty workaround i originally made as it should not impact performance, its just annoying.No clue, should only be priv write
Nothing else has root access to limit it
Unless explicitly installed
simpledeckyTDP for instance will use ryzenadj
So if that's installed, there's your TDP limit
think they said they only installed lact but didnt do anything in it.
at least there is the brute force workaround i made back in the beginning 🤣
i hate it
Okay, some good news and bad news. I decided to wipe my drive and reinstall my bazzite-deck from scratch - fresh offline ISO, installed and updated to latest stable. Didn't install LACT, Decky or anything of that sort. Ran
Edit: So I suspect that 30W thing is just a MangoHud reporting glitch,
cat /sys/class/hwmon/hwmon0/power1_cap_default and it now shows 212000000! /sys/class/hwmon/hwmon0/power1_cap_maxalso shows 280000000, which matches with what Adrenalin in Windows showed. So that's all well and good.
Unfortunately, it didn't really fix the my slow game performance. I tried maxing out the game settings to see how far I can push the GPU but it seems to max out around 526MHz and 30W, and this is happening in all games (both native ones like Last Epoch and Proton ones like Diablo 4). This is happening in both desktop and game mode btw. Also tried running furmark and I was only getting 5FPS and again, the power did not exceed 30W.
I'm not sure where it's getting that 30W limit from. Is /sys/class/hwmon/hwmon0/power1_cap_max the right path? I could run LACT to double-check but don't want to risk changing any values. What do you guys think?/sys/class/hwmon/hwmon0/power1_cap_default still reports 15000000 so ignore the above.
GitHub
bazzite/spec_files/jupiter-hw-support/priv-write.patch at main · ub...
Bazzite is an OCI image that serves as an alternative operating system for the Steam Deck, and a ready-to-game SteamOS-like for desktop computers, living room home theater PCs, and numerous other h...
This is the patch that should prevent this from doing anything
Feel free to install LACT, that's easily disabled
Curious what you find
echo "commit: Skipped - see /etc/default/steam-hardware-control" | systemd-cat -t p-steamos-priv-write -p warning
It also writes logs
So it's worth checking that
journactl has the following logs:
Which is interesting because I don't have a any power2* files in that path.
I also installed LACT and it is showing 15W, and it looks like this is being set in
/sys/class/hwmon/hwmon0/power1_cap.
Edit: Now that I look at the log again, maybe that decline is not working because it's writing to a non-existent file?
---
Btw @HikariKnight:
rpm-ostree kargs :
rhgb quiet root=UUID=5125c6a7-d169-4e52-9a0c-8e010e37cdeb rootflags=subvol=root rw ostree=/ostree/boot.0/default/200d6b192b97a3b6e644cd8b288f642db8fc254676a0b2c9811df40aba3d5a44/0 gpu_sched.sched_policy=0
specs:
---
i see nothing that should cause it to do this
Any reason why steamos-priv-write is refering to power2_cap when it doesn't exist?
it refers to it because thats where gamescope-session tells it to write to
if steamdeck or hardware controls enabled then commit the write
otherwise skip it and declinewrite
decline is at the bottom of the script and runs this
i am curious if this also happens on the desktop image
From the comment from the other guy, apparently the desktop image is fine
ok so it is one of the packages in the deck image that does this 🤔
thats going to take a while to go through
@antheas could this be adjustor?
Needs to be explicitly turned on
Good, good
Really confused what's setting this then
Also only supports 2 cpus
But never hurts to open hhd and verify
Also only writes to the cpu
We have gotten another 1-2 reports from egpu users though
I was trying to see if ryzenadj also changed the tdp limit of amd gpus
Results were inconclusive
also seems to only affect some hardware as i cannot replicate it with RX6600XT and Ryzen 5 5600x
I had the same issue with a 6600 XT, same desktop. Actually bought my GPU because I thought my 6600 XT was too old/slow for Last Epoch lol, didn't know about the TDP limits then.
huh, this is getting even weirder then
Seems like steam is setting the limit for some reason
15w is steam deck I mean come on
yeah it is, it is just weird it affects a super small subset of hardware and its setting it in a different way than the rest of steamos which uses
steamos-priv-writeStill needs a polkit though
No sudo perms
Somebody lsof the file and see who's writing on it
would have to do that on an affected system since i cant replicate it on my own (even with the same card as they previously had)
Im affected by this, is there anything I can do to help?
do you have a 2nd system you can ssh into bazzite with to do some testing?
sure, let me find a charger for my laptop
awesome, maybe we can get some good data then
starting my windows laptop for the first time in a bit and I had to reset my pin for some reason :s
ok
its finally up and running
ok so you familiar with ssh from before?
not more than this
thats all the familiarity you need 😄
sweet
give me 2 sec
watch -n 0.1 lsof $(find /sys/class/hwmon/*/ -name "power1_cap")should give you something like this
yy
ok go into desktop mode on the htpc then back into gamemode while watching that and tell me if anything shows up (it might just flash there for a sec so make sure you keep an eye on it)
hmm, nothing showed up
ok can you open another ssh window to bazzite and write this
cat $(find /sys/class/hwmon/*/ -name "power1_cap")_default | sudo tee $(find /sys/class/hwmon/*/ -name "power1_cap")
then go to desktop and back to gamemodeok
nothing showed up
but its set to 303w now
thats the default for the card
can you try launch a game while keeping an eye on the ssh terminal?
it should in theory stay at 303w
nothing showed up and the game Im launching should run at 100+ fps at default w but its at 10
so I guess its not at 303w :p
mangohud reports gpu: 100% 41w
sorry, I missunderstood, let me try running that command and then starting a game
you can also
cat $(find /sys/class/hwmon/*/ -name "power1_cap") after game has started to check the TDP set on the gpu
so 12w?
echo "commit: Skipped - see /etc/default/steam-hardware-control" | systemd-cat -t p-steamos-priv-write -p warningreturns nothing
sorry
journalctl -xe -t p-steamos-priv-write
that should show you all the logs from steamos-priv-write this boot which is what sets the tdpit shows up a bunch of times with power2_cap at 15000000 and 12000000
able to copy+paste it in here?
or do you want an entire job identifier?
would like the entire thing so i can see if it skipped things or not
sec let me try something
journalctl -xe -t p-steamos-priv-write | fpaste try that
gives me everything that is relevant in 1 link that you just send here 🙂can you
cat /etc/default/steam-hardware-control for me and
/usr/libexec/hardware/valve-hardware ; echo $?whops
remove cat from the last command XD
also i guess you installed simpledeckytdp?
/usr/libexec/hardware/valve-hardware ; echo $? you forgot the ? at the endah sorry
and yes but uninstalled it when hhd got the ability to do tdp control
ah well can you
sudo nano /etc/default/steam-hardware-control and change the variable to 0 and then reboot and see if that fixes your issue
as yours might not even be related to this issue thenok, doing that put my gpu at max power usage limit
wait
it might be because the workaround didnt get removed when I removed it? :s
yep, simpledeckytdp enables steam hardware controls when we install it.
did it fix your issue at least?
Let me reboot one last time after properly removing the workaround from github
ok yes, that did solve it for me
ok well it fixed it for you but this lead was a dud for us 😅
oh well
maybe for now remove the hardware toggle for SimpleDeckyTDP. The feature is optional, not required, for the plugin
it's only required if the user wants to patch the Steam TDP and GPU Sliders
Replace the env variable with a check for simpledeckytdp
Write a file to /tmp
i like this option better
And have the poll check it
well, thanks for the help and sorry for not helping :HaHaa:
well that works too, lol
dw @azu it happens
Or make the commit fail return the Same as writing
So that steam is not confused
And rename the env variable
Unless you actually want it to write
isn't the hardware toggle required for bazzite on actual Deck hardware?
or is that separate?
its auto enabled if it detects deck hardware
hmm considering this is running as root, would need to find a way to actually detect the right user (incase someone went and added/removed users)
That's why I suggested a var
But it will break the current decky version so
@Aru im not familiar with decky plugins, but would it be possible for simpledeckytdp to write a file to tmp if it is active? 🤔
yep, should be possible
there actually already is
log file
/tmp/simpleTDP.log
oh nice
will that one be there no matter what?
Sup guys, just joined in. I'm free now if anyone wants to do any troubleshooting/tests.
it'll only be there after decky finishes initialization after boot
but never gets deleted by the plugin itself
if you are able to do the same stuff i got azu to do, then that would be helpful 🙂
however please
cat /etc/default/steam-hardware-control first and make sure that variable is set to 0oh, but if the decky loader systemctl service itself ever gets reset, it's temporarily cleared out until decky finishes re-initializing
Is ssh enabled by default btw?
thats fine as long as its there after decky is initialized its enough of a signal that simpledeckytdp is there
Btw 0 is true in bash
Inthink
no
sudo systemctl enable --now sshdWill still break egpus even with simple decky tdp installed
only if you are checking for exit codes
variable or i write a function to detect egpu, but i do not own one myself so i would need help from someone who owns one
Egpus are on the todo although I don't know what would be useful on them
most of them are limited to 4 pcie lanes right? (excluding oculink)
or was it 8
yeah most of them are limited to 4 lanes
yeah so that alone is one thing to look for if i can probe it
either way, that variable was set to 0 for you?
yep it's set to 0
if it was 1, set it to 0 and reboot to see if that is enough to fix the issue (obviously disabling the workaround we did)
and to clarify I don't have decky etc
ok
open 2 ssh windows to the htpc, in one you run
watch -n 0.1 lsof $(find /sys/class/hwmon/*/ -name "power1_cap")
and keep it always visible to you
the 2nd one you will use for other commands when we need themso that does nothing
its supposed to be blank
from my understanding, you can't use lsof because it's sysfs and it's not an actual file
I just tested it by manually chaning the value via LACt
I can confirm it's changed locally
well crap
but lsof doesn't pick it up
hmm
journalctl -xe -t p-steamos-priv-write --follow
that will be our best bet then
then go into desktop mode, then back into gamemode and see if it changes the tdp
fire up a game and see if that changes the tdpcool. FYI I'm starting off with 280W via LACT
thats fine
ideally it should just show skipped, checking and declines as you do all of that
entered game mode, journactl updated:
went back to desktop mode, no change in journalctl but my TDP has changed back to 15
that is something, it is definitively not done by steamos polkit helpers
or at least not steamos-priv-write
hmm
we are done with journalctl, can you switch it to
watch -n 0.1 cat $(find /sys/class/hwmon/*/ -name "power1_cap")
then change the tdp back to whatever you want
then do the same process and tell us exactly what action changes the tdpsure
(also reset the tdp manually if you want to check different actions)
yep
this is the reset tdp command for reference
cat $(find /sys/class/hwmon/*/ -name "power1_cap")_default | sudo tee $(find /sys/class/hwmon/*/ -name "power1_cap")
so you dont have to dig it upokay so it changed to 15 as soon as the steam startup animation started
when I entered game mode
ok
I changed it back to 280. Launching a game now to see if the value changes.
yeah was going to suggest that
Okay been inside a couple of different games, proton and native, and the value stays
performance is also good
@Kyle Gospo we got something but not much to go after
steam/gamemode sets tdp to 15W once during the animation phase on each session start on affected hardware.
doesnt help much but it is something we could add a check for maybe 🤔
we dont know the requirements to make this trigger though
It uses the polkit?
maybe but not using
steamos-priv-write like the rest of gamescope-session
so it is something we can start dig into at leastcan't we just have a systemd service that sets the TDP to power1_cap_default (or a user-defined variable for custom TDP) - but before doing that, check if DeckyTDP isn't installed first (in case users want to use that to control the TDP)?
That should then work for both handheld and HTPC users
a systemd service is a dirty workaround, we would more ideally like to prevent it from happening in general
It has to do this or similar
Steam doesn't have root perms
I know that steam will write to the brightness slider directly if it can
Check for file perms on the gpu
@d3Xt3r can you
ls -la $(find /sys/class/hwmon/*/ -name "power1_cap")Because I don't have the polkit think it changes my brightness fine
-rw-rw-rw-. 1 root root 4096 Mar 17 11:05 /sys/class/hwmon/hwmon0/power1_capyeah should be rw-r--r--
There you go
sudo chmod 644 /sys/class/hwmon/hwmon0/power1_cap then reboot
see if that fixes it permanentlyIt won't I'm pretty sure sys gets recreated every reboot
Now you have to play the game of who set the permissions
i know steamos-priv-write changes the permissions if steam hardware controls is enabled
which is why i want to try change it then reboot
since if it changes it, it will be in the journalctl
but yes, i do suspect it will recreate it on boot. still rather sanity check since my system isnt affected 😄
Seems it will change perma
Sounds like a terrible idea but
Seems like the hw check fails then
At least once
okay so switching to game mode doesn't change the value
but after a reboot, it goes back to 15W
with the new permissions that is
permissions are back to -rw-rw-rw-
or if user installs simpledeckytdp once
ok so something else sets the permission on boot, at least it is something we can maybe look for
just to sanity check
@d3Xt3r can you set the permissions to 644 again then go desktop --> gamemode
Permissions persist when just switching between desktop/gamemode.
ok so it happens at early boot
I think it's that script
Probably the hardware check fails once
During early boot
only one way for us to test that
i will make a pr to testing
@HikariKnight merge Master into testing before you open that
So it's against what's current
And actually just feel free to commit to testing
That's what it's for
@Kyle Gospo i can push directly to testing right?
Yep
Curious to see what your potential fix is
Probably would be faster to pull the rpm and replace it on your machine
my machine isnt affected so i cant test it, so testing would be better then
@d3Xt3r once this finishes building, can you try rebasing to testing and see if that fixes it 🙂
https://github.com/ublue-os/bazzite/actions/runs/8311112126
GitHub
Build Bazzite · ublue-os/bazzite@dd78ccb
Bazzite is an OCI image that serves as an alternative operating system for the Steam Deck, and a ready-to-game SteamOS-like for desktop computers, living room home theater PCs, and numerous other h...
specifically the deck image you use
@d3Xt3r do a rebase from terminal
Rather than steam game mode
I'm testing the former still after we simplified ublue update
and if this fix does not work i will try a run where i just outright remove the chmod for anything that is not a deck
I think the deck check might fail. Can you link it?
@d3Xt3r hows the rebase going? 🙂
The build failed. 🙂
nope, only the asus surface build failed
Ah right. Rebasing now
👌
@HikariKnight Rebased, no joy. 😦
ok i will just rip away the whole thing then to test
then i will go to bed
No worries
ok i removed the chmod entierly from
steamos-priv-write
if this does not work then there is something else causing this and we will have to look at something else (also please do verify the permissions for the file after reboot with ls -la $(find /sys/class/hwmon/*/ -name "power1_cap") )
once this finish building (main, bazzite-deck for kinoite or silverblue) you can ujust update in testing
https://github.com/ublue-os/bazzite/actions/runs/8311655935GitHub
Build Bazzite · ublue-os/bazzite@534c84d
Bazzite is an OCI image that serves as an alternative operating system for the Steam Deck, and a ready-to-game SteamOS-like for desktop computers, living room home theater PCs, and numerous other h...
ideally we would keep the chmod in there, but i removed it mainly for testing, if it works i will add back the deck check as a minimum, if it does not work then i will revert it
anyways good luck and goodnight
@d3Xt3r how did it go? 🙂 also morning
Morning. 🙂 No luck sadly. Still 15W and permissions are still the same.
Ok I will revert the changes then. Might also become a non issue in a future kernel update since it seems that being able to set the power cap that low to begin with on the cards (other than APUS) is a bug in the amdgpu driver, and how it was dealt with was based on how the board partner configured the firmware which explains why this is not affecting everyone.
I do wonder if they will deny the lower than power cap min write or if they will convert it to the minimum cap though.
hmm
Does not explain how the permission is changed in the early boot though
If they do just deny writes lower than the minimum power cap that will inadvertently fix the issue 😂
there's some interesting discussions here https://lore.kernel.org/amd-gfx/6e93a748-786e-4aca-9b97-65b25e664436@leemhuis.info/T/#m88ef9189ceaff46e9b7be387784c7409af3ba755
Yep that's the discussion I'm referring to
I will make a patch that resets the perms and power cap as a workaround in priv-write
Hopefully this will be enough. If not we will have to do a startup service.
Oh hold on that looks familiar
I think fsync patched this
https://pagure.io/kernel-fsync/blob/6.7/f/SOURCES/amdgpu-ignore-min-pcap.patch
ok so we still need to patch on our side then 🤣
im making a patch file atm, apparently the current one is malformed so i just redid it
havent written .patch files before though so hopefully i manage to get it done correctly
so this looks promising at least when i manually force the conditions
@Kyle Gospo seems like the patch is not applied, guess i have to rebuild jupiter-hw-support to test the fix but idk where to do that 🤔
this should fix the issue though
https://github.com/ublue-os/bazzite/commit/681e2df75fc22f8131c0ccd0600c19c7c873b8d3
GitHub
fix(deck): fix random gpus stuck at 15W tdp · ublue-os/bazzite@681e...
where power_cap randomly becomes writable on boot
requirements to trigger the fix:
- steam-hardware-control is disabled
- tdp is 15W
- power_cap is writable
- default power*_cap is more than 45W
also fixed the valve-hardware check, the brackets were in the wrong place
Download the spec file
Swap out the patch for your own and put it in the file
Build and layer it
With ostree replace override something
Find the command in the dockerfile
well i have 0 knowledge of building rpms outside of config (which has a build script with the right stuff provided) and i couldnt find the right args for it from kyles copr when i glanced at it, so i will have to look at it later.
need to go handle life right now 😅
The patch is there, but it needs a karg to be effective
didnt add a karg, i patched
steamos-priv-write to fix the power*_cap permission if it is wrong and reset the power cap if the default is higher than 45W and the cap is set to 15W and steamos hardware control is disabled (and obviously if it is not valve hardware)
and steamos-priv-write was still the old one when i rebased to testing, most likely since the file is from your copr builds@HikariKnight is that change in main?
I'll kick off a build now
no its in testing
i can put it in main if you want
That's fine actually I'll do a one off copr build
new hhd build is out
hopefully that change will at least fix the affected cards as soon as gamescope tries to change the tdp
Yeah, it's a safe assumption
ok it built, can kick off testing again and it should have the updated version
@d3Xt3r there is a new testing build with the changes (assuming its not
bazzite-asus-deck as that one failed), can you test that when you can and tell me if it fixes the issue 🙂Still no luck unfortunately, 15W and rw-rw-w.
even when you start a game?
yep
hmm
can you give me your
journalctl -xe -t p-steamos-priv-write | fpasteonly three lines so:
rpm-ostree statuswhat happens if you try to run a game again?
checking
hmm, strange
I'm in game now and the voltage is now my default
212000000
perms are still the same though
ok so that part worked
this part didnt though 🤣
i will adjust it a bit though and that might be enough
btw @d3Xt3r can you give me your updated journalctl?
just want to double check everything went off there
thats all?
supposed to look something similar to this
yep that's all that's in there
with the two
fix: lines being new
its what happens when you ran the game a 2nd time in theorylemme reboot and check again
I also did a
reset to uninstall lact btw, just in casereboot, run game 2 times (or if it works on first run thats enough) then grab the journalctl for me
just want to see if the fix portion actually triggers, since it should trigger if
- TDP is 15W (going to change this to if TDP is being set to 15W to make it hopefully trigger earlier)
- Default TDP is higher than 45W
- Steam hardware control is set to 0
- power*_cap is writable
okay, no change
still the same three entries, no fix:
the entries are generated after booting up
even when starting the 2nd game?
yep
but the tdp is right on the 2nd run?
yep
ok can you do a quick test for me
do
sudo rpm-ostree usroverlaydone
then edit
/usr/bin/steamos-polkit-helpers/steamos-priv-write
use nano if youre not comfortable with vim (must be edited with sudo)I'm alg with vim. In the file now
then scroll down and look for
power*_cap
there is an if statement inside the else block
can you change the first condition to
"$WRITE_VALUE" == "15000000"yep it's sthere
no the current one is different
wait so change WRITE_PATH to WRITE_VALUE ?
yes and remove the
$(cat ) portion
and make it exactly what i showed
line should look like this
like this?
(before I :wq)
yep
save it and set the tdp to 15 then test again by running a game
and check journalctl afterwards
if that adds the
fix: entries then we got something that should trigger properlyI saved the file but I'm unable to change the TDP back to 15
let me get the command
echo 15000000 | sudo tee $(find /sys/class/hwmon/*/ -name "power1_cap")ran that, still not changing
hmm
stat -c %a $(find /sys/class/hwmon/*/ -name "power1_cap"666
hmm
can you try this instead?
ok
I saved the script but I'm still unable to change the TDP. Note that I didn't run the script - am I supposed to do that first?
nope
script runs each time you start a game
or when gamemode starts on boot (but we cant test that since the change vanishes on shutdown and reboot)
as gamemode tries to change the tdp on bootup and game start
so just try launch a game each time we change the if statement then check the journal
k
still no new entries
echo 15000000 | sudo tee $(find /sys/class/hwmon/*/ -name "power2_cap") then, i saw it was power2_cap for you sorry 😅alg, trying again 🙂
Still not changing
Checked both power1 and power2
huh doesnt have a default cap
I think we were catting the wrong thing
this worked:
maybe, but system tries to edit power2_cap 🤔
out of curiosity
ls /sys/class/hwmon/hwmon0/
no power2 stuff
odd
i would like
journalctl -xe -t p-steamos-priv-write | fpaste though so i can have the log with timestamps
also will have to think of another solution
but the systemd workaround did work right when you tried it?https://paste.centos.org/view/a305b453
Yeah the systemd workaround works fine
Although aftewards I just made a simpler service that directly sets the power1 value to my max TDP without a script (I have disabled that service btw)
yeah i wrote mine to be universal 😅
ok so this was a dead end @d3Xt3r
willing to try make a systemd system service that just
chmod 644 on your power1_cap on boot and see if that is enough?
or chmod it and reset the power cap
if a chmod is all that is needed that is an easy thing to fixsure thing, will try just the chmod
@Kyle Gospo @Aru we verified that asusctl sets tdp on ac/dc events, unsure about suspend
also adjustor does fan curves now so no reason for ally image
also i suspect ppd might be doing some funny business
but as you said it doesnt autoswitch on ac/dc events
So the service with just the chmod does the trick, perms are preserved and my cap is set to the default value (212)
ooo nice it survives a reboot?
yep
We don't use ppd
And neither tuned nor PPD touch power limits
In any way shape or form. They also don't care about your power state
And lastly, they don't even do anything unless you're on the desktop
Game mode doesn't touch them
Except to reset to balance if it's set to power save upon entering game mode
@Kyle Gospo i will undo the patch i did (but keep the fixes to your if valve hardware conditions) and make a service file that will make sure power*_cap has the permissions 644
as that seems to prevent the issue
no idea what sets the permission at boot for select hardware sadly
Sounds good, wish I knew literally anything about why this was happening
same
but a single shot service is better than the old workaround that ran every 3 seconds
they set the platform profile
that sets the tdp on the ally
Yes, but doing that will not affect a desktop gpu, especially setting it to 15 watts
They can set the platform profile as well, they do not by default
im talking for the ally
not an egpu
They would have to be configured to do that
ok if they dont and just do the governor
thats good
And PPD flat out just can't
tuned sorry cant tell the difference
No worries, that's the whole intent
If you could tell the difference it would be a bad change
so does this mean platform profile?
PPD profile
Which is mapped to tuned profiles
i think its supposed to update the platform profile by default
in fact kind of by definition
oh yes im in the wrong thread lol
i opened a PR and i also pushed the files to testing so that @d3Xt3r can test it properly (when this finishes building https://github.com/ublue-os/bazzite/actions/runs/8319288590), once they verify that it works you can merge this https://github.com/ublue-os/bazzite/pull/892 @Kyle Gospo
i will be heading to bed now 🙂
GitHub
feat(deck): add tdpfix for cards that has their sysfs writable on b...
Bazzite is an OCI image that serves as an alternative operating system for the Steam Deck, and a ready-to-game SteamOS-like for desktop computers, living room home theater PCs, and numerous other h...
GitHub
feat(deck): add tdpfix for cards that has their sysfs writable on b...
We do not know what causes a super small subset of GPUs to boot with sysfs writable on the deck images, but this will at least set the permissions back to 644 and reset the TDP at boot if it was me...
the service should at boot
- if the permissions on power1_cap is 666, change permissions to 644
- set TDP back to default if it is set to 15W and default TDP is higher than 45W
once that is done it will not run again and any software/firmware will handle TDP from there on.
45W was selected to avoid stepping on handhelds TDP and lowend cards
you can verify by running
journalctl -xe -t bazzite-tdpfix after bootSolution
I can confirm that the fix works 🙂 TDP is back to normal, permissions stay on 644. Tried going in and out of game mode as well as launching different games. This was tested without LACT.
Afterwards I installed LACT and tested - good news is that I can still change the TDP via LACT and the value persists after a reboot. 🙂
Awesome
I did notice a weird issue though, probably unrelated but just incase
The overlay (guessing MangoHud?) isn't detecting my GPU anymore.
Unrelated, mangohud does that sometimes and future updates to it fixes it again
I will get the fix merged into stable today
Nice, and thanks for all your work, I really appreciate it. 🙂
sorry for asking but do we need to wait for a patch or whats the manual fix/Update exactly?
Nice job Hikari!
woah hey, do you think applying this patch would fix that nonsense I had with my EGPU? I can hopefully test later
yes the patch fixes those issues
steam set the tdp to 15w due to a permissions issue
no kidding. that’s awesome
GitHub
Build Bazzite · ublue-os/bazzite@8a9d890
Bazzite is an OCI image that serves as an alternative operating system for the Steam Deck, and a ready-to-game SteamOS-like for desktop computers, living room home theater PCs, and numerous other h...
let us know 🙂
didnt test on egpu, but if it does not work, let me know @Roboid and we can patch it to detect and apply the fix, atm it just searches for power1_cap and sets permissions on that if it is wrong
yes that should fix egpu too
probably, same file
Rad, thank you
also i would like to know if it also worked for egpu 🙂
you can verify with
journalctl -xe -t bazzite-tdpfix after bootAbsolutely! I will test when I’m able to get back to my setup. Not 100% sure when that’ll be but I’ll ping/reply.
thanks 😄
Hey I’m sorry, I’m very new to not just Linux but GitHub 😅 how exactly do I go about testing this?
go into desktop mode, open the terminal (ptyxis) and type in the journalctl command i sent
it should tell you if it fixed the tdp
I mean how to actually install the fix, haha… I’m not seeing an image for Bazzite 2.5.0 I can use with the pull requests merged. But I downloaded the tdpfix script and service and am trying to install them manually now
you can just update, it's been part of the images for a couple days now
you can delete what you downloaded
Oh, I ran ujust upgrade today, so I should be fine. Thank you
should look like this when you run the command if it fixes the tdp at boot
For some reason, it just gave a bunch of tildes with line breaks and then - -No Entries - -
means it never triggered so it doesnt fix the issue
let me get a command for you to run to find what i need
@Roboid
can you run this
that should been covered, whats your
rpm-ostree status | fpasteI actually got it working! With a small caveat. My issue was that I had the TDP slider default set to 30W, so the script wasn’t catching, because it’d set the EGPU max watts to 30. But I set the default to 15W and it makes the script work for the OneXGPU. even in game mode!! cc @antheas
the script would have made the life listed in the link be rw-r--r--
the only weird thing is the EGPU has a Turbo button on it that takes it from 100W to 120W max. Pressing this button lowers the W of the card back to around 15W instead of increasing it.
well the tdpfix should have triggered on that card though during boot
what device is this?
It’s the OneXGPU. it’s a 7600M XT in an enclosure that connects through TB3
Let me switch back to desktop real quick. I think it IS triggering. Maybe I need to enable the turbo before boot
oh wait you said it had a button that put it into 30W mode, yeah then the script wouldnt trigger on it since it only fixes the tdp if the default tdp is more than 45W
so just out of curiosity
just curious if this can give me some ideas as to why it didnt trigger the script 🤔
I’m sorry let me be a little more clear. I’m using a handheld computer with an attached EGPU. The script did not work when I was using a 30W TDP default for the handheld, but it did work when I lowered it to 15. Separate from this, the EGPU has a default 100W draw that can be increased to 120W by pushing a button on the front (the GPU does not remember this setting so you have to do it every time). Pushing that button was setting the draw of the EGPU down to 15W somehow. However, it seems to work as expected if you press the turbo button during startup, rather than after boot like I had.
oh right yeah because the bug is triggered by steam setting the tdp to 15W because that is the actual bug
needed the script to target the 15W bug to avoid messing up other handhelds settings. but with more testing we might be able to make it work since it seems to be early enough in the boot to not matter
You might be able to test for a dgpu
And then always do your fix
Switcheroo's detection has been patched to be quite robust
Just checking, are you on the testing image?
the script is already on the stable image
i just remembered it currently sets the permission and then checks the tdp and reverts that to default tdp afterwards as 2 separate steps and they trigger independently, so it should just be automatic as long as nothing else fiddles with the tdp afterwards like steam
so it shouldnt care what the card is, if the permissions are wrong, fix them
if the tdp has managed to be set to 15W and the card has a default TDP above 45W, fix that afterwards
Another potential option is we modify the loop to exit after it finds the first one.
Since the first one should always be the iGPU
That's in the polkit helper
this doesnt run a loop though
Not your fix, the steam TDP setter
ah
yeah that should work but the way it searches for the cards it can be any hwmon and the first one might not be the igpu always i think?
Could test it with switcheroo
I'll play with the concept