QT6 programs fail when using a custom keyboard layout

[expipiplus1]

Describe the bug

For example: anki doesn't respect XKB_CONFIG_ROOT

Steps To Reproduce

• Add a layout to xserver.extraLayouts
• Use that layout with xserver.layout
• Build and run anki
• Observe that it doesn't look in the correct $XKB_CONFIG_ROOT for your layout:

❯ echo $XKB_CONFIG_ROOT
/nix/store/33x74vs3ykb3xs1442r8yg1921fy329h-xkeyboard-config-2.33/etc/X11/xkb

~/src/nixpkgs on nixos-unstable [nix-shell]
❯ anki
Running with temporary Qt5 compatibility shims.
Run with DISABLE_QT5_COMPAT=1 to confirm compatibility with Qt6.
Preparing to run...
Qt warning: In /nix/store/4p8jsn41v70p3wblmcmkhwzwmg8s821i-qgnomeplatform-0.8.4/lib/qt-5.15.8/plugins/platformthemes/libqgnomeplatformtheme.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
Qt warning: In /nix/store/ngj9sch1rfxc6d4mdki84p9mss84sxkn-adwaita-qt-1.4.1/lib/qt-5.15.8/plugins/styles/adwaita.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
Qt info:

GL Type: desktop
Surface Type: OpenGL
Surface Profile: CompatibilityProfile
Surface Version: 4.6
QSG RHI Backend: OpenGL
Using Supported QSG Backend: yes
Using Software Dynamic GL: no
Using Multithreaded OpenGL: yes

Init Parameters:
  *  application-name Anki
  *  browser-subprocess-path /nix/store/i8ppshlwyxjqn8im23wsgbry35dryyrs-qtwebengine-6.4.3/libexec/QtWebEngineProcess
  *  create-default-gl-context
  *  disable-features ConsolidatedMovementXY,InstalledApp,BackgroundFetch,WebOTP,WebPayments,WebUSB,PictureInPicture
  *  disable-setuid-sandbox
  *  disable-speech-api
  *  enable-features NetworkServiceInProcess,TracingServiceInProcess
  *  enable-threaded-compositing
  *  in-process-gpu
  *  use-gl desktop

xkbcommon: ERROR: Couldn't find file "symbols/fc660c" in include paths
xkbcommon: ERROR: 1 include paths searched:
xkbcommon: ERROR:       /nix/store/18kg67dfchk2l7ni9i0hrpbdspbxlrzw-xkeyboard-config-2.33/share/X11/xkb
xkbcommon: ERROR: Abandoning symbols file "(unnamed)"
xkbcommon: ERROR: Failed to compile xkb_symbols
xkbcommon: ERROR: Failed to compile keymap
Starting main loop...
[282321:282350:0416/224135.195895:FATAL:xkb_keyboard_layout_engine.cc(652)] Keymap file failed to load: fc660c
#0 0x7f3a6f8fea19 base::debug::CollectStackTrace()
#1 0x7f3a6f851306 base::debug::StackTrace::StackTrace()
#2 0x7f3a6f84232b logging::LogMessage::~LogMessage()
#3 0x7f3a70575f8e ui::(anonymous namespace)::LoadKeymap()
#4 0x7f3a70573ff6 base::internal::Invoker<>::RunOnce()
#5 0x7f3a6f8b455a base::TaskAnnotator::RunTaskImpl()
#6 0x7f3a6f8e4043 _ZN4base13TaskAnnotator7RunTaskIJZNS_8internal11TaskTracker11RunTaskImplERNS2_4TaskERKNS_10TaskTraitsEPNS2_10TaskSourceERKNS_13SequenceTokenEEUlRN8perfetto12EventContextEE_EEEvNSE_12StaticStringERNS_11PendingTaskEDpOT_.constprop.0
#7 0x7f3a6f8e468b base::internal::TaskTracker::RunContinueOnShutdown()
#8 0x7f3a6f8e480e base::internal::TaskTracker::RunTask()
#9 0x7f3a6f91bcd8 base::internal::TaskTrackerPosix::RunTask()
#10 0x7f3a6f8dfca1 base::internal::TaskTracker::RunAndPopNextTask()
#11 0x7f3a6f8ef39e base::internal::WorkerThread::RunWorker()
#12 0x7f3a6f8efb7d base::internal::WorkerThread::RunPooledWorker()
#13 0x7f3a6f91beeb base::(anonymous namespace)::ThreadFunc()
#14 0x7f3a8d29fe24 start_thread
#15 0x7f3a8d3219b0 __clone3
Task trace:
#0 0x7f3a705751e6 ui::XkbKeyboardLayoutEngine::SetCurrentLayoutByNameWithCallback()

[1]    282321 trace trap (core dumped)  anki

Expected behavior

Anki starts (and uses the correct layout)

Notify maintainers

@oxij @Profpatsch @euank

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.2.2, NixOS, 23.05 (Stoat), 23.05pre461539.c90c4025bb6`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.3`
 - channels(root): `"nixos"`
 - nixpkgs: `/home/e/src/nixpkgs`

[ajgrf]

