github-starred/lan-mouse
2
0
Fork 0
mirror of https://github.com/feschber/lan-mouse.git synced 2026-05-15 14:15:52 -06:00
Code Issues 107 Projects Packages Wiki Activity Actions

[GH-ISSUE #74] KDE prompts Remote Control Request muliple times and answer doesn't matter. #23

New issue
Closed
opened 2026-05-05 22:04:40 -06:00 by gitea-mirror · 17 comments
gitea-mirror commented 2026-05-05 22:04:40 -06:00
Owner
Copy link

Originally created by @CupricReki on GitHub (Jan 15, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/74

I'm getting multiple Remote Control Request every time I launch lan-mouse from the CLI.

Log

❯ lan-mouse
[2024-01-15T14:52:24Z INFO  lan_mouse::config] using config: "/home/cupric/.config/lan-mouse/config.toml"

(lan-mouse:1668930): Gtk-WARNING **: 09:52:24.175: Unknown key gtk-modules in /home/cupric/.config/gtk-4.0/settings.ini
[2024-01-15T14:52:24Z INFO  lan_mouse::config] using config: "/home/cupric/.config/lan-mouse/config.toml"
[2024-01-15T14:52:24Z INFO  lan_mouse] Press Ctrl+Alt+Shift+Super to release the mouse
[2024-01-15T14:52:24Z INFO  lan_mouse::consumer] wayland backend not available: the requested global was not found in the registry
[2024-01-15T14:52:24Z INFO  lan_mouse::producer] libei event producer not available: not implemented
[2024-01-15T14:52:24Z INFO  lan_mouse::producer] using layer-shell event producer

(lan-mouse:1668930): Adwaita-WARNING **: 09:52:24.261: Using GtkSettings:gtk-application-prefer-dark-theme with libadwaita is unsupported. Please use AdwStyleManager:color-scheme instead.

KDE Screenshare

[2024-01-15T14:52:34Z INFO  lan_mouse::consumer] libei not available: Portal request failed: org.freedesktop.zbus.Error: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'ConnectToEIS' in interface 'org.freedesktop.impl.portal.RemoteDesktop' at object path '/org/freedesktop/portal/desktop' (signature 'osa{sv}')

Remote Control Request prompt shows a second time.

[2024-01-15T14:52:40Z INFO  lan_mouse::consumer] using xdg-remote-desktop-portal event consumer
[2024-01-15T14:52:49Z INFO  lan_mouse] terminating service
[2024-01-15T14:52:49Z INFO  lan_mouse::server] terminating service
[2024-01-15T14:52:49Z INFO  lan_mouse::server] terminating gracefully...

Notes

  • Interestingly, it doesn't matter how if I accept or not, lan-mouse still works.
  • When launching via lan-mouse I don't always get the prompt, but I do get a notification.
    KDE Screenshare popup
Originally created by @CupricReki on GitHub (Jan 15, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/74 I'm getting multiple Remote Control Request every time I launch lan-mouse from the CLI. ## Log ``` ❯ lan-mouse [2024-01-15T14:52:24Z INFO lan_mouse::config] using config: "/home/cupric/.config/lan-mouse/config.toml" (lan-mouse:1668930): Gtk-WARNING **: 09:52:24.175: Unknown key gtk-modules in /home/cupric/.config/gtk-4.0/settings.ini [2024-01-15T14:52:24Z INFO lan_mouse::config] using config: "/home/cupric/.config/lan-mouse/config.toml" [2024-01-15T14:52:24Z INFO lan_mouse] Press Ctrl+Alt+Shift+Super to release the mouse [2024-01-15T14:52:24Z INFO lan_mouse::consumer] wayland backend not available: the requested global was not found in the registry [2024-01-15T14:52:24Z INFO lan_mouse::producer] libei event producer not available: not implemented [2024-01-15T14:52:24Z INFO lan_mouse::producer] using layer-shell event producer (lan-mouse:1668930): Adwaita-WARNING **: 09:52:24.261: Using GtkSettings:gtk-application-prefer-dark-theme with libadwaita is unsupported. Please use AdwStyleManager:color-scheme instead. ``` ![KDE Screenshare](https://github.com/feschber/lan-mouse/assets/6509200/882e06df-058b-40be-895f-31baa2a798ae) ``` [2024-01-15T14:52:34Z INFO lan_mouse::consumer] libei not available: Portal request failed: org.freedesktop.zbus.Error: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'ConnectToEIS' in interface 'org.freedesktop.impl.portal.RemoteDesktop' at object path '/org/freedesktop/portal/desktop' (signature 'osa{sv}') ``` Remote Control Request prompt shows a second time. ``` [2024-01-15T14:52:40Z INFO lan_mouse::consumer] using xdg-remote-desktop-portal event consumer [2024-01-15T14:52:49Z INFO lan_mouse] terminating service [2024-01-15T14:52:49Z INFO lan_mouse::server] terminating service [2024-01-15T14:52:49Z INFO lan_mouse::server] terminating gracefully... ``` ## Notes - Interestingly, it doesn't matter how if I accept or not, lan-mouse still works. - When launching via lan-mouse I don't always get the prompt, but I do get a notification. ![KDE Screenshare popup](https://github.com/feschber/lan-mouse/assets/6509200/1dcbb2fe-d9c0-4b6d-b5d3-cc2f4898cde0)
gitea-mirror commented 2026-05-05 22:04:43 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Jan 15, 2024):

The reason it shows up twice is that it first tries to connect to Libei, which is done through the same RemoteDesktopPortal interface as the actual remote desktop portal backend.

KDE does not implement Libei yet so that fails. Then the remote desktop portal requests access again.

It would be possible to work around this by simply requesting the remote desktop portal on KDE directly instead of Libei (I actually did this in earlier versions until I changed it to this fallback based system) but I'd rather leave it like this until KDE supports libei (I dont know how long that is going to take maybe I can look into it if I have the time).

As far as I have seen, KDE does not ask again once the permission has been granted once for a specific application so I dont think this should be a large issue but let me know your thoughts.

<!-- gh-comment-id:1892712574 --> @feschber commented on GitHub (Jan 15, 2024): The reason it shows up twice is that it first tries to connect to Libei, which is done through the same RemoteDesktopPortal interface as the actual remote desktop portal backend. KDE does not implement Libei yet so that fails. Then the remote desktop portal requests access again. It would be possible to work around this by simply requesting the remote desktop portal on KDE directly instead of Libei (I actually did this in earlier versions until I changed it to this fallback based system) but I'd rather leave it like this until KDE supports libei (I dont know how long that is going to take maybe I can look into it if I have the time). As far as I have seen, KDE does not ask again once the permission has been granted once for a specific application so I dont think this should be a large issue but let me know your thoughts.
gitea-mirror commented 2026-05-05 22:04:43 -06:00
Author
Owner
Copy link

@CupricReki commented on GitHub (Jan 17, 2024):

I'm not sure what triggers the permission prompt to be again after being accepted the first time. Perhaps the issue will go away now that that I'm installing/updating via the AUR.

Keeping this open for now.

<!-- gh-comment-id:1894830384 --> @CupricReki commented on GitHub (Jan 17, 2024): I'm not sure what triggers the permission prompt to be again after being accepted the first time. Perhaps the issue will go away now that that I'm installing/updating via the AUR. Keeping this open for now.
gitea-mirror commented 2026-05-05 22:04:44 -06:00
Author
Owner
Copy link

@CupricReki commented on GitHub (Jan 17, 2024):

Bummer about Libei. But it looks like it might come to Plasma 6.1 https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12.

<!-- gh-comment-id:1894844543 --> @CupricReki commented on GitHub (Jan 17, 2024): Bummer about Libei. But it looks like it might come to Plasma 6.1 https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12.
gitea-mirror commented 2026-05-05 22:04:45 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Jan 19, 2024):

I'm not sure what triggers the permission prompt to be again after being accepted the first time. Perhaps the issue will go away now that that I'm installing/updating via the AUR.

Keeping this open for now.

Did you test this? I am not getting prompts after accepting it for the first time.

<!-- gh-comment-id:1900412543 --> @feschber commented on GitHub (Jan 19, 2024): > I'm not sure what triggers the permission prompt to be again after being accepted the first time. Perhaps the issue will go away now that that I'm installing/updating via the AUR. > > Keeping this open for now. Did you test this? I am not getting prompts after accepting it for the first time.
gitea-mirror commented 2026-05-05 22:04:46 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Mar 16, 2024):

