bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

[Marvin Gülker]

Dear developers,

Emacs fails to recognise a Hyper key modifier sent by the Wayland
compositor. I used XKB to make the caps-lock key into the Hyper modifier
key using the method described at
<https://who-t.blogspot.com/2020/02/user-specific-xkb-configuration-part-1.html>.
Thus, I now have a file ~/.config/xkb/rules/evdev with this content:

    ! option                =       symbols
      custom:hypercaps      =       +custom(hypercaps)
    
    ! include %S/evdev

And ~/.config/xkb/symbols/custom with this content:

    partial alphanumeric_keys
    xkb_symbols "hypercaps" {
        key <CAPS> { [ Hyper_L ] };
        modifier_map Mod3 { <CAPS> };
    };

This creates a new XKB option custom:hypercaps. I run KDE Plasma, so I
enabled this new XKB option by editing ~/.config/kxkbrc so that it
contains this line in the section [Layout]:

    Options=custom:hypercaps

In case it is relevant, other than this I use a German keyboard layout
(de). Log out and log in again to have the change take effect. After
that, it can be seen in wev(1) that the KDE Wayland compositor emits
Hyper_L and maps it to to Mod3 when the former caps-lock key is pressed:

    [14:     wl_keyboard] key: serial: 4191; time: 829255; key: 66; state: 1 (pressed)
    sym: Hyper_L      (65517), utf8: ''
    [14:     wl_keyboard] modifiers: serial: 0; group: 0
    depressed: 00000020: Mod3
    latched: 00000000
    locked: 00000000
    [14:     wl_keyboard] key: serial: 4193; time: 829286; key: 66; state: 0 (released)
    sym: Hyper_L      (65517), utf8: ''
    [14:     wl_keyboard] modifiers: serial: 0; group: 0
    depressed: 00000000
    latched: 00000000
    locked: 00000000

Note how this is different from just setting the XKB option caps:hyper,
which will only make the compositor emit Hyper_L, but does not map that
one to Mod3, but rather to Mod4 (making the key effectively a Super key,
which I do not want -- I use Super to control KWin, the window manager).

Still, emacs -Q entirely fails to recognise the new Hyper key (or more
precisely: the Mod3 modifier). If I press a combination of keys
involving the caps-lock key (= Hyper_L), it simply ignores it. For
instance, pressing [CapsLock]+[A] under the above configuration should
result in Emacs signalling "H-a is undefined", but it instead inserts
only "a", revealing that no Hyper modifier is applied.

To reproduce:

1. Create ~/.config/xkb/rules/evdev and ~/.config/xkb/symbols/custom
   with the contents shown above.

2. Edit ~/.config/kxkbrc as shown above.

3. Log out and in again.

4. Launch emacs -Q. Press the caps-lock key and the A key
   simultaneously.

Expected behaviour would be the error message "H-a is undefined". Real
behaviour is the insertion of the character "a".

If I run an Emacs without PGTK enabled (that is, under XWayland) it
properly recognises the new Hyper key.

System Information:

    Operating System: Arch Linux 
    KDE Plasma Version: 5.27.7
    KDE Frameworks Version: 5.109.0
    Qt Version: 5.15.10
    Kernel Version: 6.4.12-arch1-1 (64-bit)
    Graphics Platform: Wayland
    Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
    Memory: 15.4 GiB of RAM
    Graphics Processor: Mesa Intel® UHD Graphics 620
    Manufacturer: LENOVO
    Product Name: 20L6S29E18
    System Version: ThinkPad T480

In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.17.8)
System Description: Arch Linux

Configured using:
 'configure --with-pgtk --with-native-compilation=aot --sysconfdir=/etc
 --prefix=/usr --libexecdir=/usr/lib --with-tree-sitter
 --localstatedir=/var --with-cairo --disable-build-details
 --with-harfbuzz --with-libsystemd --with-modules 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2
 -Wformat -Werror=format-security -fstack-clash-protection
 -fcf-protection -g
 -ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto'
 'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -g
 -ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 76839 6912)
 (symbols 48 7115 0)
 (strings 32 19631 2224)
 (string-bytes 1 574914)
 (vectors 16 15638)
 (vector-slots 8 327224 13701)
 (floats 8 27 46)
 (intervals 56 247 0)
 (buffers 984 11))

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kontakt@guelker.eu    | O<

bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Marvin Gülker <post+emacs@guelker.eu> writes:

> Dear developers,
>
> Emacs fails to recognise a Hyper key modifier sent by the Wayland
> compositor.

Thanks, but GDK doesn't recognize Hyper keys sent by said compositors.
This is not a bug we are capable of fixing.

bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

[Marvin Gülker]

Am Freitag, dem 08. September 2023 schrieb Po Lu:
> Marvin Gülker <post+emacs@guelker.eu> writes:
>
>> Dear developers,
>>
>> Emacs fails to recognise a Hyper key modifier sent by the Wayland
>> compositor.
>
> Thanks, but GDK doesn't recognize Hyper keys sent by said compositors.
> This is not a bug we are capable of fixing.

Should this then be forwarded to the GDK bugtracker?

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kontakt@guelker.eu    | O<

bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Marvin Gülker <post+emacs@guelker.eu> writes:

> Am Freitag, dem 08. September 2023 schrieb Po Lu:
>> Marvin Gülker <post+emacs@guelker.eu> writes:
>>
>>> Dear developers,
>>>
>>> Emacs fails to recognise a Hyper key modifier sent by the Wayland
>>> compositor.
>>
>> Thanks, but GDK doesn't recognize Hyper keys sent by said compositors.
>> This is not a bug we are capable of fixing.
>
> Should this then be forwarded to the GDK bugtracker?

It's already been reported, I think, but in any case it's improbable
that the GDK developers are still interested in introducing new features
to GDK 3.x.

bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

[Eli Zaretskii]

> Cc: 65802@debbugs.gnu.org
> Date: Fri, 08 Sep 2023 13:55:59 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Marvin Gülker <post+emacs@guelker.eu> writes:
> 
> > Am Freitag, dem 08. September 2023 schrieb Po Lu:
> >> Marvin Gülker <post+emacs@guelker.eu> writes:
> >>
> >>> Dear developers,
> >>>
> >>> Emacs fails to recognise a Hyper key modifier sent by the Wayland
> >>> compositor.
> >>
> >> Thanks, but GDK doesn't recognize Hyper keys sent by said compositors.
> >> This is not a bug we are capable of fixing.
> >
> > Should this then be forwarded to the GDK bugtracker?
> 
> It's already been reported, I think, but in any case it's improbable
> that the GDK developers are still interested in introducing new features
> to GDK 3.x.

Does this problem happen only in GTK3, and is absent from GTK4?

bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Does this problem happen only in GTK3, and is absent from GTK4?

I believe so.  However, porting from GTK3 to GTK4 is not a trivial
job...

bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

[Stefan Kangas]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Does this problem happen only in GTK3, and is absent from GTK4?
>
> I believe so.  However, porting from GTK3 to GTK4 is not a trivial
> job...

Is the hope that the PGTK build will be ported to GTK4 at some point?

Or is that a bad idea?

bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> Is the hope that the PGTK build will be ported to GTK4 at some point?

I've in fact done that, so I have a reasonably accurate grasp of the
problems incurred.  One example: GTK 4 lacks a traditional menu widget,
for which the only substitute provided employs XML-based GMenuModels
(that are prohibitively expensive to generate dynamically), so Emacs
must implement menu bar widgets itself.

I would hope that we eventually take on responsibility for Wayland
support ourselves, in lieu of entrusting such tasks to a group of
developers whose motives and objectives cannot align with our own.

bug#65802: 29.1; Emacs fails to recognise Hyper under Wayland (KDE)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: post+emacs@guelker.eu,  65802@debbugs.gnu.org
> Date: Fri, 08 Sep 2023 15:14:16 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does this problem happen only in GTK3, and is absent from GTK4?
> 
> I believe so.  However, porting from GTK3 to GTK4 is not a trivial
> job...

Thanks, I added this to PROBLEMS.  Please see that what I wrote is
factually correct, and fix if needed.