towel1 wrote:what do you think? is there a saner, more automatic way to handle this? perhaps using a GUI with buttons?
Sanity is subjective.
What you've done is fine, if it's fine for you. If you want automatic without involving dbus event message passing and linux sound server bloat with associated caveats, then the very simple way to do it is to write a udev rule for when your HDMI was added or removed, accordingly, to trigger your respective scripts. All that functionality should already be installed there on your end.
A "GUI with buttons" is not an
automatic way of doing anything, short of a control button assignment "launcher" to have you call one script to toggle the condition A/B. But yes, easily done. Kept my sanity vs trackpad interference except when I expressly wanted it active, vs any fancy attempts to assist on delayed enable when typing or palm rest triggering. Those QOL items never worked so great, so the manual valve to quickly enable/disable the firehose switch so to speak, is an example I had done. And now that I've suddenly got a sensitive trackpad twice as wide as before... (yes I use tmux,(n)vim, and Vimium browser plugin, what made you ask?
)
Anyway, this is very lightweight and desktop/window manager agnostic, especially if you use neither (e.g., headless). The beauty of ALSA is/was that it just generally works, in a direct manner, once you've got it lightly configured for your needs with very little overhead.
I suppose you could also utilize inotify on sysfs to check for changes as well as an alternative.
If you do just want the turnkey solution as others may assume, latency issues and other confusion a real possibility, then you can just allow the defaults to roll with almost any standard modern media supported desktop and they will likely pull in pulseaudio/pipewire unless you -use fight to exclude. If you go this route, try to stay within their interesting constraints, rather than doing your own thing, or you'll likely run into more headaches.
If you're planning to use Steam and same to stream the A/V feed, then you'll definitely want to fight with a sound server, as my limited attempts have not found a way around getting it to effectively use ALSA feeds to 'sink' towards that other target across the network. It obviously counts on utilizing those with their closed code. I haven't tried real hard either, but semi-noticable latency sound skips can sometimes be irritating when they occur. You'll also want to consider how much control you give these things vs their authors suggested demands, such as real time priority vs your other processes.
If you use Steam locally and nothing more, you won't need those sound servers either, no matter what the outside voices tell you. It will still work fine, as will most of your other audio ALSA backend programs.