something must have changed because I see the prompt everytime now as well. Will see what I can do about that

<!-- gh-comment-id:2002089016 --> @feschber commented on GitHub (Mar 16, 2024): something must have changed because I see the prompt everytime now as well. Will see what I can do about that
gitea-mirror commented 2026-05-05 22:04:47 -06:00
Author
Owner
Copy link

@CupricReki commented on GitHub (Mar 17, 2024):

Did you update to Plasma 6?

On Sat, Mar 16, 2024, 7:59 PM Ferdinand Schober @.***>
wrote:

something must have changed because I see the prompt everytime now as
well. Will see what I can do about that

—
Reply to this email directly, view it on GitHub
https://github.com/feschber/lan-mouse/issues/74#issuecomment-2002089016,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRVFEDRXOK2U5GNYKKUYJDYYSI7XAVCNFSM6AAAAABB3ODEYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGA4DSMBRGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

<!-- gh-comment-id:2002361447 --> @CupricReki commented on GitHub (Mar 17, 2024): Did you update to Plasma 6? On Sat, Mar 16, 2024, 7:59 PM Ferdinand Schober ***@***.***> wrote: > something must have changed because I see the prompt everytime now as > well. Will see what I can do about that > > — > Reply to this email directly, view it on GitHub > <https://github.com/feschber/lan-mouse/issues/74#issuecomment-2002089016>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABRVFEDRXOK2U5GNYKKUYJDYYSI7XAVCNFSM6AAAAABB3ODEYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGA4DSMBRGY> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >
gitea-mirror commented 2026-05-05 22:04:47 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Mar 17, 2024):

