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.

Issues
  • 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
  • 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
  • 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
  • Clipboard being updated by non-active screen

    Clipboard being updated by non-active screen

    What happened?

    Would it be possible to add an option to disable clipboard sharing across devices?

    The reason is that I think it currently conflicts with other clipboard sharing applications. I have been using Join which include sharing clipboard across clients (across devices such as PC/laptops/android phone/etc.).

    Currently while using barrier (or the to-be input-leap), using PC1 as host, copying and pasting on client (PC2) will somehow erase the content. The following are logs from Host (while operating on Client):

    [2022-01-15T14:42:47] INFO: screen "Client" grabbed clipboard 0 from "Host"
    [2022-01-15T14:42:47] INFO: screen "Client" grabbed clipboard 1 from "Host"
    # I think at this point *Join* had sent a network request to update clipboard on PC1 (Host). I haven't done any other operations at this point
    [2022-01-15T14:42:50] INFO: screen "Host" grabbed clipboard 0 from "Client"
    [2022-01-15T14:42:50] INFO: screen "Host" grabbed clipboard 1 from "Client"
    

    where the lines

    [2022-01-15T14:42:50] INFO: screen "Host" grabbed clipboard 0 from "Client"
    [2022-01-15T14:42:50] INFO: screen "Host" grabbed clipboard 1 from "Client"
    

    ended up resetting the clipboard.

    Version

    v2.4.0

    Git commit hash (if applicable)

    No response

    If applicable, where did you install Barrier from?

    Host: Linux by compiling Client: Windows from release

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

    Linux, Windows

    What OS versions are you using?

    Host: Arch Linux with latest Kernel Client: Windows 10

    Relevant log output

    No response

    Any other information

    No response

    question windows linux 
    opened by soraxas 3
  • Enhance Windows CI builds

    Enhance Windows CI builds

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

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

    This PR adds support for the Windows Server 2022 build agent. This isn't based on Windows 11, but rather Windows 10. I added 2022, 2019, and 2016 to a build matrix. Currently, 2022 and 2016 are disabled.

    I had to do that because currently they fail to build, as the BATCH script has the VS SDK path hardcoded. Until we fix that, the aforementioned build agents will remain disabled.

    ## 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-05 by @shymega

    Hrm, it seems the Mac PR has been merged into this. I'm going to force-push, and remove that branch from this PR, as it shouldn't be there...


    Commented on: 2021-11-05 by @shymega

    This isn't right. My branch hasn't even been done correctly. Fixing locally, then force-pushing. Sorry.


    Commented on: 2021-11-05 by @shymega

    Fixed, but may need conflict resolution when #1385 is merged.


    Commented on: 2021-11-05 by @shymega

    The CI check seems to have been skipped. Odd. Might be related to the force-push fixing the PR... i can't trigger a build myself.


    Commented on: 2021-11-05 by @shymega

    CI builds are still being skipped. Log output suggests builds aren't being triggered, but this PR changed nothing about CI triggers.


    Commented on: 2021-11-05 by @shymega

    There we go. That fixed it - I hadn't done a block comment on the disabled agents.


    Commented on: 2021-11-05 by @p12tic

    Do we really need debug builds? This would only be useful in the case that matches all of the following:

    • There is an issue that we can't reproduce.
    • The issue requires attaching a debugger as opposed to just printing more things to the logs.
    • There is an user that can use a debugger.
    • The user can't build Barrier themselves.

    I think the likelihood for such problems is very small and worst case we can build barrier ourselves.


    Commented on: 2021-11-05 by @p12tic

    Release notes are needed for user-visible features. In this case the user doesn't see anything yet, is that right?


    Commented on: 2021-11-05 by @shymega

    Oh. I just followed the PR template. I can remove this if you'd like me to.


    Commented on: 2021-11-05 by @shymega

    Sure, I was merely mirroring your feedback in the Mac PR, and I didn't see any harm in including it here. Would you like me to remove the Debug builds?


    Commented on: 2021-11-05 by @p12tic

    In this case I will need to remove this release note when doing the release anyway, so better remove.

    I should have said something about PRs with non user visible features in the PR template


    Commented on: 2021-11-05 by @shymega

    OK, removed in 21eae23e.


    Commented on: 2021-11-05 by @shymega

    OK. So, my proposal is to remove the Debug builds, keep the Release builders, and generate installers from the 2016 agent, if that one works. I will use a condition for the installer part, based on the imageName variable - not the CI_ENV_BUILD_TYPE, which means less complexity. Thoughts?


    Commented on: 2021-11-05 by @p12tic

    Sounds good.


    Commented on: 2021-11-05 by @shymega

    Resolved in be2f658f.


    Commented on: 2021-11-05 by @shymega

    I've rebased to master. I'm waiting for CI checks now, but I think we should squash the numerous commits here.

    build-infra windows 
    opened by povilas-barrier-bot 3
  • Miscellaneous warnings

    Miscellaneous warnings

    This PR fixes more miscellaneous warnings.

    • [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 2
  • Inital update of README - more work to be done

    Inital update of README - more work to be done

    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 2
  • The links from the readme point to the repository before forking.

    The links from the readme point to the repository before forking.

    What happened?

    All the links in the readme point to the old repository before the fork, not sure if that's your intended behavior, but to me it seems like you missed that.

    Version

    From Git HEAD or commit (specify below)

    Git commit hash (if applicable)

    No response

    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?

    n/a

    Relevant log output

    No response

    Any other information

    No response

    opened by akutoku 2
  • Barrier service doesent start

    Barrier service doesent start

    What happened?

    Issue: When I start Barrier on the client it gets stuck on "Barrier is starting.". And when I take a look in the Log, it shows the error "ERROR: ipc connection error, connection refused". And in Task Manager under Services it shows that the Barrier service hasnt started. When I try to manually start it, it says "Error 1053: The service did not respond to the start or control request in a timely fashion.".

    Version

    v2.3.4

    Git commit hash (if applicable)

    No response

    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?

    Server: Ubuntu Ubuntu 22.04 LTS

    Client: Windows 10 Pro

    Relevant log output

    ERROR: ipc connection error, connection refused
    

    Any other information

    I tried it with different versions of Barrier but it throws the same error every time.

    opened by Sko0ol 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
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 8 Jun 24, 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 1.7k Jun 23, 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 1 Nov 2, 2021
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 7.5k Jun 30, 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.5k Jun 19, 2022
Open source software for autonomous drones.

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

Amov Lab 1.3k Jun 25, 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 9 Jun 7, 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 135 Jun 21, 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 May 23, 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 162 Jun 21, 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 405 Jun 23, 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 86 Jun 24, 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 12.7k Jun 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 28 Apr 11, 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 22 Jun 19, 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 59 Jun 22, 2022