Repository navigation
simple cli utility #164
Description
Describe the feature idea
A simple cli utility to update things on the steam deck.
I used this in streamdeck-linux-gui to display my obs recording time.
Something to change text would be great.
I should probably work like this (or simelar):
actions.py --device 1092 --page 10 --button 3 --label set "wellcome"
Activity
Core447 commentedon Jul 13, 2024
This is not a priority right now, but if I have some time I can add this. For now you can use the OBS plugin to show the current recording time. Currently there's an option to change the current page via the command line using the
--change-pageargumentmarvin1099 commentedon Jul 14, 2024
Yep I saw that the obs plugin has a timer included, thats nice,
it would still be nice if a interaction over the cli was possible,
the change page arg is already nice there just inst that much
you can do with it if you want a reactive button.
Take your time, the main feature i used this for in streamdeck-linux-gui
was showing the real time and the obs rec time,
these are both supported, so all ready pretty nice.
Core447 commentedon Jul 14, 2024
A short-term alternative might be to add a auto-run option to the "Run command" action and use its "show output" option
marvin1099 commentedon Jul 14, 2024
I have thought about that to, i mean how difficult would that be, it would be nice to have.
Well the long term cli option is still nicer,
but I'm fine for now if you implement the auto run option.
In that case it will probably make sense to have two commands.
One that gets executed every x seconds, for that one we show the output.
And the second one we execute when the button is pressed.
The way this could then be used, would be, that in the main file,
we could then detect a file or something that gets created by the button script.
Well that's my first thought is at least.
Feel free to adjust this in a way that makes sense in your context.
Or here is a other way that also works.
Maybe we add a argument to the script that gets run instead.
So we have one file that gets executed each x seconds,
that we show the output of and we just pass the button state as argument,
for that the script may be run when the button is pressed / unpressed with the arg
or it could be added to a waitlist.
Core447 commentedon Jul 16, 2024
I added a simple auto run feature to "Run command" with StreamController/OSPlugin@8d7c733 (available in the store), what do you think?
marvin1099 commentedon Aug 6, 2024
I do like the option,
but a option to add argument in the command box that will send the button status to the script, would be so good.
the status could be "autorun" or "pressed" or "released".
The box input may look like this:
where %s will be replaced by "autorun" or "pressed" or "released".
That way it can be detected if the button was pressed / released and still display live info.
For "released" a option to run the script on release would be needed, so I'm not shure how viable that is.
Core447 commentedon Aug 7, 2024
That's already possible using the event assigner.
I think adding the argument stuff is a bit too much for the "run command" action, environment variables might be nicer. However, with a way better cli coming at some point, idk if it's really necessary.
marvin1099 commentedon Aug 7, 2024
Using a env var would also make it impossible to tell what button was pressed,
the single argument I'm suggesting i think is a good option,
the thing is how else will i tell if a auto run button was pressed,
some way to check this would be great.
You can of course suggest some other way of doing this if you can think of it.
Let me also give an example of when this would be useful.
lets say we have 3 types of live info we want to see,
lets assume battery time and gpu encoding,
this is just a examlpe of course, this could be any live info we can get from the terminal.
so this would be a lot of info all at once so instead switching between the info might be a good idea,
thats where this feature comes in, it can then be detect the user presses and swap what info we display.
Core447 commentedon Aug 13, 2024
I don't want to add a ton of options to the "Run command" action, but what about a separate "Run script" action that is meant for such things and provides the arguments etc?
For swapping you can already use states with their own actions (e.g. "Run command").
marvin1099 commentedon Aug 13, 2024
Like it, that would be nice I think,
well take your time,
Now that you mention it the idea I had can be solved by having 2 run command actions.
But I think its still a good idea,
The reason is that then pressing a button and releasing it can then be detected by a script,
Then users can have custom button patterns.
(if they can realize then in a bash script or something like it of course.)
By using "run script" you could have:
Do something specific if button was pressed for around one sec, released for around one Sec, then pressed once more. And do something else if its just pressed once.
Well that's what I think at least,
give it some thought.
Thanks for all the awnsers,
and the implementation of some things I have asked for.
teras commentedon Sep 29, 2024
When I try to use the command line option
--change-pageto use the app in a script, the command works but the app keeps popup, which might be distracting. I believe the expected way should be to silently perform the action and exit, if command line arguments are present?About states, I am confused, I don't see a way to change the state of the button through command line options. The idea that I am trying to immitate is, to have a lock-like icon. When the icon is unlocked, then when I enter a page, the page will jump back to the home screen (this feature is already implemented. But if, in the mean time, the user presses the lock icon, then the page is "locked" and won't jump to the home page.
I am not asking to implement this feature. Actually I am a long time streamdeck-(linux-)ui user and I had created a "daemon" script that was doing a bunch of clever stuff, most of them you already have (and well done! 👏 ) But this "lock" feature is something that I still miss.
dixonte commentedon Nov 23, 2024
I have submitted pull request #287 to change this behaviour.
WakanaYuki commentedon Jul 24, 2025
I have submitted a pull request that implements this feature/enhancement request here: #460
Add FairLock, a FIFO ticket lock for the transport mutex
Install the fair transport lock before opening a deck
Retire the write-rate cap defaults now that ordering is fair
Pin the install point in the fair lock scenario
Merge branch 'perf/fair-transport-lock' into 'main'
Core447 commentedon Aug 11, 2026
Added with a12d044