Yes but I can not say 100% if that was the point where it started. Will need to check

<!-- gh-comment-id:2002362338 --> @feschber commented on GitHub (Mar 17, 2024): Yes but I can not say 100% if that was the point where it started. Will need to check
gitea-mirror commented 2026-05-05 22:04:48 -06:00
Author
Owner
Copy link

@svillar commented on GitHub (Apr 10, 2024):

I've seen the same in GNOME FWIW

<!-- gh-comment-id:2046843536 --> @svillar commented on GitHub (Apr 10, 2024): I've seen the same in GNOME FWIW
gitea-mirror commented 2026-05-05 22:04:49 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Apr 10, 2024):

What version of GNOME are you using? Starting at 45, it should only ask once as libei is now supported.

I also changed the behaviour in 0.7 now, such that it asks again if the request is cancelled. So technically it now works as intended.

I could maybe look into merging the backends into one or reuse the same portal but idk if thats actually possible even.

<!-- gh-comment-id:2047037372 --> @feschber commented on GitHub (Apr 10, 2024): What version of GNOME are you using? Starting at 45, it should only ask once as libei is now supported. I also changed the behaviour in 0.7 now, such that it asks again if the request is cancelled. So technically it now works as intended. I could maybe look into merging the backends into one or reuse the same portal but idk if thats actually possible even.
gitea-mirror commented 2026-05-05 22:04:50 -06:00
Author
Owner
Copy link

@svillar commented on GitHub (Apr 10, 2024):

What version of GNOME are you using? Starting at 45, it should only ask once as libei is now supported.

Ah maybe that's the reason, I've 45-46 in one machine but 43 in another one. Actually I couldn't make the software work at all, clients are detected but cannot share the keyboard/mouse among them. I've tried both Wayland and X11 sessions (actually the reason to try lan-mouse is the wayland support, because for X11 Ilaready have barrier working fine) I've installed libei in all the computers but shows still as unsupported

<!-- gh-comment-id:2047290758 --> @svillar commented on GitHub (Apr 10, 2024): > What version of GNOME are you using? Starting at 45, it should only ask once as libei is now supported. Ah maybe that's the reason, I've 45-46 in one machine but 43 in another one. Actually I couldn't make the software work at all, clients are detected but cannot share the keyboard/mouse among them. I've tried both Wayland and X11 sessions (actually the reason to try lan-mouse is the wayland support, because for X11 Ilaready have `barrier` working fine) I've installed libei in all the computers but shows still as unsupported
gitea-mirror commented 2026-05-05 22:04:51 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Apr 10, 2024):

Yeah libei alone won't help because gnome does not implement the input capture portal until version 45.

<!-- gh-comment-id:2047309379 --> @feschber commented on GitHub (Apr 10, 2024): Yeah libei alone won't help because gnome does not implement the input capture portal until version 45.
gitea-mirror commented 2026-05-05 22:04:51 -06:00
Author
Owner
Copy link

@svillar commented on GitHub (Apr 10, 2024):

Yeah libei alone won't help because gnome does not implement the input capture portal until version 45.