I ran into this issue a few days ago as well, and worked around it by remapping my keyboard with kanata instead of xkb. It seems to affect all Qt 6 apps, not just Anki, and only at startup. (So if you change the layout with setxkbmap us before starting Anki, then change back to your custom layout after it's running, Anki will use the custom layout correctly.)

[apfelkuchen6]

I can't reproduce this on my machine, but the code causing this appears to be https://invent.kde.org/qt/qt/qtwebengine-chromium/-/blob/22fec96c83014753f8d4d709dad25902cafa1a75/chromium/ui/events/ozone/layout/xkb/xkb_keyboard_layout_engine.cc#L641 (we of course patch the path), which is (only?) called from https://invent.kde.org/qt/qt/qtwebengine-chromium/-/blob/22fec96c83014753f8d4d709dad25902cafa1a75/chromium/ui/events/ozone/layout/xkb/xkb_keyboard_layout_engine.cc#L700 (the defined(PLATFORM_QT) is not there in upstream chromium, so this is unreachable in chromium?).

I imagine the correct thing to do is replace the path with getenv("XKB_CONFIG_ROOT") if set when the legacy display server is used and just use XKB_CONTEXT_NO_FLAGS instead of XKB_CONTEXT_NO_DEFAULT_INCLUDES otherwise. The reason why they remove the default includes is probably to match X's behaviour. X doesn't support xkb overlays (and doesn't care about XKB_CONFIG_ROOT, we just set the environment variable to the same directory we pass to X), it only reads the xkbmaps from a single directory, usually /usr/share/X11/xkb.

I'm not sure I want to know why chromium/qtwebengine reads keyboard layouts from disk.

Edit: I think also using XKB_CONTEXT_NO_FLAGS for X11 should also be fine since XKB_CONFIG_ROOT has higher precedence than the user and system xkb trees in ~/.config/xkb and /etc/xkb and definitely should contain the configured layout, so the thing I was worried about (libxkbcommon finding another file than X11) cannot happen unless the user manually changes the value of XKB_CONFIG_ROOT (but then the solution I suggested also wouldn't work).

[sersorrel]

This is definitely not limited to Anki, I see a similar thing with Calibre when trying to open a book:

$ calibre
xkbcommon: ERROR: Couldn't process include statement for 'gb(qw0rty)'
xkbcommon: ERROR: Abandoning symbols file "(unnamed)"
xkbcommon: ERROR: Failed to compile xkb_symbols
xkbcommon: ERROR: Failed to compile keymap
[1014028:1014052:0417/142531.477515:FATAL:xkb_keyboard_layout_engine.cc(652)] Keymap file failed to load: gb-qw0rty
#0 0x7f0f3ecfea19 base::debug::CollectStackTrace()
#1 0x7f0f3ec51306 base::debug::StackTrace::StackTrace()
#2 0x7f0f3ec4232b logging::LogMessage::~LogMessage()
#3 0x7f0f3f975f8e ui::(anonymous namespace)::LoadKeymap()
#4 0x7f0f3f973ff6 base::internal::Invoker<>::RunOnce()
#5 0x7f0f3ecb455a base::TaskAnnotator::RunTaskImpl()
#6 0x7f0f3ece4043 _ZN4base13TaskAnnotator7RunTaskIJZNS_8internal11TaskTracker11RunTaskImplERNS2_4TaskERKNS_10TaskTraitsEPNS2_10TaskSourceERKNS_13SequenceTokenEEUlRN8perfetto12EventContextEE_EEEvNSE_12StaticStringERNS_11PendingTaskEDpOT_.constprop.0
#7 0x7f0f3ece468b base::internal::TaskTracker::RunContinueOnShutdown()
#8 0x7f0f3ece480e base::internal::TaskTracker::RunTask()
#9 0x7f0f3ed1bcd8 base::internal::TaskTrackerPosix::RunTask()
#10 0x7f0f3ecdfca1 base::internal::TaskTracker::RunAndPopNextTask()
#11 0x7f0f3ecef39e base::internal::WorkerThread::RunWorker()
#12 0x7f0f3ecefb7d base::internal::WorkerThread::RunPooledWorker()
#13 0x7f0f3ed1beeb base::(anonymous namespace)::ThreadFunc()
#14 0x7f0f5b09fe24 start_thread
#15 0x7f0f5b1219b0 __clone3
Task trace:
#0 0x7f0f3f9751e6 ui::XkbKeyboardLayoutEngine::SetCurrentLayoutByNameWithCallback()

[nomeata]

Also observing it with Calibre’s ebook-viewer. But it must be a regression, I have had a custom keyboard layout for a while, and this just started being a problem (on 22.11).

[sersorrel]

"on 22.11" is probably pretty key, I just built 855fb68 (as "a random commit on master from a month or so ago") and ebook-viewer still crashes on launch. I'll try to go further back in history if I have time...

[euank]

For ebook-viewer, I figured it was worth seeing if it starting to fail corresponds with it switching to qt6.
Commit da6eaf2 is good (the last commit it's qt5) and works fine.

It fails to launch in the commit that switches to qt6 for another reason, but a commit soon after 3303cf2 exhibits the bug described in this issue (that's the first commit after the qt6 upgrade with qtwebengine cached, and I don't feel like compiling webengine right now).

I think it's safe to say calibre's ebook-viewer has been failing in this way ever since it was upgraded to qt6. My guess would be that qt6 in nixpkgs has had this problem the entire time.

For anyone else who wants to poke at this, the repro I used for this is here; I just plugged the above nixpkgs commits into the nixpkgs input to test em.

[euank]

@apfelkuchen6 thank you for linking the relevant code, and for the suggestion for a patch here!

I applied something pretty close to what you suggested, and it seems to fix the crash, so I put up a PR over here: #227077

If anyone else on this issue wants to try that patch, it'd be welcome... just be warned that building qtwebengine will take a while, so you know, be prepared for that.

[euank]

This should be fixed on nixpkgs-unstable now!

I'm happy to backport it to 22.11 as well if anyone wants to advocate for that (I'd just do it without asking, but I feel like I'd end up compiling qt6 to verify the backport works, which is a lot of cpu cycles to burn).

[expipiplus1]

Thank you, @euank!

[euank]

I didn't backport the patch, but we waited long enough that 23.05 is now the stable release :D

Closing as fixed!