Open-source KVM software

Overview

Barrier

Eliminate the barrier between your machines. Find releases for windows and macOS here. Your distro probably already has barrier packaged for it, see distro specific packages below for a list. Alternatively, we also provide a flatpak and a snap.

Contact info:

  • #barrier on LiberaChat IRC network

CI Build Status

Master branch overall build status: Build Status

Platform Build Status
Linux Build Status
Mac Build Status
Windows Debug Build Status
Windows Release Build Status
Snap Snap Status

Our CI Builds are provided by Microsoft Azure Pipelines, Flathub, and Canonical.

What is it?

Barrier is software that mimics the functionality of a KVM switch, which historically would allow you to use a single keyboard and mouse to control multiple computers by physically turning a dial on the box to switch the machine you're controlling at any given moment. Barrier does this in software, allowing you to tell it which machine to control by moving your mouse to the edge of the screen, or by using a keypress to switch focus to a different system.

Barrier was forked from Symless's Synergy 1.9 codebase. Synergy was a commercialized reimplementation of the original CosmoSynergy written by Chris Schoeneman.

At the moment, barrier is not compatible with synergy. Barrier needs to be installed on all machines that will share keyboard and mouse.

What's different?

Whereas Synergy has moved beyond its goals from the 1.x era, Barrier aims to maintain that simplicity. Barrier will let you use your keyboard and mouse from one computer to control one or more other computers. Clipboard sharing is supported. That's it.

Project goals

Hassle-free reliability. We are users, too. Barrier was created so that we could solve the issues we had with synergy and then share these fixes with other users.

Compatibility. We use more than one operating system and you probably do, too. Windows, OSX, Linux, FreeBSD... Barrier should "just work". We will also have our eye on Wayland when the time comes.

Communication. Everything we do is in the open. Our issue tracker will let you see if others are having the same problem you're having and will allow you to add additional information. You will also be able to see when progress is made and how the issue gets resolved.

Usage

Install and run barrier on each machine that will be sharing. On the machine with the keyboard and mouse, make it the server.

Click the "Configure server" button and drag a new screen onto the grid for each client machine. Ensure the "screen name" matches exactly (case-sensitive) for each configured screen -- the clients' barrier windows will tell you their screen names (just above the server IP).

On the client(s), put in the server machine's IP address (or use Bonjour/auto configuration when prompted) and "start" them. You should see Barrier is running on both server and clients. You should now be able to move the mouse between all the screens as if they were the same machine.

Note that if the keyboard's Scroll Lock is active then this will prevent the mouse from switching screens.

Contact & support

Please be aware that the only way to draw our attention to a bug is to create a new issue in the issue tracker. Write a clear, concise, detailed report and you will get a clear, concise, detailed response. Priority is always given to issues that affect a wider range of users.

For short and simple questions or to just say hello find us on the LiberaChat IRC network in the #barrier channel.

Contributions

At this time we are looking for developers to help fix the issues found in the issue tracker. Submit pull requests once you've polished up your patch and we'll review and possibly merge it.

Most pull requests will need to include a release note. See docs/newsfragments/README.md for documentation of how to do that.

Distro specific packages

While not a comprehensive list, repology provides a decent list of distro specific packages.

Packaging status

FAQ - Frequently Asked Questions

Q: Does drag and drop work on linux?