And should it work using any other fallback? I'm just trying to know whether this mix of GNOME 45 with 43 should work and then the problem is my configuration, or instead, I should wait till GNOME 45 in stable

<!-- gh-comment-id:2047313583 --> @svillar commented on GitHub (Apr 10, 2024): > Yeah libei alone won't help because gnome does not implement the input capture portal until version 45. And should it work using any other fallback? I'm just trying to know whether this mix of GNOME 45 with 43 should work and then the problem is my configuration, or instead, I should wait till GNOME 45 in stable
gitea-mirror commented 2026-05-05 22:04:52 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Apr 10, 2024):

And should it work using any other fallback?

Unfortunately not, no. Gnome does not support the layer-shell protocol.

<!-- gh-comment-id:2047380323 --> @feschber commented on GitHub (Apr 10, 2024): > And should it work using any other fallback? Unfortunately not, no. Gnome does not support the layer-shell protocol.
gitea-mirror commented 2026-05-05 22:04:54 -06:00
Author
Owner
Copy link

@CupricReki commented on GitHub (Apr 16, 2024):

Since updating to Plasma 6 I see two prompts every time we I start lan mouse

<!-- gh-comment-id:2060085897 --> @CupricReki commented on GitHub (Apr 16, 2024): Since updating to Plasma 6 I see two prompts every time we I start lan mouse
gitea-mirror commented 2026-05-05 22:04:54 -06:00
Author
Owner
Copy link

@hoergen commented on GitHub (Aug 1, 2024):

I'm running Plasma 6.1.3 / Framework 6.4.0 and Wayland and still getting the request every time I start lan-mouse. I had to create "/.config/lan-mouse/config.toml" manually, because it wasn't created automatically.

When I start lan-mouse on two computers they can't find each other.

This is what I get, when I start lan-mouse in the terminal. There are a lot errors, but I don't know how to solve it.
Maybe somebody else, already have an idea how to solve it?


./lan-mouse 
[2024-08-01T10:07:04Z INFO  lan_mouse::config] using config: "/home/USER/.config/lan-mouse/config.toml"
[2024-08-01T10:07:04Z INFO  lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt]
[2024-08-01T10:07:04Z INFO  lan_mouse::config] using config: "/home/USER/.config/lan-mouse/config.toml"
[2024-08-01T10:07:04Z INFO  lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt]
[2024-08-01T10:07:04Z INFO  lan_mouse] Press [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt] to release the mouse
[2024-08-01T10:07:04Z INFO  lan_mouse::server] running service
[2024-08-01T10:07:04Z INFO  lan_mouse::server::emulation_task] creating input emulation...
[2024-08-01T10:07:04Z WARN  input_emulation] wlroots backend: `wayland protocol "wlr-virtual-pointer-unstable-v1" not supported: the requested global was not found in the registry`

(lan-mouse:18504): Gtk-WARNING **: 12:07:04.162: Unknown key gtk-modules in /home/USER/.config/gtk-4.0/settings.ini

(lan-mouse:18504): Gtk-WARNING **: 12:07:04.178: Theme directory places/symbolic of theme tuxedo-breeze-dark has no size field

[2024-08-01T10:07:04Z INFO  input_emulation::libei] requesting permission for input emulation

(lan-mouse:18504): Adwaita-WARNING **: 12:07:04.295: Using GtkSettings:gtk-application-prefer-dark-theme with libadwaita is unsupported. Please use AdwStyleManager:color-scheme instead.

(lan-mouse:18504): Gtk-WARNING **: 12:07:04.371: Theme directory places/symbolic of theme tuxedo-breeze-dark has no size field

