Xwayland+Ptyxis+mc: arrow keys stop working.

[kad]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

mc -V
GNU Midnight Commander 4.8.33
Built with GLib 2.82.5
Built with S-Lang pre2.3.4-16 with terminfo database
Built with libssh2 1.11.1
With builtin editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, shell
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; uintmax_t: 64;

Operating system

Linux desk 6.18.2-1-default #1 SMP PREEMPT_DYNAMIC Fri Dec 19 10:15:01 UTC 2025 (9447271) x86_64 x86_64 x86_64 GNU/Linux

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

• openSUSE Tumbleeweed
• default install with Gnome
• use Ptyxis as terminal
• navigate over some files
• run several times commands via "somecmd" + Ctrl-Enter to paste file, Enter to execute.
• have several instances of mc running in different tabs.
• after several invocations, arrow keys stop working.

Expected behavior

Arrow keys should be working always, regardless inside X or simple console, or tmux/screen/etc..

Actual behavior

Symptoms:

• Arrow keys are navigating history in cmd line only.
• left/right are not working at all
• navigating pannels only possible with ctrl-n/ctrl-p
• Enter leads to similar as pressing Esc-Enter.
• entering menu (F9) is possible, but navigation left/right don't work. Using ctrl-N/ctrl-p allows to go up/down in menu, but selecting anything or exiting via Esc is not possible, only using hotkey letters.
• behavior continues until X session is over (closing ptyxis and all instances of mc are not enough).
• remotely logged sessions with mc in it are working fine.
• re-running mc doesn't help.
• re-running mc as XAUTHORITY= mc or DISPLAY= mc restores normal navigation behavior.
• I suspect something get screwed in underlying libraries related to detecting X session/X inputs, but wasn't able to figure out myself where it comes from.
• all other console applications are working fine inside terminal (micro, vim, gdu...)

Additional context

No response

[zyv]

Can you compile mc --without-x to prove that it has something to do with mc?

[egmontkob]

Can you compile mc --without-x to prove that it has something to do with mc?

I guess just running mc -X (a.k.a. mc --no-x11) should be sufficient.

Sounds to me like one of the modifier keys (most likely Alt) gets stuck in X11 (i.e. XWayland in our case). The terminal itself sends the correct keys (it receives correct keys because it's running natively on Wayland), but the auxiliary X11 channel falsely tells mc that a modifier is pressed, causing mc to misinterpret these keypresses.

Would be interesting to see if other XWayland apps, e.g. xterm, urxvt also misbehave (even without mc), I suspect so.

Most likely an XWayland bug.

[kad]

yeah, with mc -X it is similarly as with unsetting DISPLAY, etc. Result, it works fine. Surprisingly, mc inside xterm and rxvt works also fine. All other apps are also working fine. But, inside ptyxis and konsole, mc misbehaves.

[egmontkob]

Surprisingly, mc inside xterm and rxvt works also fine.

That's weird, not what I expected.

Well, inside xterm and rxvt, at least there's a consistent view of things: Both the terminal and mc query the same component for the pressed letter.

With native Wayland apps, like Ptyxis and Konsole, the terminal receives the keypress via one channel (directly from Wayland), whereas mc queries the modifiers via a different one (via an XWayland hop). So, if there's a bug somewhere, e.g. in XWayland, mc could see an inconsistent state.

[zyv]

With that in mind, I would close this as a non-mc bug.

[kad]

With that in mind, I would close this as a non-mc bug.

as the mc is the only app I have that is affected by that and issue visible making the mc unusable, should it be kept open to investigate which mc dependency library is reason of that fault?