mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #1079] Feature request : configurable shortcuts for triggering scripts on host #859
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#859
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Potomac on GitHub (Feb 26, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1079
Hello,
a PC monitor can have several inputs : vga, hdmi, dvi, display port,
I decided to connect 2 PCs on my iiyama monitor (VGA and DVI ports),
I want to select the input (VGA, DVI) by sending DDC commands to the monitor, instead of using the OSD of my monitor, it is possible by using DDC protocol :
https://en.wikipedia.org/wiki/Display_Data_Channel
I can write a bash script with inside commands made by "ddcutil", that can automatically switch the monitor to the desired video input (VGA, DVI) :
https://passthroughpo.st/switching-monitor-inputs-software-ddc/
https://www.ddcutil.com/
The feature I want for barrier : have the ability to trigger a custom bash script with the keyboard, by configuring shortcuts, the bash script would run the appropriate ddcutil command for switching the monitor to the correct input (VGA, DVI etc...), according to the PC I want to control.
Thanks.
@eldorel commented on GitHub (Dec 14, 2021):
@Potomac I have no idea where I found this, but barrier has a command line flag for the server that can be used to trigger a script on screen change.
--screen-change-script /path/to/scriptThis runs the named script on switch with the name of the screen as the first argument.
I have a bash script with a case statement that changes the color of my RGB keyboard to reflect which system i'm currently controlling.
That said, I do actually have a different use case for an 'action' that can be triggered by keypresses to execute a script on the host (and hopefully allow this as a secondary action for that keypress).
I want to configure a single shortcut on all of my systems to toggle screen brightness (also using DDCutil actually) and have barrier send that keypress to everything.
Sending the key works, but the shortcut system in X11 runs at a lower level than barrier and hides the keypress, so I actually can't have barrier trigger a keypress on an action that's linked to an X11 shortcut.
Being able to setup something similar to this:
keystroke(F21) = keystroke(F21,*)+run(/path/to/script)or
keystroke(F21) = run(/$home/relative/path/to/script,*)would allow me to execute the brightness control script on the server or trigger a script on all clients in the same location.
@superuser7777 commented on GitHub (Jul 30, 2022):
Is this command line not used anymore?
--screen-change-script /path/to/scriptI checked. It's not there.
https://github.com/debauchee/barrier-wiki/blob/master/Command-Line.md#server_cli
I have an AHK script that I want to run only when I am operating on a barrier.
I was looking for a way to be a trigger.
Windows to Windows
Win10Pro & Barrier latest
@mitchcapper commented on GitHub (Oct 24, 2022):
Seems like it exists only on the xwindows clients:
fc045fc793/src/lib/barrier/ServerApp.cpp (L123)and in the man page:
fc045fc793/doc/barriers.1 (L50)is captured no matter the client:
fc045fc793/src/lib/barrier/ArgParser.cpp (L64)But only run if it is XWindows:
fc045fc793/src/lib/barrier/ServerApp.cpp (L690)Extending it to support other platforms would not be overly difficult ( and likely just require modifying that last function around handleScreenSwitched
@superuser7777 commented on GitHub (Oct 26, 2022):
@mitchcapper
Thanks for the details.
I look forward to future development.