send command to hdmi switch #758
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
the
ghost
|
What is the current status of this feature? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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?