[BUG] Keyboard gets messed up, rolled back to 1924f2dc1a7c219b5323050a7fb27920e3a225d4

[izelnakri]

Hi @k0kubun ,

I understand that due nature of this software keyboard might get messed up once in a while, however I had few surprises about the bug I just experienced and I can verify that its something to do between the 2 last commits(maybe the last commit) as I just updated my flakes then reverted back this one to 1924f2dc1a7c219b5323050a7fb27920e3a225d4.

1924f2dc1a7c219b5323050a7fb27920e3a225d4 works, however one of the xremap patch updates after v0.10.11 has a MAJOR bug that makes the keyboard unusable on NixOS.

On a side note few days ago when dealing with k3s my home-manager/nixos conflict almost crashed down my 2 laptops(one NixOS, other Arch Linux), render them almost unusable since problem crashed the bootloader, it was something to do with cgroups with GRUB settings. I had to recover my system after like few hours of work to revert it back to life. Since problem was in GRUB it was near impossible to recover, I had to use a boot USB on arch and do several manual changes with the help of an LLM. So lately I'm getting even more picky/sensitive on having everything very stable.

I remember why I used this flake in my system nixOS flake.nix: I share my nix configuration with my Arch Linux laptop as well, so I could not simply use a NixOS module and there were no home-manager xremap module if I remember correctly. However it seems this flake is/will be an unstable approach given my keyboard messed up and it seems only way to lock it down was:

    xremap-flake.url = "github:xremap/nix-flake/1924f2dc1a7c219b5323050a7fb27920e3a225d4";

So please provide the inputs.xremap-flake.homeManagerModules.default directly on home-manager modules and update it there, so a simple nix flake update cannot mess my keyboard.

I used this flake for this, sharing it between NixOS and non-NixOS systems, however a direct home-manager module probably is a more stable approach, in addition to a direct NixOS module, without a need for this nix-flake repository:

   # in my users/izelnakri/default.nix:
   xremap = {
      watch = true;
      # mouse = true;
      withWlroots = true;
      # debug = true; # Logs everything
      yamlConfig = (builtins.readFile (builtins.toPath "${config.home.homeDirectory}/.config/home-manager/static/.config/xremap/${HOSTNAME}/config.yml"));

      # yamlConfig = builtins.readFile (builtins.toString ../../static/.config/xremap + "/" + (builtins.readFile "/proc/sys/kernel/hostname") + "/config.yml");
    };

[k0kubun]

You seem to be mixing up discussions about an xremap bug and nix-specific inquiries. Can we create a new thread on https://github.com/xremap/xremap/discussions and continue the discussion of the xremap bug there? When you do so,

I had few surprises about the bug I just experienced
one of the xremap patch updates after v0.10.11 has a MAJOR bug that makes the keyboard unusable on NixOS.

I'd like you to elaborate more on the symptom of the MAJOR bug. If the xremap process printed any logs, please include them in the new thread.

its something to do between the 2 last commits(maybe the last commit) as I just updated my flakes then reverted back this one to 1924f2d

The updates in this repository seem too coarse to identify the trigger. You're reporting a problem in your environment that happened between v0.10.12 ~ v0.10.14, but I'd like you to identify which xremap version (not an xremap/nix-flake revision) triggered the problem, since I cannot reproduce it myself. Please test xremap v0.10.13 and v0.10.12, and report the results on the new thread.

I'll reply to it when the thread is created. I'll leave this issue for flake-related discussions.

[izelnakri]

Hi again @k0kubun , I understand why you'd like to reproduce the issue and ask for specific further information, however as I mentioned this whole issue was something completely unexpected, since I merely did nixos-rebuild switch --flake .#${HOSTNAME} -L --impure, after a flake update, this goes to prove the current approach of having nix-flake repo is a bad idea, that initially seemed like a good idea, because it breaks someones keyboard. Better approach is to have both NixOS and home-manager modules in their respective repos: nixpkgs and home-manager respectively, and allow developers to change the xremap.package if they want to optionally.

Bug tracking would be difficult considering the update breaks a keyboard in odd/various ways when "ctrl" and "shift" keys involved, along then with all other keys, so I don't think I'll reproduce this issue again.

I just wanted to point out there is a bug(I could do a better bug report I know) and this bug experience I had, tells me nix-flake repo is a bad idea. Thank you for taking the time.

[k0kubun]

Feel free to keep discussing the best way to support Nix in this issue. But please refrain from pinging me in every reply since I'm not the maintainer of the Nix integration. Each supported platform has a different owner since they know better about it than me.

I didn't ask you to test v0.10.12 or v0.10.13 using the nix-flake. Download pre-built binaries and run them on your terminal. If you can't, just report what you already know to https://github.com/xremap/xremap/discussions, using the information about xremap versions/revisions (not the nix-flake revisions). I'm saying this is not an appropriate place to discuss bugs in the xremap itself.

[VTimofeenko]

I just wanted to point out there is a bug(I could do a better bug report I know) and this bug experience I had, tells me nix-flake repo is a bad idea.

This bug report is indeed not very actionable. Without a minimally reproducible example it would be nigh impossible to isolate the issue. If you are tracking your configuration you could bisect the changes and run your configuration in a VM, but that is getting outside the scope of this discussion.

Longer term there are plans to mirror modules into nixpkgs/home-manager but the development has been a bit slow.

You are free to use the nixpkgs version of xremap and inline modules from this repository in your configuration. The xremap flags/runtime requirements have not changed in a while.