mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #759] REQ: ChromeOS support #593
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#593
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 @jxyzn on GitHub (Jun 19, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/759
A long-standing open request for Synergy has been Chromebook/ChromeOS support. This is complicated by the fact that X has been mostly abstracted away in ChromeOS and 'remote control' capability has been carefully walled away, so nothing has been done to address it in that project.
HOWEVER, I have done some experimentation with libevdev (https://www.freedesktop.org/software/libevdev/doc/latest/) and evemu (https://github.com/whot/evemu) using a linux desktop keyboard+mouse server to a Chromebook laptop client with promising results. The input events captured through evdev can be pushed across the network and played-back through a simulated input device created to mimic the source device with evemu.
I don't have the background necessary to implement a robust and integrated solution with Barrier, but I'm hoping that awareness of the possibility of this approach might encourage some further exploration of this possibility.
@shymega commented on GitHub (Jun 19, 2020):
Interesting idea, and thanks for the experimentation. Unfortunately, we can't devote resources to this feature request at the moment, due to a huge backlog of other more pressing bugs (including memory leakage), and we also simply don't have enough developers available right now. I will mark this is a feature request.
Thanks..
@github-actions[bot] commented on GitHub (Sep 19, 2020):
This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.
@herychemo commented on GitHub (Aug 18, 2021):
Any updates on this feature?
Thx
@shymega commented on GitHub (Aug 18, 2021):
No.
@ckozler commented on GitHub (Jul 21, 2022):
Hello @shymega. I know this issue is somewhat stale but I wanted to let you know I have recently attempted a recent Flex 5 Chromebook and Barrier. I can see the log indicating entering and leaving a screen is detected, however, inputs don't work. I am guessing this is due to a way Google has modified the kernel inputs and thus Barrier cannot hook on to them (or whatever beautiful magic is under the hood). Using sudo and pkexec generates the errors I expect about no display found
In any case, I would be happy to test any feedback you might have on this or if chromebook will outright not be supported (I could not find this outlined anywhere)
@CarlosLRamirez commented on GitHub (Oct 10, 2022):
Hello, wondering if barrier works on Chromebooks now, before attempt to install it?
@andrewthetechie commented on GitHub (Oct 23, 2022):
@CarlosLRamirez not at this time.
@shymega commented on GitHub (Nov 26, 2022):
And (cc: @CarlosLRamirez)
I don't work on Barrier anymore, but thank you for testing it on Chromebook. I don't think Google have modified the kernel, as it's likely to be userland, but this isn't something I'm focusing on right now. I don't even own a Chromebook.
@FernandesLucass commented on GitHub (Mar 22, 2025):
Just to update the situation, tested the connection between Windows and Chromebook and hasn't worked yet!