FS#65730 - [xorg-xkbcomp] Could not resolve keysym XF86FullScreen
Attached to Project:
Arch Linux
Opened by Hugo Hromic (hhromic) - Saturday, 07 March 2020, 12:32 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 17 March 2020, 09:26 GMT
Opened by Hugo Hromic (hhromic) - Saturday, 07 March 2020, 12:32 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 17 March 2020, 09:26 GMT
|
Details
Description:
I'm receiving internal errors caused by xkbcomp not able to find newer symbols: For example, using xvfb: # xvfb-run -e /dev/stderr true The XKEYBOARD keymap compiler (xkbcomp) reports: > Internal error: Could not resolve keysym XF86FullScreen Errors from xkbcomp are not fatal to the X server Additional info: * package version(s) xorg-server-xvfb 1.20.7-1 xorg-xkbcomp 1.4.3-1 xkeyboard-config 2.29-1 xorgproto 2019.2-2 * config and/or log files etc. * link to upstream bug report, if any Similar to previous bug: https://bugs.archlinux.org/task/62449 Where it is suggested to recompile xkbcomp after updating xorgproto and xkeyboard-config. Steps to reproduce: Start any command using xvfb with stderr enabled. For example: xvfb-run -e /dev/stderr true |
This task depends upon
[1] https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/28bb029b49bfb29c34467f6ba70bd912408d0728
[2] https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/11
The `xkeyboard-config` package introduced the new keysym `XF86FullScreen` in the recent `2.29` version via this merge request: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/d121a0aa5cc1de22778e2ac39929fecbe5b50623
However this symbol has not been yet added to the `libxkbcommon` package, more precisely to the file `/usr/include/xkbcommon/xkbcommon-keysyms.h`. This because the new symbol has not been added to the `xorgproto` package.
The error is temporarily fixed by reverting `xkeyboard-config` to `2.28` because this version does not have the new keysym. The proper fix should be to add the missing symbol to `xorgproto` and `libxkbcommon` and recompile everything that depends on them.
At the time of opening I thought it was a packaging bug but after the discovery of yesterday perhaps this task can be closed as it is actually a bug in upstream.