steam-runtime
steam-runtime copied to clipboard
ValveSoftware
Pleas make lm-sensors available in runtime environment
Feature Request
I confirm:
- [x] that I haven't found another request for this feature.
- [x] that I have checked whether there are updates for my system available that contain this feature already.
Description
Please include the lm-sensors binary so we are able to display additional sensor information in MangoHud.
References [optional]
https://github.com/flightlessmango/MangoHud/issues/848
Where does lm-sensors get its information from? Adding executables to the container doesn't add value unless they have everything they need to do their job. In the case of lm-sensors, does that mean /sys, or /dev, or somewhere else? Does it have/need configuration?
Running a command-line program with human-readable output, and screen-scraping its output with grep or similar, is an inefficient and fragile way to get information, particularly if it's being done every few frames in something like MangoHud: launching an executable (or multiple executables for a shell pipeline) involves a lot more syscalls and I/O than calling a function, and small changes to the formatting of human-readable text can easily break field extraction.
In general I'd prefer it if tools like MangoHud were using a programmatic interface like libsensors - although the ABI of libsensors changes periodically (it's currently at libsensors.so.5) so to be reliable, a known-compatible SONAME would have to be loaded with dlopen. libsensors.so.5 is available in the soldier and sniper runtimes already, in fact (it gets pulled in as a dependency of Mesa).
If using the command-line tool is unavoidable, it would be more reliable to use sensors -j and parse JSON, instead of screen-scraping human-readable text.
Alternatively, if the overlay that shows sensor results doesn't need to be in-process with the actual game, having it be a separate process that is composited over the top of the actual game (perhaps integrated with Gamescope) would ensure it doesn't interfere with running the game itself, would ensure that it can update even if the game is frozen, and would let it run on the host system instead of inside the game's container.
Thanks for taking your time to look into this! I have a guilty conscience for forcing you into such a long explanation. :-( Please consider, I'm far away from fully understanding what you wrote, but I get your point! I'm sure the dev of MangoHud knows exactly what to do, but I everybody is short on ressources nowadays, aren't we?
Unfortunately I can't answer most of your technical questions - sorry! I should have linked the repo with my last post lm-sensors.
This proposal was meant to be a band-aid as long as the feature is not available via MangoHud code. In my very basic understanding it is an "apt install lm-sensors" into the runtime environment...XD
In my very basic understanding it is an "apt install lm-sensors" into the runtime environment...
Probably yes, but if we do that and games start relying on it being there, then we have to keep it working forever, even if it breaks because the information it needs to read from /sys has changed - so that's a bigger thing to ask for than you might first think.
Understood. Is there a way how we (users) can add that on our own, so you are not in charge of supporting it?
Is there a way how we (users) can add that on our own, so you are not in charge of supporting it?
Not easily. If you have Flatpak installed (which the Deck does), you could use /usr/libexec/flatpak-xdg-utils/flatpak-spawn --host sensors, which runs sensors outside the container and tunnels its output into the container?