[2024-08-01T10:07:07Z WARN  input_emulation] libei backend: `Portal request failed: org.freedesktop.zbus.Error: GDBus.Error:org.freedesktop.DBus.Error.Failed: Failed to connect to to EIS`
[2024-08-01T10:07:07Z INFO  input_emulation::xdg_desktop_portal] requesting permission for input emulation
[2024-08-01T10:07:08Z INFO  input_emulation] using emulation backend: xdg-desktop-portal
[2024-08-01T10:07:10Z WARN  input_capture] input-capture-portal input capture backend unavailable: error creating input-capture-portal backend: `xdg-desktop-portal: `Portal request didn't succeed: Other``
[2024-08-01T10:07:10Z INFO  input_capture] using capture backend: layer-shell
[2024-08-01T10:07:10Z INFO  lan_mouse::server::capture_task] []
<!-- gh-comment-id:2262671209 --> @hoergen commented on GitHub (Aug 1, 2024): I'm running Plasma 6.1.3 / Framework 6.4.0 and Wayland and still getting the request every time I start lan-mouse. I had to create "/.config/lan-mouse/config.toml" manually, because it wasn't created automatically. When I start lan-mouse on two computers they can't find each other. This is what I get, when I start lan-mouse in the terminal. There are a lot errors, but I don't know how to solve it. Maybe somebody else, already have an idea how to solve it? ``` ./lan-mouse [2024-08-01T10:07:04Z INFO lan_mouse::config] using config: "/home/USER/.config/lan-mouse/config.toml" [2024-08-01T10:07:04Z INFO lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt] [2024-08-01T10:07:04Z INFO lan_mouse::config] using config: "/home/USER/.config/lan-mouse/config.toml" [2024-08-01T10:07:04Z INFO lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt] [2024-08-01T10:07:04Z INFO lan_mouse] Press [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt] to release the mouse [2024-08-01T10:07:04Z INFO lan_mouse::server] running service [2024-08-01T10:07:04Z INFO lan_mouse::server::emulation_task] creating input emulation... [2024-08-01T10:07:04Z WARN input_emulation] wlroots backend: `wayland protocol "wlr-virtual-pointer-unstable-v1" not supported: the requested global was not found in the registry` (lan-mouse:18504): Gtk-WARNING **: 12:07:04.162: Unknown key gtk-modules in /home/USER/.config/gtk-4.0/settings.ini (lan-mouse:18504): Gtk-WARNING **: 12:07:04.178: Theme directory places/symbolic of theme tuxedo-breeze-dark has no size field [2024-08-01T10:07:04Z INFO input_emulation::libei] requesting permission for input emulation (lan-mouse:18504): Adwaita-WARNING **: 12:07:04.295: Using GtkSettings:gtk-application-prefer-dark-theme with libadwaita is unsupported. Please use AdwStyleManager:color-scheme instead. (lan-mouse:18504): Gtk-WARNING **: 12:07:04.371: Theme directory places/symbolic of theme tuxedo-breeze-dark has no size field [2024-08-01T10:07:07Z WARN input_emulation] libei backend: `Portal request failed: org.freedesktop.zbus.Error: GDBus.Error:org.freedesktop.DBus.Error.Failed: Failed to connect to to EIS` [2024-08-01T10:07:07Z INFO input_emulation::xdg_desktop_portal] requesting permission for input emulation [2024-08-01T10:07:08Z INFO input_emulation] using emulation backend: xdg-desktop-portal [2024-08-01T10:07:10Z WARN input_capture] input-capture-portal input capture backend unavailable: error creating input-capture-portal backend: `xdg-desktop-portal: `Portal request didn't succeed: Other`` [2024-08-01T10:07:10Z INFO input_capture] using capture backend: layer-shell [2024-08-01T10:07:10Z INFO lan_mouse::server::capture_task] [] ```
gitea-mirror commented 2026-05-05 22:04:55 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Aug 1, 2024):

Did you configure your clients? You need to add the corresponding device on both ends (device B on device A and device A on device B).

<!-- gh-comment-id:2263023388 --> @feschber commented on GitHub (Aug 1, 2024): Did you configure your clients? You need to add the corresponding device on both ends (device B on device A and device A on device B).
gitea-mirror commented 2026-05-05 22:04:55 -06:00
Author
Owner
Copy link

@gnespolino commented on GitHub (Oct 28, 2024):

I'm also affected by this.
Not clear why, but 2 PC with same OS (Manjaro KDE Plasma 6) and same updates, on one of them I can't enable input capture. So what happen when I configure clients on both, is that I can move from PC A to B, but I can't go back from B to A, B being the one where input capture cannot be enabled, mouse and keyboard connected to PC A.
This is what I get in the console when I click on "Reenable" and I allow input capture:

[2024-10-28T13:52:36Z INFO  lan_mouse::server] received capture enable request
[2024-10-28T13:52:44Z WARN  input_capture] input-capture-portal input capture backend unavailable: error creating input-capture-portal backend: `xdg-desktop-portal: `Portal request didn't succeed: Other``
[2024-10-28T13:52:44Z WARN  input_capture] layer-shell input capture backend unavailable: error creating layer-shell capture backend: `Could not find wayland compositor`
[2024-10-28T13:52:44Z WARN  input_capture] X11 input capture backend unavailable: error creating x11 capture backend: `X11 input capture is not yet implemented :(`
[2024-10-28T13:52:44Z WARN  lan_mouse::server::capture_task] input capture exited: error creating input-capture: `no backend available`

