Problems with vmware workstation 25H2 with 1.12.2

[Disidente]

Problems with vmware workstation 25H2 with 1.12.2

See here: https://aur.archlinux.org/packages/vmware-workstation

oct 22 16:07:11 DualXeon vmware[5669]: The program 'vmware' received an X Window System error.
                                       This probably reflects a bug in the program.
                                       The error was 'BadValue (integer parameter out of range for operation)'.
                                         (Details: serial 1985 error_code 2 request_code 135 (XKEYBOARD) minor_code 8)
                                         (Note to programmers: normally, X errors are reported asynchronously;
                                          that is, you will receive the error a while after causing it.
                                          To debug your program, run it with the GDK_SYNCHRONIZE environment
                                          variable to change this behavior. You can then get a meaningful
                                          backtrace from your debugger if you break on the gdk_x_error() function.)

Solved backing to 1.11.0

[wismill]

Do you run a Wayland or X11 session? Do you have the issue with other X11 apps?

Could you try xkbcli interactive-x11 with 1.12.2?

[XZVB12]

Do you run a Wayland or X11 session?

Wayland, KDE Plasma 6.5

Do you have the issue with other X11 apps?

No, problem only in vmware. Error occurs when a mouse cursor is captured in the VM or when the mouse cursor leaves the VM

Could you try xkbcli interactive-x11 with 1.12.2?

The last two entries appeared when creating a screenshot and I believe that they do not relate to the problem

[XZVB12]

in X11 this problem does not exist, so it is probably due to xwayland.

[Disidente]

I use Wayland with KDE.

It's strange, but my keyboard is configured in Spanish (es), but it appears as if it were in US English. If I force it to change to Spanish, the problem seems to be mitigated, but it doesn't disappear completely.

carlos@DualXeon:~$ setxkbmap -query WARNING: Running setxkbmap against an Xwayland server rules: evdev model: pc105 layout: us

setxkbmap es (It mitigates the problem, but does not eliminate it entirely.)

[wismill]

WARNING: Running setxkbmap against an Xwayland server

@Disidente setxkbmap -query does not work on Wayland[^1].

[^1]: More exactly, it does not sync with the Wayland compositor.

[wismill]

@XZVB12 if xkbcli interactive-x11 works, then it is not the libxkbcommon-x11 API that is failing in wmware but another X11 API. I have no idea which one. The implementation of the protocol is fragile.

[wismill]

Could you all dump your keymaps so that I try to reproduce it?

• via X11: xkbcomp -xkb $DISPLAY /tmp/x11.xkb
• via Wayland: xkbcli dump-keymap-wayland --raw > /tmp/wayland.xkb

There seems to be something fishy in Xwayland or its libs.

[XZVB12]

1.zip

[Disidente]

Arch_kernel_6.17.4.xkbcommon_1.11.0.zip

[m-doescode]

Can reproduce on VMWare 17.6.4 and 25H2. Same fix applied. In X11 sessions, it works fine, but in (X)Wayland, it fails in a similar manner. Also on KDE Plasma

Here are my keymaps: libxkbcommon 1.11.0-1 X11 - 1.11.0-1-x11.xkb.txt Wayland - 1.11.0-1-wl.xkb.txt libxkbcommon 1.12.2-1: X11 - 1.12.2-1-x11.xkb.txt Wayland - 1.12.2-1-wl.xkb.txt

Not sure if all these will be too helpful, but hopefully they'll be of use. Thanks for your contributions to open source!

P.S. It seems like the X11 kbd files have had no changes between the two versions, whereas the Wayland keymaps have changed significantly, with some keys removed and some replaced with hex codes

[ironashram]

omnissa horizon client (ex vmware) also crashes with the latest lib update, see the last comments on aur https://aur.archlinux.org/packages/omnissa-horizon-client

[TheRC51]

wayland.zip

[m-4984]

Same issue with vmware workstation here. For me xkbcli interactive-x11 crashes with a segmentation fault:

(gdb) bt full
#0  xkb_state_led_update_all (state=0x56343cdb1a30) at ../libxkbcommon/src/state.c:927
        idx = 3400
        led = 0x56343cdc6ff8
        __PRETTY_FUNCTION__ = <optimized out>
#1  xkb_state_update_derived (state=state@entry=0x56343cdb1a30) at ../libxkbcommon/src/state.c:1019
        wrapped = <optimized out>
#2  0x00007fbfadd0cd78 in xkb_state_update_mask (state=0x56343cdb1a30, base_mods=<optimized out>, latched_mods=<optimized out>, locked_mods=16, base_group=<optimized out>,
    latched_group=0, locked_group=0) at ../libxkbcommon/src/state.c:1308
        prev_components = {base_group = 0, latched_group = 0, locked_group = 0, group = 0, base_mods = 0, latched_mods = 0, locked_mods = 0, mods = 0, leds = <optimized out>}
#3  0x00007fbfadd43e78 in xkb_x11_state_new_from_device () from /usr/lib/libxkbcommon-x11.so.0
No symbol table info available.
#4  0x0000563415372217 in ?? ()
No symbol table info available.
#5  0x0000563415371558 in ?? ()
No symbol table info available.
#6  0x00007fbfada27675 in __libc_start_call_main (main=main@entry=0x563415371080, argc=argc@entry=1, argv=argv@entry=0x7ffc05023cb8) at ../sysdeps/nptl/libc_start_call_main.h:58
        self = <optimized out>
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -7788105940383868943, 140720392518840, 1, 140461232349184, 94781694237304, -7788105940599875599, -7823799658883229711},
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x7ffc05023cb8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#7  0x00007fbfada27729 in __libc_start_main_impl (main=0x563415371080, argc=1, argv=0x7ffc05023cb8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7ffc05023ca8) at ../csu/libc-start.c:360
No locals.
#8  0x0000563415371ef5 in ?? ()
No symbol table info available.
(gdb) info registers
rax            0x0                 0
rbx            0x0                 0
rcx            0xd48               3400
rdx            0x0                 0
rsi            0x56343cdc6ff8      94782359367672
rdi            0x0                 0
rbp            0x7ffc05023910      0x7ffc05023910
rsp            0x7ffc050238c0      0x7ffc050238c0
r8             0x4274614c          1114923340
r9             0x56343cdb1a30      94782359280176
r10            0x56343cdafa20      94782359271968
r11            0x1                 1
r12            0x1                 1
r13            0x0                 0
r14            0x0                 0
r15            0x34646f5f          878997343
rip            0x7fbfadd0756c      0x7fbfadd0756c <xkb_state_update_derived+252>
eflags         0x10283             [ CF SF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
fs_base        0x7fbfadc86740      140461231073088
gs_base        0x0                 0
(gdb) thread apply all bt

Thread 1 (Thread 0x7fbfadc86740 (LWP 225313)):
#0  xkb_state_led_update_all (state=0x56343cdb1a30) at ../libxkbcommon/src/state.c:927
#1  xkb_state_update_derived (state=state@entry=0x56343cdb1a30) at ../libxkbcommon/src/state.c:1019
#2  0x00007fbfadd0cd78 in xkb_state_update_mask (state=0x56343cdb1a30, base_mods=<optimized out>, latched_mods=<optimized out>, locked_mods=16, base_group=<optimized out>, latched_group=0, locked_group=0) at ../libxkbcommon/src/state.c:1308
#3  0x00007fbfadd43e78 in xkb_x11_state_new_from_device () from /usr/lib/libxkbcommon-x11.so.0
#4  0x0000563415372217 in ?? ()
#5  0x0000563415371558 in ?? ()
#6  0x00007fbfada27675 in __libc_start_call_main (main=main@entry=0x563415371080, argc=argc@entry=1, argv=argv@entry=0x7ffc05023cb8) at ../sysdeps/nptl/libc_start_call_main.h:58
#7  0x00007fbfada27729 in __libc_start_main_impl (main=0x563415371080, argc=1, argv=0x7ffc05023cb8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc05023ca8) at ../csu/libc-start.c:360
#8  0x0000563415371ef5 in ?? ()

(Arch [6.17.4-zen2-1-zen], Wayland, KDE Plasma [6.4])

[wismill]

@m-4984 that’s pretty bad! Could you share your keymaps?

I opened a dedicated issue at #889.

[SergioEanX]

Same issue, I solved downgrading to previous version by:

cd /tmp wget https://archive.archlinux.org/packages/l/libxkbcommon/libxkbcommon-1.11.0-1-x86_64.pkg.tar.zst wget https://archive.archlinux.org/packages/l/libxkbcommon-x11/libxkbcommon-x11-1.11.0-1-x86_64.pkg.tar.zst

sudo pacman -U libxkbcommon-1.11.0-1-x86_64.pkg.tar.zst libxkbcommon-x11-1.11.0-1-x86_64.pkg.tar.zst

OS: EndeavourOS kernel: 6.17.4-arch2-1

[wismill]

I do not have access to vmware and I cannot reproduce the error by other means. For now it seems some code specific to the app. Are you aware of similar issues with other X11 apps?

Details: serial 1985 error_code 2 request_code 135 (XKEYBOARD) minor_code 8

means that the XkbGetMap request failed, probably there. Now, since I do not have access to the code where such request is done, it is difficult to know if it a misuse of the libX11 API (I suspect XkbGetKeyTypes with wrong types count argument) or a bug in the Xorg ecosystem (or both 😅).

[XZVB12]

Are you aware of similar issues with other X11 apps?

there are not so many programs requiring xwayland, of which only vmware performs mouse and keyboard capture, so probably nothing suitable for checking

I do not have access to vmware

I could provide a package for arch-based systems if it would help.

[wismill]

I could provide a package for arch-based systems if it would help.

Thanks but I use openSUSE. Anyway I need to know where and how the xkb request is done, which is not possible with proprietary software.

Has a bug report been sent to Broadcom?

[mahkoh]

There are tools that allow you to capture X messages and print them similar to WAYLAND_DEBUG though I don't remember what they are called or if they work with extensions.

[wismill]

@mahkoh do you mean these?

[mahkoh]

Yes

[wismill]

It seems none supports XKB though.

[Disidente]

Podría proporcionar un paquete para sistemas basados ​​en arquitectura si fuera de ayuda.

Gracias, pero uso openSUSE. Necesito saber dónde y cómo se realiza la solicitud xkb, lo cual no es posible con software propietario.

¿Se ha enviado un informe de error a Broadcom?

Broadcom will wash its hands of the matter, and if it resolves anything, it will do so for 26H1 if it follows the update protocol. In other words, by June of next year.

Aren't libraries supposed to be backward compatible?

[wismill]

Broadcom will wash its hands of the matter, and if it resolves anything, it will do so for 26H1 if it follows the update protocol. In other words, by June of next year.

It seems that the best bet is to send a bug report ASAP. There is a workaround (lock to v1.11) that can be used meanwhile.

---

If vmware and the omnissa client are the only affected apps, I am afraid I cannot investigate much further.

All indicates that this is an issue with the X server/libs or a misuse of their API. I am studying the Xorg code but I have not found meaningful issues for now.

[m-doescode]

@wismill could I assist in the debugging process? In the meantime, I'll try to pin it down to a specific commit

[wismill]

@m-doescode thanks for proposing! The most useful input would be to intercept the relevant requests and responses of the X server, using maybe these tools. We are looking specifically at:

serial 1985 error_code 2 request_code 135 (XKEYBOARD) minor_code 8

from the OP. Maybe activating all Gtk debugging could help too.

The other part is not much more fun: look at the XkbGetMap request implementation:

• xserver
• libX11

[mahkoh]

This is fixed by https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/293.

[m-doescode]

Sorry, was busy for a while.

I tried building @mahkoh's fork and that seemed to do it! Now working with libxkbcommon 1.12.2-1!

I guess that means that there is nothing to be done here. If you'd still like me to investigate, please let me know.

[wismill]

@mahkoh that’s a great find!

So it a race condition? Something like:

• Server send XkbMapNotify
• Client receives it
• Server has a keymap update
• Client uses XkbRefreshKeyboardMapping(), which will send a XkbGetMap request with partial components.
• Server errors while processing the XkbGetMap request, on the now invalid partial components.
• Client does not handle the error (it could have tried to reset its keymap) and crash

[mahkoh]

Such a race would be possible but that is not what is happening. vmware effects a change in the xtest keyboard device whose map is completely independent from the xwayland map.