nixpkgs/pkgs/tools/X11/xkbvalidate/default.nix

{ lib, runCommandCC, libxkbcommon }:

runCommandCC "xkbvalidate" {
  buildInputs = [ libxkbcommon ];
  meta = {
    description = "NixOS tool to validate X keyboard configuration";
    license = lib.licenses.mit;
    platforms = lib.platforms.unix;
    maintainers = [ lib.maintainers.aszlig ];
  };
} ''
  mkdir -p "$out/bin"
  $CC -std=c11 -Wall -pedantic -lxkbcommon ${./xkbvalidate.c} \
    -o "$out/bin/xkbvalidate"
''
nixos/xserver: Properly validate XKB options Checking the keyboard layout has been a long set of hurdles so far, with several attempts. Originally, the checking was introduced by @lheckemann in #23709. The initial implementation just was trying to check whether the symbols/ directory contained the layout name. Unfortunately, that wasn't enough and keyboard variants weren't recognized, so if you set layout to eg. "dvorak" it will fail with an error (#25526). So my improvement on that was to use sed to filter rules/base.lst and match the layout against that. I fucked up twice with this, first because layout can be a comma-separated list which I didn't account for and second because I ran into a Nix issue (NixOS/nix#1426). After fixing this, it still wasn't enough (and this is btw. what localectl also does), because we were only matching rules but not symbols, so using "eu" as a layout won't work either. I decided now it's the time to actually use libxkbcommon to try compiling the keyboard options and see whether it succeeds. This comes in the form of a helper tool called xkbvalidate. IMHO this approach is a lot less error-prone and we can be sure that we don't forget about anything because that's what the X server itself uses to compile the keymap. Another advantage of this is that we now validate the full set of XKB options rather than just the layout. Tested this against a variety of wrong and correct keyboard configurations and against the "keymap" NixOS VM tests. Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @lheckemann, @peti, @7c6f434c, @tohl, @vcunat, @lluchs Fixes: #27597 2017-07-28 11:36:48 +01:00			`{ lib, runCommandCC, libxkbcommon }:`

			`runCommandCC "xkbvalidate" {`
			`buildInputs = [ libxkbcommon ];`
			`meta = {`
			`description = "NixOS tool to validate X keyboard configuration";`
			`license = lib.licenses.mit;`
xkbvalidate: Don't rely on GNU extensions The only reason why I was using _GNU_SOURCE was because of vasprintf(), so getting rid of that extension should make the source way more portable. When using vsnprintf() with a null pointer for the output buffer and a size of 0, I wasn't quite sure whether this would be undefined behaviour, so I looked it up in the C11 standard. In section 7.21.6.5, it explicitly mentions this case, so we're lucky: If n is zero, nothing is written, and s may be a null pointer. Additionally, section 7.21.6.12 writes the following about vsnprintf(): The vsnprintf function does not invoke the va_end macro. So to be sure to avoid undefined behaviour I subsequently added the corresponding va_end() calls. With this, the platforms attribute is now "unix", because the program should now even run on OS X, even though it usually wouldn't be needed. Signed-off-by: aszlig <aszlig@nix.build> 2019-08-14 23:06:51 +01:00			`platforms = lib.platforms.unix;`
nixos/xserver: Properly validate XKB options Checking the keyboard layout has been a long set of hurdles so far, with several attempts. Originally, the checking was introduced by @lheckemann in #23709. The initial implementation just was trying to check whether the symbols/ directory contained the layout name. Unfortunately, that wasn't enough and keyboard variants weren't recognized, so if you set layout to eg. "dvorak" it will fail with an error (#25526). So my improvement on that was to use sed to filter rules/base.lst and match the layout against that. I fucked up twice with this, first because layout can be a comma-separated list which I didn't account for and second because I ran into a Nix issue (NixOS/nix#1426). After fixing this, it still wasn't enough (and this is btw. what localectl also does), because we were only matching rules but not symbols, so using "eu" as a layout won't work either. I decided now it's the time to actually use libxkbcommon to try compiling the keyboard options and see whether it succeeds. This comes in the form of a helper tool called xkbvalidate. IMHO this approach is a lot less error-prone and we can be sure that we don't forget about anything because that's what the X server itself uses to compile the keymap. Another advantage of this is that we now validate the full set of XKB options rather than just the layout. Tested this against a variety of wrong and correct keyboard configurations and against the "keymap" NixOS VM tests. Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @lheckemann, @peti, @7c6f434c, @tohl, @vcunat, @lluchs Fixes: #27597 2017-07-28 11:36:48 +01:00			`maintainers = [ lib.maintainers.aszlig ];`
			`};`
			`} ''`
			`mkdir -p "$out/bin"`
xkbvalidate: Don't rely on GNU extensions The only reason why I was using _GNU_SOURCE was because of vasprintf(), so getting rid of that extension should make the source way more portable. When using vsnprintf() with a null pointer for the output buffer and a size of 0, I wasn't quite sure whether this would be undefined behaviour, so I looked it up in the C11 standard. In section 7.21.6.5, it explicitly mentions this case, so we're lucky: If n is zero, nothing is written, and s may be a null pointer. Additionally, section 7.21.6.12 writes the following about vsnprintf(): The vsnprintf function does not invoke the va_end macro. So to be sure to avoid undefined behaviour I subsequently added the corresponding va_end() calls. With this, the platforms attribute is now "unix", because the program should now even run on OS X, even though it usually wouldn't be needed. Signed-off-by: aszlig <aszlig@nix.build> 2019-08-14 23:06:51 +01:00			`$CC -std=c11 -Wall -pedantic -lxkbcommon ${./xkbvalidate.c} \`
xkbvalidate: Rename output binary to xkbvalidate So far, the output binary has been just "validate", which is quite a very generic name and doesn't match the package name. Even though I highly doubt that this program will ever be used outside of NixOS modules, it's nevertheless less confusing to have a consistent naming. Signed-off-by: aszlig <aszlig@nix.build> 2019-08-15 00:11:32 +01:00			`-o "$out/bin/xkbvalidate"`
nixos/xserver: Properly validate XKB options Checking the keyboard layout has been a long set of hurdles so far, with several attempts. Originally, the checking was introduced by @lheckemann in #23709. The initial implementation just was trying to check whether the symbols/ directory contained the layout name. Unfortunately, that wasn't enough and keyboard variants weren't recognized, so if you set layout to eg. "dvorak" it will fail with an error (#25526). So my improvement on that was to use sed to filter rules/base.lst and match the layout against that. I fucked up twice with this, first because layout can be a comma-separated list which I didn't account for and second because I ran into a Nix issue (NixOS/nix#1426). After fixing this, it still wasn't enough (and this is btw. what localectl also does), because we were only matching rules but not symbols, so using "eu" as a layout won't work either. I decided now it's the time to actually use libxkbcommon to try compiling the keyboard options and see whether it succeeds. This comes in the form of a helper tool called xkbvalidate. IMHO this approach is a lot less error-prone and we can be sure that we don't forget about anything because that's what the X server itself uses to compile the keymap. Another advantage of this is that we now validate the full set of XKB options rather than just the layout. Tested this against a variety of wrong and correct keyboard configurations and against the "keymap" NixOS VM tests. Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @lheckemann, @peti, @7c6f434c, @tohl, @vcunat, @lluchs Fixes: #27597 2017-07-28 11:36:48 +01:00			`''`