`setxkbmap` fails to find layout

[TheBlackBeans]

@seniorivn

  services.xserver = {
    enable = true;
    layout = "my";
    extraLayouts = {
      my = {
        description = "Custom layout file";
        languages = [ "eng" "rus" ];
        symbolsFile = ./xkb/symbols/my;
      };
    };

weird, i posted a comment in russian, anyway this is a way to add additional xkb layouts/symbols
or replace existing ones

This is not ok, because it recompiles the X server and every that depends on it on each rebuild. See the issue it causes.

---

@jtojnar

As written in Nixos builds a ton of packages instead of fetching them in the cache - #5 by jtojnar, you should not need to replace anything else other than xkeyboardconfig.

Ah, ok I didn’t see that

@jtojnar

You could try checking nix-store --query --tree /run/current-system/sw to see what pulls it in.

@TheBlackBeans

When I run nix show-derivation nixpkgs.xorg.setxkbmap , the out path points to the derivation which does not contain the bsk file.

That is to be expected as, unlike overlays, system.replaceRuntimeDependencies does not change nixpkgs packages but only replaces them in the final built system path.

If I understood right, I don’t need to run nix-store --query --tree /run/current-system/sw since the behavior of system.replaceRuntimeDependencies already explains why I do have two derivations.

---

So, I patched my snippet, and looked for the actual runtime replacement of the derivation, and found it. Actually, the derivation path of the patched derivation is in the final derivation. No problem there, it runs fine.

@futile

Does running the other setxkbmap , which does contain your new file, work?

I didn’t know you could do that, but it actually makes sense. I looked in the patched derivation tree, looking for the binary, and I understood that the final derivation configuration directory was linked to the patched derivation (which, when you think of, makes sense: if it didn’t, how the patched derivation would impact the system?).

But, if it is the case, then there should be a bsk file in /nix/store/final-setxkbmap/share/X11/xkb/symbols/. And, turns out, there is! I think when I looked for it the first time I went in the directory of the original derivation.

Whatever, if the file is in the right place, then setxkbmap should work, right? Lol.
After some debugging, I realized setxkbmap crashes even before trying to read the bsk file. Strange. So, it doesn’t even look for it. Why is that? Debug, debug, debug. Ah, so it reads X11/xkb/rules/evdev, which is supposed to contain an entry for my layout. But it doesn’t. According to this tutorial (and some others), evdev is built from X11/xkb/rules/xorg.xml or X11/xkb/rules/evdev.xml, neither of witch contains bsk. They should contain an entry that looks like

<layout>
  <configItem>
    <name> BSK </name>
    <shortDescription> ... </shortDescription>
    <description> ... </description>
  </configItem>
</layout>

Isn’t NixOS supposed to take care of that?

---

Actually, I think that this is supposed to be the role of this snippet. However, it only changes base.xml, not xorg.xml or evdev.xml. Is it a bug? Did I miss something?

EDIT: I don’t really understand why, but bsk is present in all three base.xml, evdev.xml and xorg.xml in the patched derivation, but not in the final one. Also, for a strange reason, base.xml and evdev.xml are always identical, but are not linked each other (even though in the snippet only base.xml is changed, evdev.xml also ends up being changed…). Also, I have been confused by the hash that have been changed during the build. bsk is not present in the path of the final derivation.
EDIT 2: Also, even though bsk is present in evdev.xml in the patched derivation, it is not present in evdev, which is the file setxkbmap reads, so even if I call the patched binary, it doesn’t work…