I also get the same output when launching lan-mouse on PC B.
When I launch lan-mouse on PC A, I don't get this lines in the console.

On both lan-mouse is installed through repositories

EDIT: actually I was running PC B in X11 sessions, so just ignore my comment

<!-- gh-comment-id:2441658229 --> @gnespolino commented on GitHub (Oct 28, 2024): > I'm also affected by this. > Not clear why, but 2 PC with same OS (Manjaro KDE Plasma 6) and same updates, on one of them I can't enable input capture. So what happen when I configure clients on both, is that I can move from PC A to B, but I can't go back from B to A, B being the one where input capture cannot be enabled, mouse and keyboard connected to PC A. > This is what I get in the console when I click on "Reenable" and I allow input capture: > > ``` > [2024-10-28T13:52:36Z INFO lan_mouse::server] received capture enable request > [2024-10-28T13:52:44Z WARN input_capture] input-capture-portal input capture backend unavailable: error creating input-capture-portal backend: `xdg-desktop-portal: `Portal request didn't succeed: Other`` > [2024-10-28T13:52:44Z WARN input_capture] layer-shell input capture backend unavailable: error creating layer-shell capture backend: `Could not find wayland compositor` > [2024-10-28T13:52:44Z WARN input_capture] X11 input capture backend unavailable: error creating x11 capture backend: `X11 input capture is not yet implemented :(` > [2024-10-28T13:52:44Z WARN lan_mouse::server::capture_task] input capture exited: error creating input-capture: `no backend available` > ``` > > I also get the same output when launching lan-mouse on PC B. > When I launch lan-mouse on PC A, I don't get this lines in the console. > > On both lan-mouse is installed through repositories > EDIT: actually I was running PC B in X11 sessions, so just ignore my comment
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
attach-dialog-to-window
windows-msi-installer
config-watcher
fix-ci
update-cachix-workflow
build-on-22.04
update-ci
save-config
macos-fix-scroll-capture
improve-connection-reliability
improve-macos-capture
macos-capture-modifier-keys
reset-double-click-on-move
fix-duplicate-key-release
emulate-double-click
fix-scrolling
prevent-authorization-request-spam
revert-scrolling-behaviour
up-deps
macos-cleanup-event-thread
macos-input-capture-fix
fix-gtk-widget-parent
fix-clippy-warnings
fix-mandatory-client-config
connection-accept-notification
change-config-syntax
rework-cli-frontend
feschber-patch-1
gtk-frontend-rework
dns-fix
remove-git-dep
encryption
fix-wl-object-recreation
macos-client-side-modifier-events
log-keypress
fix-key-repeat
cleanup-server
cleanup
extract-frontend
drop-hard-dep-shortcut-inhibit
include-commit-hash-in-version
capture-dummy-events
local-channel
lan-mouse-proto
cleanup-capture-task
derive-barrier-id-from-cursor
capture-error-handling
purge-anyhow
drop-dispatch-hack
split-crates
configurable-emulation-backend
configurable-capture-backend
hyprland-fix
fix-UB-transmute
fix-usize-assumed-8-bytes
enter-hook
display-util
fix-display-scaling
x11-event-producer
main
lan-mouse-proto-v0.2.0
lan-mouse-ipc-v0.2.0
lan-mouse-gtk-v0.2.0
lan-mouse-cli-v0.2.0
input-event-v0.3.0
input-emulation-v0.3.0
input-capture-v0.3.0
v0.10.0
v0.9.1
input-emulation-v0.2.1
v0.9.0
input-emulation-v0.2.0
input-capture-v0.2.0
input-event-v0.2.1
input-event-v0.2.0
input-emulation-v0.1.0
input-capture-v0.1.0
input-event-v0.1.0
v0.8.0
v0.7.3
v0.7.2
v0.7.0
v0.6.0
v0.5.1
v0.5.0
v0.4.0
v0.3.3
v0.3.2
v0.3.1
v0.3.0
v0.2.1
v0.2.0
v0.1.1
v0.1.1-alpha.1
0.1.1-alpha.1
Labels
Clear labels   
Xorg

   
documentation

   
enhancement

   
macos

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
windows
No labels
Xorg
documentation
enhancement
macos
pull-request
question
windows
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/lan-mouse#23
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?