systemd support for wayland systems

[Kommynct]

The only good way to log characters on linux wayland systems is by using systemd in the same way as kanata/keyd and others do.

This would also work for x11 so it's just a better way of doing things all around linux-side.

[Raymo111]

@Kommynct the shared upstream library is xslendix/libvinput that is used to do input capture, you should file this issue there instead.

[xslendix]

@Raymo111 it is on Nexus to create such systemd service. It makes literally no sense for a library to run as a daemon. You could have a systemd user service though that starts with a desktop target.

[Raymo111]

@xslendix they said "best way to log characters", I'm not sure what they want.

@Kommynct can you clarify what you want?

[xslendix]

@xslendix they said "best way to log characters", I'm not sure what they want.

Yes which is literally the whole point of Nexus. You can have a systemd service that just executes Nexus. That's literally all there is to it.

[Unit]
Description=Nexus

[Service]
ExecStart=/path/to/nexus
Restart=always
RestartSec=3

[Install]
WantedBy=graphical-session.target

[Kommynct]

it's incorrect that that's all there is to it, really.

Nexus is meant to be used to log character entry to find lists of most commonly used words, as the note in the readme says, it lacks wayland compatibility, the workaround is to enable xwayland and enable a setting that is a massive security risk, and doesn't exist as a result on most compositors.

The only way to get full wayland compatibility (no xwayland) working properly is a system service, I want this working on all wayland systems instead of just kde with a major security risk enabled.

[Raymo111]

The only way to get full wayland compatibility (no xwayland) working properly is a system service

Can you elaborate on this?

[Kommynct]

https://github.com/jtroo/kanata

https://github.com/rvaiya/keyd

^^these work independently of X and wayland, they allow remapping your keyboards by creating a virtual input device, something very similar could be used here to get rid of the dependency on X. They even work without a GUI at all in the tty.

You have two options here, you either use root and launch them every time that way, or you create a systemd service, which avoids the necessity of calling sudo/whatever every time.

considering X.org is actively being phased out, for linux support on most desktops these days, there is no alternative to doing it this way.

as for why this is necessary, wayland doesn't allow programs to snoop on keyboard inputs, to avoid keyloggers running unpriviledged clients, the workaround listed on your page opens up a major security flaw, it makes it so that any xwayland client can read whatever you're typing, this would be much much more secure and work absolutely everywhere instead of only kde (and who knows if kde will even keep this horrible workaround).

I do use kanata currently, and would like this to be compatible with it, however. I don't know if that's doable, no idea if this would interfere.

[xslendix]

@Raymo111 From what I understand, this would require reworking how the structure of the application works, having it run as some sort of server that continuously runs in the background. The GUI can stay there as it is currently, but instead of working with logic it interfaces with the server's API. For example you could have an HTTP server that has a /log/begin or /log/status or /log/words?page=1 etc

[Raymo111]

@Raymo111 From what I understand, this would require reworking how the structure of the application works, having it run as some sort of server that continuously runs in the background. The GUI can stay there as it is currently, but instead of working with logic it interfaces with the server's API. For example you could have an HTTP server that has a /log/begin or /log/status or /log/words?page=1 etc

I don't think this has anything to do with the GUI, since there's a fully featured CLI. Didn't you tell me at one point that with the uinput rewrite, libvinput can be used in TTYs?

[xslendix]

Didn't you tell me at one point that with the uinput rewrite, libvinput can be used in TTYs?

This is still true.

I don't think this has anything to do with the GUI, since there's a fully featured CLI.

It does, those need to be switched from calling the logger logic directly to using the API of a new Nexus daemon. You could have the server start and have the lifetime of the interface though and it would be the same as it is now. This ensures keys are captured if you want even at boot time, where the rest of services are started. I think this is what OP wants.

[Kommynct]

To be clear, I do want that, but I also want to ensure there's no xwayland dependency whatsoever, due to, again, the massive security implications.

[xslendix]

I also want to ensure there's no xwayland dependency whatsoever.

xwayland is just a way to interface with X11 applications on Wayland compositors. libvinput, and Nexus need to support X11 as well, so support for it cannot be removed. If there's no x11 session, libvinput shrimply just uses the uinput kernel API.

[Kommynct]

there being no xwayland dependency doesn't mean remove support for x11, it just means on wayland, if there is no xwayland at all, it should still work.

However, i'm fairly certain they actually do not need to support x11, for the same reason keyd and kanata do not need to support x11, they use lower-level interception than either wayland or x11 and as a result do not depend on them at all. Again, doing things this way is more secure and will work on everything, even like, arcan.

[Raymo111]

there being no xwayland dependency doesn't mean remove support for x11, it just means on wayland, if there is no xwayland at all, it should still work.

Currently on Wayland, nexus works out of the box, with no need for XWayland. I don't think anything else is needed.

[Kommynct]

this section of the readme should be updated, then, i'll submit a PR removing it if you're fine with that.