"Po Lu" <luangruo@yahoo.com> writes:

> Trey Peacock <gpg@treypeacock.com> writes:
>
>> It does not seem to be a requirement of GTK 3.2 or XKB to send virtual
>> modifiers.
>
> See https://docs.gtk.org/gdk3/flags.ModifierType.html, which says:
>
>   Since 2.10, GDK recognizes which of the Meta, Super or Hyper keys are
>   mapped to Mod2 - Mod5, and indicates this by setting GDK_SUPER_MASK,
>   GDK_HYPER_MASK or GDK_META_MASK in the state field of key events.

The capability to do something is not the same as a requirement.

>> The only compositor I have come across that actually sends a virtual
>> modifier is mutter/GNOME. Neither wlroots nor Weston, the Wayland
>> reference implementation, send them. I'm unsure about Plasma, but I
>> believe this highlights an issue with the development of pgtk, if it
>> is meant to be targeted towards wayland users it should be tested
>> against more than just one compositor.
>
> I don't have any other compositor installed that I can actually start.
> Users, such as you, are supposed to do that part of the job.

I would be happy to help. Granted, this is only my second interaction on
the mailing list, but I do want to contribute how I can.

>> The experience of a user updating Emacs and realizing a key is no longer
>> recognized, without any notification or justification would also be a
>> step backwards.
>
> That is the price you pay when using the development version of Emacs.
> The key wasn't intentionally disabled, so I cannot know those problems
> exist until users like you report them.
>
> Hopefully, those problems will no longer exist when Emacs 29.1 is
> released.

100% agree about the risks and responsibilities of users of dev
versions. That's why I wanted to bring this to attention.

>> I have spoken with devs of wlroots & wayland over IRC and they seem to
>> agree that it is not necessary. I don't mean to be adversarial but would
>> be happy to see this change amended to incorporate the entirety of
>> wayland compositors.
>
> Wayland compositors do not send those virtual modifier masks.  GDK is
> supposed to, and does it correctly when running on GNOME Shell, so the
> bug either lies in GTK or the other Wayland compositors.

The reason this works is because mutter sends additional virtual
modifiers. You can see more here:
https://gitlab.gnome.org/GNOME/mutter/-/commit/0fa9751b3144aef5faaca1ad381b6f86b5f30994.
It is not GDK that is responsible for this. Further, since this is not
required, I don't think its proper to deem it a bug.

Now, if we were building this against Gtk 4 then I would agree with you
it seems to be the direction it's going. Though still not fully
explicit.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/docs/reference/gtk/migrating-3to4.md#adapt-to-changes-in-keyboard-modifier-handling.

Your change seems to have removed a fallback in case there were no
virtual modifiers and reverses the previous logic:

previously: if a virtual modifier exists equal to GDK_SUPER_MASK then
super_mod_mask = GDK_MOD4_MASK, if it does not equal GDK_SUPER_MASK then
it just passes the state & current value. Lastly, if a virtual modifier
does not exist super_mod_mask=GDK_MOD4_MASK.

current: only if a virtual modifier exists does super_mod_mask =
GDK_SUPER_MASK.

x_find_modifier_meanings (struct pgtk_display_info *dpyinfo)
{...
-  state = GDK_SUPER_MASK;
-  r = gdk_keymap_map_virtual_modifiers (keymap, &state);
-  if (r)
-    {
-      /* Super key exists. */
-      if (state == GDK_SUPER_MASK)
-	{
-	  dpyinfo->super_mod_mask = GDK_MOD4_MASK;	/* maybe this is super. */
-	}
-      else
-	{
-	  dpyinfo->super_mod_mask = state & ~GDK_SUPER_MASK;
-	}
-    }
-  else
-    {
-      dpyinfo->super_mod_mask = GDK_MOD4_MASK;
-    }
...
}
...
pgtk_gtk_to_emacs_modifiers (struct pgtk_display_info *dpyinfo, int state)
{...
-  if (state & dpyinfo->super_mod_mask)
+  if (state & GDK_SUPER_MASK)
     mod |= mod_super;
...
}