A: No (see #855 if you'd like to change that)

Q: What OSes are supported?

A: The most recent release of Barrier is known to work on:

  • Windows 7, 8, 8.1, 10, and 11
  • macOS (previously known as OS X or Mac OS X)
    • The current GUI does not work on OS versions prior to macOS 10.12 Sierra (but see the related answer below)
  • Linux
  • FreeBSD
  • OpenBSD

Q: Are 32-bit versions of Windows supported?

A: No

Q: Is it possible to use Barrier on Mac OS X / OS X versions prior to 10.12?

A: Not officially.

  • For OS X 10.10 Yosemite and later:
  • For Mac OS X 10.9 Mavericks (and perhaps earlier):
    1. the command-line portions of the current release should run fine.
    2. The GUI will not run, as that OS version does not include Apple's Metal framework.

Note: Only versions v2.3.4 and later of Barrier can be supported by this project.

  • Anyone using an earlier version is advised to upgrade due to recently-addressed security vulnerabilities (and other bug fixes).
    • This is especially important for computers accessible from the public Internet (or from other shared/untrusted networks, such as when using shared WiFi).

Q: How do I load my configuration on startup?

A: Start the binary with the argument --config <path_to_saved_configuration>

Q: After loading my configuration on the client the field 'Server IP' is still empty!

A: Edit your configuration to include the server's ip address manually with

(...)

section: options
   serverhostname=<AAA.BBB.CCC.DDD>

Q: Are there any other significant limitations with the current version of Barrier?

A: Currently:

  • Barrier currently has limited UTF-8 support; issues have been reported with processing various languages.
  • There is interest in future support for the Wayland compositor/display server protocol (official site | Wikipedia article) on Linux.
    • As of late 2021, there is no expected completion date for Wayland support.
    • (see #109 and #1251 for status or to volunteer your talents)

The complete list of open issues can be found in the 'Issues' tab on GitHub. Help is always appreciated.

Comments
  • Continue renaming from Barrier to InputLeap

    Continue renaming from Barrier to InputLeap

    This commit adds to @p12tic's commit (hash: cdda053d) of changing Debauchee and Barrier references to the new InputLeap project.

    I've adjusted the developer group name of "Debauchee Open Source Group" to "The InputLeap Developers", and renamed the URLs to the new InputLeap organisation and repository.

    With regards to the newsfragment: I'm not sure if it's worth creating one until we have fully renamed all Barrier + Debauchee references, as this commit does not fix all references yet. There's still some in translations and codebase (But the latter isn't always user-facing). I'd personally like to make a final newsfragment once everything has been changed.

    Additionally: we need to be sure of the new name. It's not clear if it's "InputLeap" OR "Input-Leap". I'll be making a edit to the README and Wiki soon.

    Signed-off-by: Dom Rodriguez [email protected]

    Contributor Checklist:

    • [ ] I have created a file in the doc/newsfragments directory IF it is a user-visible change (and make sure to read the README.md in that directory)
    documentation 
    opened by shymega 8
  • gui: Update Hungarian translation

    gui: Update Hungarian translation

    This is a port of https://github.com/debauchee/barrier/pull/1458 to input-leap.

    Thanks @ViBE-HU.

    Contributor Checklist:

    • [x] I have created a file in the doc/newsfragments directory IF it is a user-visible change (and make sure to read the README.md in that directory)
    opened by p12tic 7
  • Rename Barrier to Input Leap in translations

    Rename Barrier to Input Leap in translations

    This is a bit hacky, but I ran sed on the translations, to change 'Barrier' to 'Input Leap', etc.

    It seems to compile fine, but I haven't yet tested translations, as I'm only fluent in English, unfortunately.

    There are still references to barriers and barrierc, but we haven't renamed those yet, so this will need more work.

    Signed-off-by: Dom Rodriguez [email protected]

    Contributor Checklist:

    • [x] I have created a file in the doc/newsfragments directory IF it is a user-visible change (and make sure to read the README.md in that directory)
    opened by shymega 5
  • Only allows active client grabbing clipboard

    Only allows active client grabbing clipboard

    Addresses #1433

    This PR disallows non-active client grabbing the clipboard ownership, which could erase the clipboard content of the current active client (i.e. the focused screen). This occurs when a background process in an non-active client updates system clipboard content (hence, triggering the grab event).

    Contributor Checklist:

    • [x] I have created a file in the doc/newsfragments directory IF it is a user-visible change (and make sure to read the README.md in that directory)
    opened by soraxas 5
  • Refactoring of CI configurations and build scripts

    Refactoring of CI configurations and build scripts

    This PR has been migrated from old Barrier Github repository https://github.com/debauchee/barrier/pull/1385

    PR created on: 2021-11-04 by @shymega PR last updated on: 2021-11-07

    Now, CI builds for macOS involve three separate builds for a range of macOS versions, and a final Universal macOS Binary made on Big Sur. It should work with the M1 chip and x86_64 Intel Macs.

    I have also renamed osx_environment->macOS_environment.sh to reflect the new name change of Apple's desktop OS.

    In terms of the clean_builds.sh script, this has also been refactored to be more resilient, and efficient (marginally).

    Signed-off-by: Dom Rodriguez [email protected]

    Contributor Checklist:

    • [x] I have created a file in the doc/newsfragments directory (and read the README.md in that directory)

    Commented on: 2021-11-04 by @shymega

    This has been worked on in a branch of the main Barrier repo. It took a lot of trial and error, with many commits, but I squashed them into one for this PR - the Azure Pipelines build log shows a lot of attempts, but this can be ignored. The latest commit - i.e, this PR - should be looked at primarily.

    In terms of the long-term viability, I'm waiting for the Universal Mac BInary to be tested, but I'm fairly confident - hesitant to say I'm completely confident - that it will execute correctly. In the meantime, I will mark this PR as a WIP until confirmation is attained that the build works on M1 and x86_64 Macs.


    Commented on: 2021-11-04 by @shymega

    The report in #1380 seems to indicate my PR was unsuccessful. I will take another look tomorrow.


    Commented on: 2021-11-04 by @shymega

    Oh... it's not an environment variable I need to set. It's in CMakeLists.txt. Duh. OK, I've made the change, and now it's building. If someone could give it a try once it's finished, I'll look at it tomorrow when I get a chance.


    Commented on: 2021-11-05 by @p12tic

    End users are likely to build with Release, so we should use that too. There are compile-time bugs that can only be seen either in Release or Debug mode.


    Commented on: 2021-11-05 by @p12tic

    I think it would be better to merge this to bug-sur-Release and add a condition on the artifact publishing task so that it only happens on big-sur job.


    Commented on: 2021-11-05 by @p12tic

    Obvious comment, no need for it.

    I think it maybe makes sense to put all of this in a loop to check cmake3 and cmake in that sequence and exit the loop if the command is found.


    Commented on: 2021-11-05 by @p12tic

    Let's set default B_CMAKE_FLAGS above just like with B_BUILD_TYPE so that we don't duplicate stuff.


    Commented on: 2021-11-05 by @p12tic

    Executing this will fail if there's no file, so there's no need for the check of existence. I doubt that in normal times we'll ever see the above error ever happen.


    Commented on: 2021-11-05 by @p12tic

    No need for this check unless I miss something. rm -rf path does not fail if the path does not exist.


    Commented on: 2021-11-05 by @p12tic

    Having default B_CMAKE_FLAGS would reduce noise here


    Commented on: 2021-11-05 by @p12tic

    I think the previous cd is better solution because it leads to simplier code.


    Commented on: 2021-11-05 by @p12tic

    No one will see this, I'd say this comment is not necessary. If someone wants to use ninja, they won't use clean_build.sh.


    Commented on: 2021-11-05 by @p12tic

    Why conditionals? || exit 1 is a common pattern in shell scripting


    Commented on: 2021-11-05 by @p12tic

    Redundant


    Commented on: 2021-11-05 by @p12tic

    I don't see osx_environment.sh removed.


    Commented on: 2021-11-05 by @p12tic

    I'd say let's use snake_case for the file name here, as in macos_environment.sh to keep consistency with the rest of build scripts.


    Commented on: 2021-11-05 by @p12tic

    I doubt downstreams will actually use this script, it's just asking for trouble and additional risk in case we break something here.


    Commented on: 2021-11-05 by @p12tic

    For example, we do network access in the script, which is usually big no no and build machines have network completely disabled. If they did allow network access then reproducible builds would be much harder and there would be risk in malware infection because the code that runs on build machine is external.


    Commented on: 2021-11-05 by @shymega

    ~~Sorry, could you explain further? I've made some changes locally that now build on all three Mac build agents both Debug and Release mode.~~

    Never mind. Makes sense now. I agree, looking at it now. Saves us time rather than having another job.


    Commented on: 2021-11-05 by @shymega

    There is one issue with Universal DMGs: basically, Qt 5 doesn't support ARM64 - only Qt 6, it would appear. So we would have to look into bumping to Qt 6, either on Mac only or globally. It's not ideal. So for now, I think we should pause the Universal DMG directive in CMakeLists.txt, and explore bumping to Qt 6 in a separate issue. Thoughts?


    Commented on: 2021-11-05 by @shymega

    It depends on what your definition of 'Redudunant' is. I would say that it would make searching logs for the build being completed simpler, but I can see your point. I'll remove it for now, as we can revisit in the future if someone wants this output.


    Commented on: 2021-11-05 by @shymega

    Removed in b229324d.


    Commented on: 2021-11-05 by @shymega

    There's really not much difference with regards to simplictly. In fact, not cding to the build directory, but instead doing it this way means its simpler, with no directory changes. I'd rather keep it.


    Commented on: 2021-11-05 by @shymega

    Fixed in 0091b281.


    Commented on: 2021-11-05 by @shymega

    Also removed in b229324d, good point about reproducible builds.


    Commented on: 2021-11-05 by @shymega

    I've done that now, but I think you meant about -DCMAKE_BUILD_TYPE=${B_BUILD_TYPE} rather than the macOS flags.


    Commented on: 2021-11-05 by @shymega

    Fixed in 3d084b63.


    Commented on: 2021-11-05 by @shymega

    That has now been fixed - we have a matrix of three Mac build agents, doing two types of builds each - Debug & Release. Big Sur has a conditional during the job to generate artefacts.


    Commented on: 2021-11-05 by @shymega

    That's been removed - the comment - but I think we should really think pragmatically about changing this into a loop. What benefits does it bring? If we're just checking for either executable, a conditional works fine IMO. Thoughts?


    Commented on: 2021-11-05 by @shymega

    As per my comment in this PR, I think this variable should be disabled for the moment until we can address the Qt issue. Currently Mojave fails to build with this set.cc: @p12tic.


    Commented on: 2021-11-05 by @shymega

    This has been disabled in 0642496b, builds on all agents now pass.


    Commented on: 2021-11-05 by @shymega

    Fixed in a1bc7a32.


    Commented on: 2021-11-05 by @shymega

    Fixed in 250072e9.


    Commented on: 2021-11-05 by @shymega

    Removed in b229324d.


    Commented on: 2021-11-05 by @shymega

    Fixed in 250072e9 - the comment.


    Commented on: 2021-11-05 by @shymega

    Disabled arm64 building in 0642496b.


    Commented on: 2021-11-05 by @shymega

    Simplified and fixed in 5e7fa733 - thoughts?


    Commented on: 2021-11-05 by @p12tic

    I think it's best not to even add the comment. It could perhaps live in a WIP PR or something, right now it's just noise looking from code perspective.


    Commented on: 2021-11-05 by @p12tic

    OK let's keep it, I was just a little annoyed that we change working code for little reason. It's easy way to introduce regressions and spend time for no benefit.


    Commented on: 2021-11-05 by @p12tic

    We still don't need the comment, people who want to look into how it was before can check git blame or git log


    Commented on: 2021-11-05 by @p12tic

    Do you envision a situation when there's no macos_environment.sh file? Since it's committed to git, I would include it unconditionally.


    Commented on: 2021-11-05 by @p12tic

    Since we actually disable the arm64, it's not actually universal.


    Commented on: 2021-11-05 by @shymega

    Sorry that you were annoyed, that wasn't my intention. I'm going to revert it because it has occurred to me that some build environments might not support this new behaviour, and the make -C might be a GNU-ism.


    Commented on: 2021-11-05 by @shymega

    This has now been reverted in 299bac40.


    Commented on: 2021-11-05 by @shymega

    This has now been removed in ea66407c.


    Commented on: 2021-11-05 by @shymega

    Not particularly, I'll add it unconditionally.


    Commented on: 2021-11-05 by @shymega

    This was leftover from a previous commit where arm64 was enabled. Removed in a9bcc38d.


    Commented on: 2021-11-05 by @shymega

    Removed in 317262c2.


    Commented on: 2021-11-05 by @p12tic

    Some rust code?


    Commented on: 2021-11-05 by @shymega

    Uh... that's not meant to be there 😆


    Commented on: 2021-11-05 by @shymega

    Fixed in a2296931. This is a mess of mine.


    Commented on: 2021-11-05 by @shymega

    Once the review is approved @p12tic, I think I should squash the PR into one commit. Same with #1396. Thoughts?


    Commented on: 2021-11-05 by @p12tic

    Still here somehow


    Commented on: 2021-11-05 by @p12tic

    Ah, I was talking about the exit, not about the other lines in the comment.


    Commented on: 2021-11-05 by @p12tic

    This comment is also obvious.


    Commented on: 2021-11-05 by @p12tic

    This comment is also obvious


    Commented on: 2021-11-05 by @shymega

    Fixed in 037146ab.


    Commented on: 2021-11-05 by @shymega

    Fixed in 037146ab.


    Commented on: 2021-11-05 by @shymega

    You're quite right. Removed in 24f45e63.


    Commented on: 2021-11-06 by @p12tic

    If we're adding release build to this same matrix, let's keep the old names.


    Commented on: 2021-11-06 by @p12tic

    Let's save CPU time and only do release builds.


    Commented on: 2021-11-06 by @p12tic

    I don't think we should say this here. People should look into release notes. Artifact names may be used by scripts, so we should actually make them machine-readable long term.


    Commented on: 2021-11-06 by @p12tic

    I think that we don't need to include the condition here. The task will either not show or be skipped in azure UI and whoever looks into the file will see the condition check.


    Commented on: 2021-11-06 by @p12tic

    The above 3 lines were fine in the original version, let's revert.


    Commented on: 2021-11-06 by @p12tic

    We can keep this informational message too. It makes it very clear whether one needs to look into log for error or not.


    Commented on: 2021-11-06 by @shymega

    The condition has been shortened to only release from Big Sur. This is future proof for when we ship for M1 (although this won't be for some time yet), and means that we don't publish every artifact from each build agent, which is what would happen if we didn't have the conditional. This will be pushed in due course, once I've addressed the rest of your feedback.


    Commented on: 2021-11-06 by @shymega

    They are in the clean_build.sh I have here. Looks like it's committed. The only thing that needs adding is "Build completed successfully", which I will add again here.


    Commented on: 2021-11-06 by @shymega

    As in the previous comment, this will be added again.


    Commented on: 2021-11-06 by @shymega

    Fixed in ed981a41.


    Commented on: 2021-11-06 by @shymega

    Resolved in 68283b90.


    Commented on: 2021-11-06 by @shymega

    Resolving, as this review comment has been addressed.


    Commented on: 2021-11-06 by @shymega

    Resolved in ecc8475e.


    Commented on: 2021-11-06 by @shymega

    Addressed in a677ab21.


    Commented on: 2021-11-06 by @shymega

    Addressed in d866cf52.


    Commented on: 2021-11-06 by @shymega

    Addressed in d866cf52.


    Commented on: 2021-11-06 by @shymega

    Just a reminder - I'm all ready to merge if you are, I've rebased to master as well.


    Commented on: 2021-11-06 by @shymega

    Just a reminder - I'm all ready to merge if you are, I've rebased to master as well.


    Commented on: 2021-11-07 by @p12tic

    git is showing a change - 3 red lines and 3 green, so it isn't completely reverted. Better squash all these twenty commits on your side locally and you'll see the change clearly.

    macOS build-infra awaiting-approval 
    opened by povilas-barrier-bot 5
  • "Barrier is starting." But not working.

    What happened?

    Barrier is stuck at "Barrier is starting." What might i need?

    Both boxen have a wire to my modem, are fully updated, and can ssh to each other. Both have this /etc/barrier.conf:

    section: screens
            e540:
            eb840g3:
    end
    section: links
            e540:
                    up    = eb840g3
            eb840g3:
                    down  = e540
    end
    

    i invoked barrier(2.4.0-1)(installed by pacman) on e540(manjaro kde), in the terminal it said:

    *** WARNING *** The program 'barrier' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi. *** WARNING *** Please fix your application to use the native API of Avahi! *** WARNING *** For more information see http://0pointer.de/blog/projects/avahi-compat.html

    i found https://github.com/input-leap/input-leap/issues/780 via google but it's not clear to me if the comments solved the issue. Perhaps if i give the server address to the client it doesn't really need avahi?

    Not knowing what to make of that i went ahead in the barrier GUI, designated it as 'Server', selected 'Use existing configuration:' at /etc/barrier.conf and clicked 'Start'. in the terminal it said:

    ("-f", "--no-tray", "--debug", "INFO", "--name", "e540", "--disable-client-cert-checking", "-c", "/etc/barrier.conf", "--address", ":24800")

    and in the GUI it says "Barrier is running." Then i invoked barrier(2.4.0-1.7)(installed by zypper) on 3b840g3(tumbleweed kde), designated it as 'Client', 'Auto config', clicked 'Start', in the terminal it said:

    ("-f", "--no-tray", "--debug", "INFO", "--name", "eb840g3", "[]:24800")

    and in the GUI it says "Barrier is starting." Tried uncheck 'Auto config', entered Server IP, clicked 'Reload', 'Stop', and 'Start', in the terminal it said:

    ("-f", "--no-tray", "--debug", "INFO", "--name", "eb840g3", "[10.3.8.21]:24800")

    and in the GUI it still says "Barrier is starting."

    Both GUIs say "SSL Fingerprint: Disabled". The manjaro default install has no firewall iiuc. Tumbleweed does, but as client does it need anything open? i tried "firewall-cmd --add-port=24800/tcp" on tumbleweed, and clicked 'Stop' and 'Start' on the Server and then the Client, but no change.

    What else might i check, or read, or do? Many thanks,

    Version

    v2.4.0

    Git commit hash (if applicable)

    No response

    If applicable, where did you install Barrier from?

    pacman and zypper, from the default repositories

    What OSes are you seeing the problem on? (Check all that apply)

    Linux

    What OS versions are you using?

    server on manjaro kde, client on tumbleweed kde, both are rolling release and up to date

    Relevant log output

    manjaro/server:
    Sep 20 23:51:31 e540 barrier[15783]: *** WARNING *** The program 'barrier' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
    Sep 20 23:51:31 e540 barrier[15783]: *** WARNING *** Please fix your application to use the native API of Avahi!
    Sep 20 23:51:31 e540 barrier[15783]: *** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
    Sep 20 23:51:31 e540 dbus-daemon[399]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service' requested by ':1.322' (uid=1000 pid=15783 comm="barrier")
    Sep 20 23:51:31 e540 dbus-daemon[399]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service not found.
    Sep 20 23:51:31 e540 kded5[720]: Registering ":1.71/StatusNotifierItem" to system tray
    
    tumbleweed/client:
    Sep 20 23:53:04 eb840g3 kded5[1999]: Registering ":1.75/StatusNotifierItem" to system tray
    

    Any other information

    No response

    bug invalid wontfix linux 
    opened by gregrwm 4
  • Issue #1441 Make changes for Github Actions CI and Innosetup 6.2.0

    Issue #1441 Make changes for Github Actions CI and Innosetup 6.2.0

    This PR is what it takes to move the existing Azure Pipelines CI to Github Actions and use Innosetup 6.2. Not presenting this as a fully done solution, it still needs work and input.

    Other changes:

    • Bump Qt for Windows builds to 5.15.2 to match MacOS and Linux
    • Use VS2022 and the latest VC++ redist for Windows
    • Combination of the above two changes and Innosetup 6.2 security is that minimum Windows version is now Win7 SP1
    • Tell the MacOS build to target 10.15 instead of 10.9
    • Replace the custom dependency fetcher for Innosetup with the community-standard script

    Still needs work:

    • Build output uploads need some tweaking to work in a form we would actually expect
    • The ISS script needs a lot more updates to finish the branding move to Input Leap
    • The Github Action needs to run on other Linux distros via containers (Arch and Fedora at least?)
    • Need to figure out support matrix for Windows and MacOS and what that looks like for building vs running
    opened by a5ehren 4
  • Forward/backward mouse side buttons with waynergy

    Forward/backward mouse side buttons with waynergy

    What happened?

    I'm toying with connecting a Ubuntu 20.04 barrier server, now switched to a input-leap master checkout in hope of better mouse button support from https://github.com/input-leap/input-leap/pull/391/, with a Ubuntu 22.04 waynergy client (since Wayland seems inevitable...).

    Works reasonably so far, but the forward/backward side buttons on my Logitech M500 don't register on the client, while they do on the server. They also work when the mouse is connected to the client machine directly. xev output on the 20.04 host tells me:

    button 1: LMB
    button 2: wheel click
    button 3: RMB
    button 4: scroll up
    button 5: scroll down
    button 6: left tilt wheel
    button 7: right tilt wheel
    button 8: backward side button
    button 9: forward side button
    

    xev on the 22.04 client shows the same when directly wired, but only up to and including button 7 via input-leap. Then buttons 8 and 9 do nothing. Notably wheel tilting (buttons 6, 7) for horizontal scrolling does work on the client via input-leap.

    Version

    v2.4.0

    Git commit hash (if applicable)

    708cbfde

    If applicable, where did you install Barrier from?

    No response

    What OSes are you seeing the problem on? (Check all that apply)

    Linux

    What OS versions are you using?

    Ubuntu 20.04, Ubuntu 22.04

    Relevant log output

    No response

    Any other information

    I could work around this by remapping the buttons to lower indices on both machines, e.g. moving the horizontal scrolling to the unsupported range. The side buttons offer higher usability and quality of life for me, but maybe this can be done without sacrifice and a fix in input-leap would be more appropriate? From https://github.com/input-leap/input-leap/blob/master/src/lib/inputleap/mouse_types.h It appears that we could extend this to mice with a moderately higher number of buttons (hey, at least it's not one of these 15-button Razers ;) ).

    Considered issues https://github.com/input-leap/input-leap/issues/51, https://github.com/input-leap/input-leap/pull/242, https://github.com/input-leap/input-leap/issues/594 and https://github.com/input-leap/input-leap/issues/1042, which seem either resolved or distinct.

    opened by donjan 3
  • barrierc cannot be properly shut down

    barrierc cannot be properly shut down

    What happened?

    When I shut down barrierc using "Stop" from barrier GUI, barrierc is not actually shut down, and after 5 seconds, barrier kills barrierc with SIGKILL.

    Version

    From Git HEAD or commit (specify below)

    Git commit hash (if applicable)

    420de96f3d280089ee929804bf8cecc35de0c28b

    If applicable, where did you install Barrier from?

    From the AUR package maintained by me https://aur.archlinux.org/packages/input-leap-git

    What OSes are you seeing the problem on? (Check all that apply)

    Linux, Windows

    What OS versions are you using?

    Server: Arch Linux latest Client: Windows 10 21H2

    Relevant log output

    $ sudo gdb
    GNU gdb (GDB) 11.2
    Copyright (C) 2022 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Type "show copying" and "show warranty" for details.
    This GDB was configured as "x86_64-pc-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <https://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
        <http://www.gnu.org/software/gdb/documentation/>.
    
    For help, type "help".
    Type "apropos word" to search for commands related to "word".
    (gdb) attach 367525
    Attaching to process 367525
    [New LWP 367526]
    [New LWP 367527]
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/libthread_db.so.1".
    0x00007f7e44aaca55 in [email protected]_2.2.5 () from /usr/lib/libc.so.6
    (gdb) bt
    #0  0x00007f7e44aaca55 in [email protected]_2.2.5 () from /usr/lib/libc.so.6
    #1  0x00007f7e44ab1717 in nanosleep () from /usr/lib/libc.so.6
    #2  0x000055eb2c42b65e in ArchSleepUnix::sleep (this=<optimized out>, timeout=0.050000000000000003) at /usr/src/debug/input-leap/src/lib/arch/unix/ArchSleepUnix.cpp:74
    #3  0x000055eb2c42a01b in ArchMultithreadPosix::wait (this=0x7ffe7cc36b48, target=0x55eb2e17ad90, timeout=-1)
        at /usr/src/debug/input-leap/src/lib/arch/unix/ArchMultithreadPosix.cpp:329
    #4  0x000055eb2c47af97 in Thread::wait (timeout=-1, this=<optimized out>) at /usr/src/debug/input-leap/src/lib/mt/Thread.cpp:107
    #5  SocketMultiplexer::~SocketMultiplexer (this=<optimized out>, this=<optimized out>) at /usr/src/debug/input-leap/src/lib/net/SocketMultiplexer.cpp:64
    #6  0x000055eb2c4363ce in std::default_delete<SocketMultiplexer>::operator() (this=<optimized out>, __ptr=0x55eb2e17cc60) at /usr/include/c++/11.2.0/bits/unique_ptr.h:79
    #7  std::default_delete<SocketMultiplexer>::operator() (__ptr=0x55eb2e17cc60, this=<optimized out>) at /usr/include/c++/11.2.0/bits/unique_ptr.h:79
    #8  std::unique_ptr<SocketMultiplexer, std::default_delete<SocketMultiplexer> >::~unique_ptr (this=<optimized out>, this=<optimized out>)
        at /usr/include/c++/11.2.0/bits/unique_ptr.h:361
    #9  App::~App (this=<optimized out>, this=<optimized out>) at /usr/src/debug/input-leap/src/lib/inputleap/App.cpp:76
    #10 0x000055eb2c426a42 in main (argc=12, argv=<optimized out>) at /usr/src/debug/input-leap/src/cmd/barriers/barriers.cpp:63
    (gdb) info threads
      Id   Target Id                                     Frame
    * 1    Thread 0x7f7e44899100 (LWP 367525) "barriers" 0x00007f7e44aaca55 in clock_na[email protected]_2.2.5 () from /usr/lib/libc.so.6
      2    Thread 0x7f7e44895640 (LWP 367526) "barriers" 0x00007f7e44a1724a in sigtimedwait () from /usr/lib/libc.so.6
      3    Thread 0x7f7e44094640 (LWP 367527) "barriers" 0x00007f7e44a5e15a in __futex_abstimed_wait_common () from /usr/lib/libc.so.6
    (gdb) thread 2
    [Switching to thread 2 (Thread 0x7f7e44895640 (LWP 367526))]
    #0  0x00007f7e44a1724a in sigtimedwait () from /usr/lib/libc.so.6
    (gdb) bt
    #0  0x00007f7e44a1724a in sigtimedwait () from /usr/lib/libc.so.6
    #1  0x00007f7e44a168ec in sigwait () from /usr/lib/libc.so.6
    #2  0x000055eb2c42a1b4 in ArchMultithreadPosix::threadSignalHandler () at /usr/src/debug/input-leap/src/lib/arch/unix/ArchMultithreadPosix.cpp:588
    #3  0x00007f7e44a615c2 in start_thread () from /usr/lib/libc.so.6
    #4  0x00007f7e44ae6584 in clone () from /usr/lib/libc.so.6
    (gdb) thread 3
    [Switching to thread 3 (Thread 0x7f7e44094640 (LWP 367527))]
    #0  0x00007f7e44a5e15a in __futex_abstimed_wait_common () from /usr/lib/libc.so.6
    (gdb) bt
    #0  0x00007f7e44a5e15a in __futex_abstimed_wait_common () from /usr/lib/libc.so.6
    #1  0x00007f7e44a60960 in [email protected]@GLIBC_2.3.2 () from /usr/lib/libc.so.6
    #2  0x00007f7e44cc7c51 in __gthread_cond_wait (__mutex=<optimized out>, __cond=0x55eb2e17cc98)
        at /usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:865
    #3  std::__condvar::wait (__m=..., this=0x55eb2e17cc98) at /usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/std_mutex.h:155
    #4  std::condition_variable::wait ([email protected]=0x55eb2e17cc98, __lock=...) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/condition_variable.cc:41
    #5  0x000055eb2c47a8c4 in std::condition_variable::wait<SocketMultiplexer::service_thread()::<lambda()> > (__p=..., __lock=..., this=0x55eb2e17cc98)
        at /usr/include/c++/11.2.0/condition_variable:103
    #6  SocketMultiplexer::service_thread (this=0x55eb2e17cc60) at /usr/src/debug/input-leap/src/lib/net/SocketMultiplexer.cpp:144
    #7  operator() (__closure=<optimized out>) at /usr/src/debug/input-leap/src/lib/net/SocketMultiplexer.cpp:57
    #8  std::__invoke_impl<void, SocketMultiplexer::SocketMultiplexer()::<lambda()>&> (__f=...) at /usr/include/c++/11.2.0/bits/invoke.h:61
    #9  std::__invoke_r<void, SocketMultiplexer::SocketMultiplexer()::<lambda()>&> (__fn=...) at /usr/include/c++/11.2.0/bits/invoke.h:154
    #10 std::_Function_handler<void(), SocketMultiplexer::SocketMultiplexer()::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...)
        at /usr/include/c++/11.2.0/bits/std_function.h:291
    #11 0x000055eb2c47e722 in std::function<void ()>::operator()() const (this=0x55eb2e17b2c0) at /usr/include/c++/11.2.0/bits/std_function.h:560
    #12 Thread::threadFunc(std::function<void ()> const&) (func=...) at /usr/src/debug/input-leap/src/lib/mt/Thread.cpp:141
    #13 operator() (__closure=0x55eb2e17b2c0) at /usr/src/debug/input-leap/src/lib/mt/Thread.cpp:33
    #14 std::__invoke_impl<void, Thread::Thread(const std::function<void()>&)::<lambda()>&> (__f=...) at /usr/include/c++/11.2.0/bits/invoke.h:61
    #15 std::__invoke_r<void, Thread::Thread(const std::function<void()>&)::<lambda()>&> (__fn=...) at /usr/include/c++/11.2.0/bits/invoke.h:154
    #16 std::_Function_handler<void(), Thread::Thread(const std::function<void()>&)::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...)
        at /usr/include/c++/11.2.0/bits/std_function.h:291
    #17 0x000055eb2c42a4e8 in std::function<void ()>::operator()() const (this=0x55eb2e17ada0) at /usr/include/c++/11.2.0/bits/std_function.h:560
    #18 ArchMultithreadPosix::doThreadFunc (thread=0x55eb2e17ad90, this=0x7ffe7cc36b48) at /usr/src/debug/input-leap/src/lib/arch/unix/ArchMultithreadPosix.cpp:531
    #19 ArchMultithreadPosix::threadFunc (vrep=0x55eb2e17ad90) at /usr/src/debug/input-leap/src/lib/arch/unix/ArchMultithreadPosix.cpp:513
    #20 0x00007f7e44a615c2 in start_thread () from /usr/lib/libc.so.6
    #21 0x00007f7e44ae6584 in clone () from /usr/lib/libc.so.6
    (gdb) c
    Continuing.
    [Thread 0x7f7e44094640 (LWP 367527) exited]
    [Thread 0x7f7e44895640 (LWP 367526) exited]
    
    Program terminated with signal SIGKILL, Killed.
    The program no longer exists.
    (gdb)
    The program is not being run.
    quit)
    

    Any other information

    Logs above are for barrierc after I hit "Stop" and before SIGKILL happens. Looks like a thread is waiting for new events and never terminates.

    By the way, a similar issues happens when I tried to shut down barrierd on Windows with net stop barrierd. I built Windows binaries using MinGW with many patches, so that might not be an upstream issue.

    opened by yan12125 3
  • Miscellaneous warnings

    Miscellaneous warnings

    This PR fixes miscellaneous warnings and deletes dead code.

    • [not needed] I have created a file in the doc/newsfragments directory IF it is a user-visible change (and make sure to read the README.md in that directory)
    opened by mokibit 3
  • Rename Barrier -> Input Leap in build sh script

    Rename Barrier -> Input Leap in build sh script

    Signed-off-by: Dom Rodriguez [email protected]

    Contributor Checklist:

    • [ ] I have created a file in the doc/newsfragments directory IF it is a user-visible change (and make sure to read the README.md in that directory)
    opened by shymega 3
  • Make dist workflow only build on Input Leap tag

    Make dist workflow only build on Input Leap tag

    This modification reduces confusion for users with GH Actions, and I will be looking to make generic amd64/arm64 artifacts for debug builds on Linux/Mac, but for now, this fix makes it so the dist.yml workflow only builds Fedora RPMs on a tag release. That way, we have only one CI workflow actually running when it comes to new commits, and publishing generic amd64/arm64 Mac, Linux, and amd64 Windows executable artifacts.

    Thoughts?

    Contributor Checklist:

    • [ ] I have created a file in the doc/newsfragments directory IF it is a user-visible change (and make sure to read the README.md in that directory)
    opened by shymega 3
  • feat: Scoop package

    feat: Scoop package

    What happened?

    Barrier used to have a Scoop package. I think that it would be a good idea to bring that back.

    Version

    v2.0.0-RC1

    Git commit hash (if applicable)

    No response

    If applicable, where did you install Barrier from?

    Scoop

    What OSes are you seeing the problem on? (Check all that apply)

    Windows

    What OS versions are you using?

    Windows 11 + Rectify11

    Relevant log output

    No response

    Any other information

    No response

    opened by CamperSamu 0
  • Unable to disable crypto?

    Unable to disable crypto?

    What happened?

    Log outputs the following when attempting to start barrier in either client or server mode:

    [2022-05-20T20:38:48] INFO: starting server
    [2022-05-20T20:38:48] DEBUG: command: /usr/bin/barriers -f --no-tray --debug DEBUG2 --name caleb-ryzen-archlinux --disable-crypto --disable-client-cert-checking -c /tmp/InputLeap.PrXlSr --address :24800
    [2022-05-20T20:38:48] INFO: config file: /tmp/InputLeap.UaXJFt
    [2022-05-20T20:38:48] INFO: log level: DEBUG2
    barriers: unrecognized option `--disable-crypto'
    Try `barriers --help' for more information.
    [2022-05-20T20:38:48] ERROR: process exited with error code: 3
    [2022-05-20T20:38:48] INFO: detected process not running, auto restarting
    [2022-05-20T20:38:48] DEBUG: stopping process
    [2022-05-20T20:38:48] INFO: stopping barrier desktop process
    

    Version

    From Git HEAD or commit (specify below)

    Git commit hash (if applicable)

    c3c1232eccda893a27cc36964551e9dbaf185be1

    If applicable, where did you install Barrier from?

    Self-built executable

    What OSes are you seeing the problem on? (Check all that apply)

    Linux

    What OS versions are you using?

    Arch Linux

    Relevant log output

    No response

    Any other information

    No response

    bug linux from git 
    opened by CCF100 0
  • CTRL+ALT+DEL do not work with Windows Host and Windows Client

    CTRL+ALT+DEL do not work with Windows Host and Windows Client

    What happened?

    I am running 2.3.4. Host and Client on Windows 11 and Windows Server 2022. When I move my cursor to Server 2022 that sits on the lock screen showing "Press Ctrl+Alt+Del to unlock." Then hold Ctrl+Alt+ tap Del the menu comes up on the host only not on the client.

    Expected the Login screen to come up on the Client.

    Version

    v2.3.4

    Git commit hash (if applicable)

    No response

    If applicable, where did you install Barrier from?

    github right here

    What OSes are you seeing the problem on? (Check all that apply)

    Windows

    What OS versions are you using?

    11, Server 2022

    Relevant log output

    No response

    Any other information

    No response

    opened by oilcan-productions 0
  • Qt6

    Qt6

    Contributor Checklist:

    • [ ] I have created a file in the doc/newsfragments directory IF it is a user-visible change (and make sure to read the README.md in that directory)

    Not sure when but when wanting to port to Qt 6 feel free to use this as a starting point. With these 2 commits I'm able to build here on macos (though the gui hangs when clicking Start and a couple warnings are in the terminal when running directly. I'll look into those next.

    opened by jpwhiting 0
  • Windows 11 client can not type in emjoi picker

    Windows 11 client can not type in emjoi picker

    What happened?

    Just upgraded a client machine to Windows 11. When using the emoji picker ( Windows key + period ) I am unable to type text in the text box. In Windows 10 I could type in the text box.

    I can still use the mouse to close the emoji picker and select the text input box. Just can not type.

    Version

    v2.3.3

    Git commit hash (if applicable)

    3395cca9

    If applicable, where did you install Barrier from?

    No response

    What OSes are you seeing the problem on? (Check all that apply)

    Windows

    What OS versions are you using?

    Windows 10 server and Windows 11 client

    Relevant log output

    No response

    Any other information

    No response

    opened by JohnVillalovos 1
Owner
null
Monitor based on perf_event: split-lock, irq-off, profile, task-state, watchdog, kmemleak, kvm-exit, mpdelay

基于perf的监控框架 基于libperf和libtraceevent库实现简单的监控框架,提供比perf更灵活的特性。 数据不落盘。 数据过滤,基于tracepoint的过滤机制,减少数据量。 数据实时处理并输出。不需要存盘后再处理。 基于perf_event_open系统调用。 虽然比perf更

null 19 Nov 20, 2022
ModuLiDAR is an all-in-one open-source software for autonomous UGVs and industrial robots.

ModuLiDAR is an all-in-one open-source software for autonomous UGVs and industrial robots. the target industries that ModuLiDAR is working on are farming industry, mining industry, warehouses industry, and construction industry.

null 18 Jun 22, 2022
SDR++ is a cross-platform and open source SDR software with the aim of being bloat free and simple to use.

SDR++ is a cross-platform and open source SDR software with the aim of being bloat free and simple to use.

AlexandreRouma 2.1k Nov 24, 2022
OpenFOAM is a free, open source computational fluid dynamics (CFD) software package

acousticStreamingFoam About OpenFOAM OpenFOAM is a free, open source computational fluid dynamics (CFD) software package released by the OpenFOAM Foun

Bruno 3 Oct 28, 2022
C++ Open Source Software Template

cpp-oss-template cpp-oss-template is a simple template for C++ language based project. Support CI Appveyor Travis CI Azure Pipelines Support Tool Code

Chris Ohk 12 Jun 21, 2022
OSS-Fuzz - continuous fuzzing for open source software.

OSS-Fuzz: Continuous Fuzzing for Open Source Software Fuzz testing is a well-known technique for uncovering programming errors in software. Many of th

Google 8.1k Dec 2, 2022
OpenToonz - An open-source full-featured 2D animation creation software

OpenToonz 日本語 What is OpenToonz? OpenToonz is a 2D animation software published by DWANGO. It is based on Toonz Studio Ghibli Version, originally deve

OpenToonz 3.6k Dec 2, 2022
Open source software for autonomous drones.

Prometheus - 自主无人机开源项目 [English Readme] Prometheus是希腊神话中最具智慧的神明之一,希望本项目能为无人机研发带来无限的智慧与光明。 项目总览 Prometheus是一套开源的自主无人机软件平台,为无人机的智能与自主飞行提供全套解决方案。本项目基于PX4

Amov Lab 1.6k Nov 28, 2022
Open source hardware design and software for OpenPodcar.

OpenPodcar Open Source Hardware Design and Software for OpenPodcar. OpenPodcar_obstacle_avoidance_INB_Atrium.mov Table of Contents I. General Info II.

null 10 Jul 8, 2022
Open-source and open-hardware scientific RPN calculator

OpenRPNCalc Open-source and open-hardware scientific RPN calculator Introduction OpenRPNCalc is a scientific calculator based on STM32 microcontroller

Anton Poluektov 145 Nov 10, 2022
A fully-functional open source and open hardware mechanical USB computer keyboard with only three keys!

threeboard threeboard is a fully-functional open source and open hardware mechanical USB computer keyboard with only three keys. It supports multiple

Conor Taylor 97 Nov 15, 2022
This is a tool for software engineers to view,record and analyse data(sensor data and module data) In the process of software development.

![Contributors][Huang Jianyu] Statement 由于工具源码在网上公开,除使用部分开源项目代码外,其余代码均来自我个人,工具本身不包含公司的知识产权,所有与公司有关的内容均从软件包中移除,软件发布遵循Apache协议,任何人均可下载进行修改使用,如使用过程中出现任何问

HuangJianyu 34 May 5, 2022
Add virtual monitors to your windows 10 device! Works with Oculus software, obs, and any desktop sharing software

License MIT and CC0 or Public Domain, whichever is least restrictive -- Use it AS IS - NO IMPLICIT OR EXPLICIT warranty This may break your computer,

Rashi Abramson 221 Nov 26, 2022
MasterPlan is a project management software / visual idea board software. It attempts to be easy to use, lightweight, and fun.

MasterPlan is a customizeable graphical project management software for independent users or small teams. If you need to share plans across a whole co

SolarLune 439 Nov 28, 2022
Open Source Cheat for Apex Legends, designed for ease of use. Made to understand reversing of Apex Legends and respawn's modified source engine as well as their Easy Anti Cheat Implementation.

Apex-Legends-SDK Open Source Cheat for Apex Legends, designed for ease of use. Made to understand reversing of Apex Legends and respawn's modified sou

null 107 Nov 20, 2022
Sourcetrail - free and open-source interactive source explorer

Sourcetrail Important Note: This project was archived by the original autors and maintainers of Sourcetrail by the end of 2021. If you want to know mo

Coati Software 13.1k Nov 27, 2022
Single source file ASTC texture decompression in C++ (derived from Google's open source Android project)

astc_dec astc_dec is a single source file ASTC texture decompressor with the Apache 2.0 license, derived from Google's open source Android sources. Th

Rich Geldreich 30 Oct 22, 2022
First open source android modding library for Geometry Dash Based on Hooking-and-Patching-android-template

Android-ML First open source android modding library for Geometry Dash Based on Hooking-and-Patching-android-template Installation Download this githu

BlackTea ML 21 Jul 17, 2022
OpenTibiaBR - Canary Project is a free and open-source MMORPG server emulator written in C++.

OpenTibiaBR - Canary Project is a free and open-source MMORPG server emulator written in C++. It is a fork of the OTServBR-Global project. To connect to the server and to take a stable experience, you can use our own client or tibia client and if you want to edit something, check our customized tools.

OpenTibiaBR 97 Nov 28, 2022