mirror of
https://github.com/feschber/lan-mouse.git
synced 2026-05-15 14:15:52 -06:00
[GH-ISSUE #37] Chrome OS support #8
Labels
No labels
Xorg
documentation
enhancement
macos
pull-request
question
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/lan-mouse#8
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 @jsinterface on GitHub (Nov 26, 2023).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/37
trying to test this in a graphically rather limited wayland environment (chrome os), and i worked through a few errors to satisfy the gui dependencies, but libadwaita being a more complicated one, I'm just wishing for a way to opt out of building the gui and rely on the cli only:
is it already available just not mentioned in the readme?
Sorry if it could be determined with more familiarity with cargo toolchains.
Thanks!
@feschber commented on GitHub (Nov 27, 2023):
Disabling individual features does not seem to be possible as of now:
https://github.com/rust-lang/cargo/issues/3126
There is two Options:
--no-default-featuresand add all the features manually:Cargo.tomland remove the feature from there:e88241e816/Cargo.toml (L52)@feschber commented on GitHub (Nov 27, 2023):
If you could tell me what Distro you're using, I may be able to help you with getting libadwaita installed.
@feschber commented on GitHub (Nov 27, 2023):
Sorry I overlooked chrome os.
@feschber commented on GitHub (Dec 1, 2023):
Do you have an update on this?
I'm curious if chrome os works but I feel like they probably dont support the necessary wayland protocols or desktop portals.
@jpeeler commented on GitHub (Dec 15, 2023):
I tried running in a Crostini container (with libadwaita-1-0 installed) and got this:
@feschber commented on GitHub (Dec 15, 2023):
You are on a Chromebook as well?
@jpeeler commented on GitHub (Dec 15, 2023):
Yeah (don't think Crostini exists anywhere else). I compiled the binary on a more powerful linux host and copied over the binary - I assume that doesn't matter.
@feschber commented on GitHub (Dec 15, 2023):
Could you run
wayland-infoin that container and list the supported interfaces here?For input capture either the
wlr_layer_shellprotocol would need to be implemented or libei support is requiredand for input emulation the best bet is probably the remote desktop portal but I don't think that is available in chrome os either.
I would not get my hopes up too much that any of this works in Chrome OS unfortunately.
@jpeeler commented on GitHub (Dec 15, 2023):
I don't really have my hopes up for ChromeOS. But I am interested in the rest of the operating systems, especially Linux+MacOS. If I can help debug integration any there let me know.
@feschber commented on GitHub (Dec 15, 2023):
gtk_shell1 might be a valid fallback for layer_shell but at least zwp_keyboard_shortcuts_inhibit_manager_v1 would still be required to do anything useful.
Will do :) Still in pretty early development.
@jsinterface commented on GitHub (Dec 16, 2023):
sorry i dropped out a bit, i layed off trying to control my chromebooks for a bit, but i'm still interested and will get back to testing.
Two things i'd note is i think building on another linux distro and copying the binary may not be indifferent (statically linked libraries missing or dynamic env assumptions differing). In my build attempts i was building on crostini directly, and running from there, but you could also be right @jpeeler .
Secondly, in chromeos, crostini is a virtual machine with a little more integration than usual which makes it a viable candidate, but there is also the host "crosh" (chromeos shell) system with more limited, but at least not virtual linux environment which i was also testing against.
I'll return to keep on testing, i just missed notifications of your engagement here, but i'm happy to see the support, thanks!
@feschber commented on GitHub (Dec 16, 2023):
Cheers!
You could do one more thing: Try to run with XDG_CURRENT_DESKTOP=KDE. That way we can tell whether or not the remote desktop portal is available.
At least rudimentary input capture should always be possible through an application window. I feel Iike input emulation might be the bigger problem
@jpeeler commented on GitHub (Dec 16, 2023):
Is this what you were asking about, @feschber ?
I thought that the remote desktop portal was something to be installed. Surprisingly I do have xdg-desktop-portal-gtk and xdg-desktop-portal installed. Wondering if switching to the KDE version would be helpful, though when I set the current desktop to gnome I get the exact same output.
@bpstrngr I thought crosh was restricted to executing Chrome management utilities. You're saying there's a way to run scripts/binaries in that environment?
@feschber commented on GitHub (Dec 16, 2023):
It must be capital KDE, what you want is the xdg-desktop-portal backend
@jpeeler commented on GitHub (Dec 16, 2023):
@feschber commented on GitHub (Dec 16, 2023):
Can you rerun this with LAN_MOUSE_LOG_LEVEL=debug?
@jpeeler commented on GitHub (Dec 16, 2023):
CLI run
@feschber commented on GitHub (Dec 16, 2023):
Okay, seems like I need to add some more debug information first.
@feschber commented on GitHub (Dec 17, 2023):
@jpeeler you can try the latest main now. I added a fallback interface so it does not crash before we know whats going on.
XDG_CURRENT_DESKTOP=KDE is not required anymore
@jpeeler commented on GitHub (Dec 17, 2023):
(Using
a6ab109fae).@feschber commented on GitHub (Dec 18, 2023):
Okay seems like the remote desktop portal is not available. XTest likely wont work either.
@feschber commented on GitHub (Dec 19, 2023):
This Gtk-CRITICAL error is because I had used widgets from libadwaita-1.4 (accidentally). If you try the latest main, you may be able to get the gui to launch.
@jpeeler commented on GitHub (Dec 19, 2023):
Yep, I was compiling against libadwaita-rs 0.5.2. The GUI does indeed launch, which is nice.
@jpeeler commented on GitHub (Dec 19, 2023):
Something I just wondered - do you know of any necessary portal versions that are required to get things to work? This linux container I'm testing with is running Debian 12. The KDE portal is 5.27.5, which seems to be around 7 months old. But maybe everything that is required has been implemented for a while and the problem is more so on the ChromeOS wayland side.
@feschber commented on GitHub (Dec 19, 2023):
For input emulation only the remote desktop portal is required. (org.freedesktop.portal.RemoteDesktop).
This has been around for a quite a while in xdg-desktop-portal-kde.
Do I understand correctly that you are running KDE on a Linux container in ChromeOS?
Can you check the output of
qdbus?It should list all of the available portals.
@jpeeler commented on GitHub (Dec 19, 2023):
The xdg-desktop-portal package is 1.16.0, which is about 12 months old. And I realized that I only had the -gtk portal installed earlier. However, it doesn't change the result all that much.
I am not running KDE as a desktop environment on ChromeOS if that's what you're asking. But am using their packages to run various apps (such as VLC).
I don't understand why the KDE portal is not listed though.
@jsinterface commented on GitHub (Dec 24, 2023):
found the time to test this too, starting from the point where you taught me how to opt out of libadwaita, i compiled with
cargo build --release --no-default-features --features waylandin crostini.inside crostini, it's the same result as for jpeeler,
The thing i can add, for what it's worth, is what happens outside crostini, on the host chromeos shell:
or, when built with "x11,xdg_desktop_portal" features included:
(been down the rabbit hole of building/copying such libs individually, in this case i assume the list would be long, so i just didn't include these features, X11 will certainly be ever foreign to the native chromeos shell).
And yes, @jpeeler official chromeos distributions lock the user out of the host shell, but "switching to dev mode", or chromium os builds, give access to it. it's a really minimal raspberry pi-like gentoo environment with not even portage being functional (although i commonly run nodejs/python there without any problems), so probably won't be easy to give any more diagnostics about the wayland environment.
@jsinterface commented on GitHub (Dec 24, 2023):
Oh, and mind you, i had to checkout the v0.3.3 tag, because on the latest main, and several commits back,
cargo build --releaseon crostini has started failing with@feschber commented on GitHub (Dec 28, 2023):
ChromeOS would need to support either
For input emulation
And either
for input capture
Neither of which is very likely to happen anytime soon.
The error you are seeing is because xdg-output
is currently used to detect the dimensions of monitors attached to a PC. I can fallback to wl-output which must be supported by any wayland compositor.
That would lead to the next error though, which is that wlr-layer-shell is not supported.
For that I could craft another fallback to a simple xdg-toplevel (normal application window) that you would move the mouse into to control another PC. (not very elegant but a somewhat useful fallback).
So in short the options to get input capture working are:
For input emulation I have less hope other than chromeos supporting either xdg remote desktop or Libei at some point.
The other error you are seeing is very peculiar and seems to be an issue with cargo on chromeos.
You could comment out the "reis" dependency from
Cargo.tomlto work around it (its only needed for libei, which is not supported anyway).With that the GUI should now launch as well.