-
-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clients Not Activated in Daemonized Mode #68
Comments
Yeah, currently all clients are deactivated by default on startup. I was planning to add an |
Sounds good. For some context, I have already implemented a systemd unit to handle automatic startup, and this issue is the last obstacle to having a functional setup that can start automatically in a systemd setup. I'd be willing to look into implementing it myself if it helps, though I don't have a lot of time during the week at the moment due to my own backlog of work. Partially depends on how soon you would consider looking into this. Not to rush you or hijack your own prioritization, of course. I do appreciate the effort you've already put into the project thus far: the fact that lan-mouse already works with both wlroots and kwin_wayland makes it actually usable with my current setup. |
I have partially implemented this in #70 . Activating on startup does work but I'm having some issues with the gtk frontend that I need to figure out. |
I wanted to fix this for some time now so thank you for giving me a good reason! Basically the gtk switch does not want to activate when a client is activated without pressing the switch. |
Clients can now be enabled on startup with |
Environment info
Version: 0.5.0 (release)
Clients: Arch Linux (x2)
There appears to be an issue where starting lan-mouse in daemonized mode does not automatically activate clients that are defined in config.toml. Lan-mouse works properly when running with either the cli or gtk frontends and explicitly activating the connections, hence the suspicion that the daemonized mode is simply not activating client profiles.
Proposals
Short-term fix
Automatically starting all client profiles when running in daemonized mode seems like a reasonable short-term solution. If this is already the expected behaviour, I can assist with diagnostics as necessary.
Enhancement
It may be useful to have an "activate" key in the client configuration specification to specify which clients should be activated automatically during startup, as this would be useful even in non-daemonized cases. A similar global config key could be useful for controlling whether all profiles are activated at startup.
This can split into a separate issue if you would rather track the enhancement request separately
Annotated Log (Sway client)
[asmith@host2 ~]$ lan-mouse -d
[2024-01-11T03:17:10Z INFO lan_mouse::config] using config: "/home/asmith/.config/lan-mouse/config.toml"
[2024-01-11T03:17:10Z DEBUG lan_mouse] Config { frontend: Cli, port: 4242, clients: [(Client { host_name: Some("host1"), ips: None, port: Some(4242) }, Top)], daemon: true }
[2024-01-11T03:17:10Z INFO lan_mouse] Press Ctrl+Alt+Shift+Super to release the mouse
[2024-01-11T03:17:10Z DEBUG lan_mouse::frontend] remove socket: "/run/user/1000/lan-mouse-socket.sock"
[2024-01-11T03:17:10Z INFO lan_mouse::consumer] using wlroots event consumer
[2024-01-11T03:17:10Z INFO lan_mouse::producer] libei event producer not available: not implemented
[2024-01-11T03:17:10Z DEBUG lan_mouse::backend::producer::wayland] ==============> requested registry
[2024-01-11T03:17:10Z DEBUG lan_mouse::backend::producer::wayland] wl_output global
[2024-01-11T03:17:10Z DEBUG lan_mouse::backend::producer::wayland] ==============> roundtrip 1 done
[2024-01-11T03:17:10Z DEBUG lan_mouse::backend::producer::wayland] xdg-output - Name { name: "eDP-1" }
[2024-01-11T03:17:10Z DEBUG lan_mouse::backend::producer::wayland] xdg-output - Description { description: "LG Display 0x0719 0x000037A1 (eDP-1)" }
[2024-01-11T03:17:10Z DEBUG lan_mouse::backend::producer::wayland] xdg-output - LogicalPosition { x: 0, y: 0 }
[2024-01-11T03:17:10Z DEBUG lan_mouse::backend::producer::wayland] xdg-output - LogicalSize { width: 1440, height: 960 }
[2024-01-11T03:17:10Z DEBUG lan_mouse::backend::producer::wayland] ==============> roundtrip 2 done
[2024-01-11T03:17:10Z DEBUG lan_mouse::backend::producer::wayland] OutputInfo {
name: "eDP-1",
position: (0,0,),
size: (1440,960,),
}
[2024-01-11T03:17:10Z INFO lan_mouse::producer] using layer-shell event producer
[2024-01-11T03:17:10Z INFO lan_mouse::server] adding client [top]host1 @ {}
[2024-01-11T03:17:10Z DEBUG lan_mouse::server] add_client 0
[2024-01-11T03:17:10Z DEBUG lan_mouse::frontend] json: {"NotifyClientCreate":[0,"host1",4242,"Top"]}, len: 55
[2024-01-11T03:17:10Z INFO lan_mouse::dns] resolving host1 ...
[2024-01-11T03:17:10Z INFO lan_mouse::dns] host1: adding ip 192.168.0.16
<Attempt to move mouse from host 1 into host 2>
[2024-01-11T03:17:12Z WARN lan_mouse::server] ignoring events from client 192.168.0.16:4242
The text was updated successfully, but these errors were encountered: