send command to htmi switch #758
Conversation
|
I think it would make sense to have a way to specify arbitrary command that would be run on screen switch. Then users could support this use case without touching Barrier itself. |
|
An arbitrary command will work, but it will be slower than the proposed solution. The code in this PR keeps the COM port open to reduce the response time. |
Could we measure how much time does port opening take? A delay like 100ms would be almost unnoticeable and given how much computation can be done in that time it's hard to believe that opening of the COM port would take more. |
|
On my system, with a usb-to-rs232 adapter, it takes the port almost a second to open, that's why I re-wrote the code to keep the port open. |
|
I do think that this is a rather niche use case. I'm not convinced it needs to be in the main Barrier codebase - from what I understand, I can see it will only work on one HDMI switch. |
|
@VE3NEA couldn't you have another program always running that keeps the port running, and then from barrier you could send a command to your program to tell it to switch? |
|
I wrote that code when I was still waiting for the switch to arrive. Now I have it and, unfortunately, it takes the switch/monitor/videocard 2 to 5 seconds to start showing the other screen. 0.7 seconds spent on opening the port does not make much of a difference, so it makes no sense to keep the port open. @p12tic 's suggestion will work fine. |
|
An approach which would be more extensible would be to have Barrier support 'hooks'. That way if screen X is activated, Barrier could act on a hook associated with that event to switch the HDMI selection switch. Of course, that's more work... |
From the architecture point of view, it would be best to implement this "keep port open" functionality as a separate daemon-like program. Barrier would just call helper programs that would inform daemon that something needs to be sent to the interface. This way the responsibilities are properly separated - barrier does not include any HDMI-related things and the daemon does not include any Barrier-related things. |
|
👍 This definitely seems like the right direction (hooks on i.e. screen switch or keystroke) and external daemons to handle things like communication to specific HDMI/DP switches. It would be neat to see what this looks like at the limit. e.g. Having 6 DP monitors and a DP matrix switch, and being able to setup mappings for various work configurations (e.g. one PC use all 6 displays, split them up between 6 PCs, or some combination of the two for different scenarios). One important question then becomes how does this interact with the Barrier "Configure Server.." map -- which is currently "static" In this world where you might be changing the PC:Monitor mappings dynamically, it would be nice to be able to also swap "Server Configurations" as part of the same keystroke. There may be a subset of people who would be happy to swap all the displays between different computers (all on A. vs all on B.), and that use case wouldn't require "dynamic server configurations"; but, personally, my use cases often revolve around seeing some subset of my displays persistently, and I don't envision that changing even if I were to add an HDMI/DP switch to dynamically change which PC some displays point at. |
|
You don't even need display switching hardware for this to be useful. I'd like to have my monitor switch inputs based upon which host has focus. I can do this using ddc over the video connection itself. For example on a linux platform I could have barrier call ddcutil. |
|
Are hooks implemented in Barrier yet? If so, is there any documentation? |
P.O.C. only, please do not merge.
This is the code mentioned in Issue #347 that
sends a source selection command to the HDMI switch.