Skip to content
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

Please send help #2

Open
thepragmaticmero opened this issue Aug 30, 2024 · 7 comments
Open

Please send help #2

thepragmaticmero opened this issue Aug 30, 2024 · 7 comments

Comments

@thepragmaticmero
Copy link

I don't know what happens really, I'm scared. Sorry for the title (you could change it for something accurate when we figure out what happens), I'm really flabbergasted for what it's happening.

Distro: Fedora Silverblue 40
Plover version: 4.0.0.rc

IDK why when and how. But when I enable plover on Gnome wayland. My Paper Tape looks like this when I press a singular key slightly.
image

It starts an infinite loop of keypresses and eventually crashes after a couple of seconds, unless I disable with the right side radio toggle, I don't know what to do at this point. I ended up spending more time debugging than actually using this thing. I don't know what to do TnT please help.

Those are real keypresses by the way, it messed with my firefox wayland window. So.... what's the matter?

I've got all the premissions (yep, permissions in Silverblue) and udev rules $ cat /etc/udev/rules.d/99-plover-uinput.rules KERNEL=="uinput", GROUP="input", MODE="0660", OPTIONS+="static_node=uinput" .

@Noah765
Copy link

Noah765 commented Sep 10, 2024

I have the same problem on NixOS using the Hyprland Wayland compositor. I have logged the strokes and the output of a stroke seems to be interpreted as keyboard input, just as if I had typed it myself on the specified layout.

@LilleAila
Copy link
Owner

Hmm, i’m not sure how this is happening, looking at the code i can’t see what is causing this. You could try using my pull request openstenoproject/plover#1679 and see if that makes a difference
@Noah765 if you want an example, this is what i have in my configuration, with this as the input.

@Noah765
Copy link

Noah765 commented Sep 10, 2024

The have tried using the plover derivation you pointed out (but without any plugins), but that didn't fix the problem. After looking at your config, I noticed that you didn't set hardware.uinput.enable to true (it evaluates to false). When I try this, I get evdev.uinput.UInputError: "/dev/uinput" cannot be opened for writing, which makes sense, so I am wondering why plover isn't throwing the same exception on your end.

@LilleAila
Copy link
Owner

I think that’s because i manually added the udev rule for it, look here

@Noah765
Copy link

Noah765 commented Sep 12, 2024

My last comment was a bit stupid because I thought I knew more than I did. I apologise for that. Since it did not help this discussion, I have deleted it now. The real reason your config did not work for me is that I forgot to add myself to the input group.
Using the plover flake and the udev rule you provided, I got it to work.
However, if I create a new group and use that group for the permissions of the uinput device node (as the hardware.uinput module from nixpkgs does) then plover just completely ignores all keystrokes as if it were disabled.
Using this plugin with the configuration provided below, plover will enter the infinite output loop described in this issue, no matter if a new group or the input group is used.

The inputs I used:

inputs = {
  plover = {
    url = "github:dnaq/plover-flake";
    inputs.nixpkgs.follows = "nixpkgs";
  };
  nixpkgs-xkbcommon.url = "github:NixOS/nixpkgs/c35a5a895f2517964e3e9be3d1eb8bb8c68db629";
};

This is how I added this plugin:

home.packages = [
  (inputs.plover.packages.${pkgs.system}.default.with-plugins (ps: [
    (ps.plover-uinput.overrideAttrs (old: {
      propagatedBuildInputs = [pkgs.python311Packages.evdev inputs.nixpkgs-xkbcommon.legacyPackages.${pkgs.system}.python311Packages.xkbcommon];
    }))
  ]))
];

@LilleAila
Copy link
Owner

Thanks for providing the configuration, i’ll see if i can reproduce it. Did you encounter any problems using the version of xkbcommon that it comes with by default? Ignoring the keypresses is intended, because it’s impossible not to, but perhaps i should see if i can add a warning. This plugin is a little behind the pr, but i can see if there are changes i should backport to fix this

@Noah765
Copy link

Noah765 commented Sep 12, 2024

Without overriding xkbcommon, I had a version conflict because dnaqs flake provides the latest version (currently 1.5.1, provided here), but your plugin has a version requirement of xkbcommon<1.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants