Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

send command to htmi switch #758

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

send command to htmi switch #758

wants to merge 1 commit into from

Conversation

VE3NEA
Copy link

@VE3NEA VE3NEA commented Jun 19, 2020

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.

@p12tic
Copy link
Member

p12tic commented Jun 19, 2020

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.

@VE3NEA
Copy link
Author

VE3NEA commented Jun 20, 2020

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.

@p12tic
Copy link
Member

p12tic commented Jun 20, 2020

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.

@VE3NEA
Copy link
Author

VE3NEA commented Jun 20, 2020

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.

@shymega
Copy link

shymega commented Jun 21, 2020

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.

@axelson
Copy link

axelson commented Jul 14, 2020

@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?

@VE3NEA
Copy link
Author

VE3NEA commented Jul 14, 2020

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.

@shymega
Copy link

shymega commented Jul 14, 2020

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...

@shymega shymega added the enhancement New feature or request label Jul 14, 2020
@p12tic
Copy link
Member

p12tic commented Jul 19, 2020

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.

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.

@missmah
Copy link

missmah commented Aug 18, 2020

👍 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.

@maxlock
Copy link

maxlock commented Aug 27, 2020

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.

@foxt
Copy link

foxt commented Apr 28, 2021

Are hooks implemented in Barrier yet? If so, is there any documentation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants