System details
- Omarchy 4.0.1-1, Hyprland 0.56.2, libxkbcommon 1.13.2-1, steam 1.0.0.87-3
- AMD Ryzen 7 7800X3D, NVIDIA RTX 4090 (+ Raphael iGPU), Wayland/Hyprland, fcitx5 via
omarchy-fcitx5.service
What's wrong
install/user/xcompose.sh writes ~/.XCompose with an absolute include into the packaged tree:
tee ~/.XCompose >/dev/null <<EOF
# Run omarchy-restart-xcompose to apply changes
# Include fast emoji access
include "/usr/share/omarchy/default/xcompose"
...
EOF
Steam runs games inside pressure-vessel, a container with its own /usr. $HOME is bind-mounted into it, so the container reads ~/.XCompose — but /usr/share/omarchy does not exist there, so the include cannot resolve.
A failed include does not degrade gracefully. It aborts the whole compose table:
$ xkbcli compile-compose --file /tmp/bad.compose
xkbcommon: ERROR: (unknown file):1:9: failed to open included Compose file "/usr/share/omarchy/does-not-exist"
xkbcommon: ERROR: (unknown file):1:9: failed to parse file
ERROR: Couldn't create compose from file: /tmp/bad.compose
$ echo $?
1
So inside Steam and every Proton game, no compose sequence works — not the Omarchy emoji shortcuts, not the identity macros, not the %L locale defaults. Each affected process also logs the failure to the journal:
steam[80717]: xkbcommon: ERROR: /home/<user>/.XCompose:4:9: failed to open included Compose file
"/usr/share/omarchy/default/xcompose": No such file or directory
steam[80717]: xkbcommon: ERROR: /home/<user>/.XCompose:4:9: failed to parse file
Confirmed the container genuinely cannot see the path, while it can see the file that references it:
$ ls /proc/$(pgrep -f SomeGame.exe)/root/usr/share/omarchy/default/xcompose
ls: cannot access '...': No such file or directory
$ ls /proc/$(pgrep -f SomeGame.exe)/root/home/<user>/.XCompose
-rw-r--r-- 1 <user> <user> 232 Aug 30 15:18 /proc/.../.XCompose
The same reasoning applies to any sandboxed app that sees $HOME but not the host /usr — Flatpaks, for instance — though I only verified Steam/pressure-vessel.
This is a regression from Omarchy 3
Per #8173, Omarchy 3 wrote:
include "%H/.local/share/omarchy/default/xcompose"
%H expands to $HOME, which is bind-mounted into the container, so the Omarchy 3 form resolved correctly inside Steam. Moving the include to an absolute /usr/share/omarchy path is what broke it.
Worth flagging against #8175, which proposes repointing ~/.XCompose at the packaged tree to fix the quattro upgrade path: as written that would give upgraded installs the same absolute include, and with it this bug.
Steps to reproduce
- Fresh Omarchy 4 install (or any install whose
~/.XCompose has the absolute include).
- Launch any Steam game, native or Proton.
- Try a compose sequence in-game, e.g. CapsLock
m s. Nothing is produced.
journalctl --user -b | grep xkbcommon shows the parse errors above.
Suggested fix
Make the include home-relative so it resolves inside containers, writing a copy into $HOME at install time:
cp /usr/share/omarchy/default/xcompose ~/.XCompose.omarchy
# in ~/.XCompose:
include "%H/.XCompose.omarchy"
That keeps the packaged file authoritative at install/update time while leaving ~/.XCompose self-contained from a container's point of view. It needs a re-sync step on update, which the current absolute include avoids — so if keeping the packaged path is preferred, the alternative is to accept that compose is simply unavailable in sandboxed apps and drop the include from the generated file rather than emit one that fails to parse.
Note
I found this while chasing an unrelated missing-keyboard-input problem in a Proton game. Fixing this did not resolve that, and I want to be clear I have no evidence the broken include causes loss of key input — the verified impact is dead compose sequences plus journal error spam in every Steam/Proton process.
System details
omarchy-fcitx5.serviceWhat's wrong
install/user/xcompose.shwrites~/.XComposewith an absolute include into the packaged tree:Steam runs games inside pressure-vessel, a container with its own
/usr.$HOMEis bind-mounted into it, so the container reads~/.XCompose— but/usr/share/omarchydoes not exist there, so the include cannot resolve.A failed include does not degrade gracefully. It aborts the whole compose table:
So inside Steam and every Proton game, no compose sequence works — not the Omarchy emoji shortcuts, not the identity macros, not the
%Llocale defaults. Each affected process also logs the failure to the journal:Confirmed the container genuinely cannot see the path, while it can see the file that references it:
The same reasoning applies to any sandboxed app that sees
$HOMEbut not the host/usr— Flatpaks, for instance — though I only verified Steam/pressure-vessel.This is a regression from Omarchy 3
Per #8173, Omarchy 3 wrote:
%Hexpands to$HOME, which is bind-mounted into the container, so the Omarchy 3 form resolved correctly inside Steam. Moving the include to an absolute/usr/share/omarchypath is what broke it.Worth flagging against #8175, which proposes repointing
~/.XComposeat the packaged tree to fix the quattro upgrade path: as written that would give upgraded installs the same absolute include, and with it this bug.Steps to reproduce
~/.XComposehas the absolute include).ms. Nothing is produced.journalctl --user -b | grep xkbcommonshows the parse errors above.Suggested fix
Make the include home-relative so it resolves inside containers, writing a copy into
$HOMEat install time:That keeps the packaged file authoritative at install/update time while leaving
~/.XComposeself-contained from a container's point of view. It needs a re-sync step on update, which the current absolute include avoids — so if keeping the packaged path is preferred, the alternative is to accept that compose is simply unavailable in sandboxed apps and drop the include from the generated file rather than emit one that fails to parse.Note
I found this while chasing an unrelated missing-keyboard-input problem in a Proton game. Fixing this did not resolve that, and I want to be clear I have no evidence the broken include causes loss of key input — the verified impact is dead compose sequences plus journal error spam in every Steam/Proton process.