* Re: PGTK-related misconceptions
@ 2022-04-18 21:50 Trey
2022-04-19 0:59 ` Po Lu
0 siblings, 1 reply; 48+ messages in thread
From: Trey @ 2022-04-18 21:50 UTC (permalink / raw)
To: Po Lu; +Cc: Morgan Smith, emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 925 bytes --]
Po Lu <luangruo@yahoo.com> writes:
> Morgan Smith <morgan.j.smith@outlook.com> writes:
>
>> I'd like to report that my super key stopped registering. I suspected
>> commit 1404e16975 caused it so I did a quick `git revert 1404e16975`
>> ontop of 807682de1e and that fixed it.
>
> Crystal ball says you are using X Windows, and have to put
>
> remove mod4 = Hyper_L
>
> in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11
> Emacs to work around the common kind of virtual modifier
> misconfiguration.
>
I'm experiencing the same issue here. My super key no longer registers,
even using emacs -Q. However, I find it begins from the commit changing
to GDK modifier masks 1c1ae6ba802cc5813fa6f8f90f21050aae6bb459. I've
tested this with the following specs:
WMs: River & Sway
Emacs Version: Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.17.6) of 2022-04-18
--
Trey
[-- Attachment #1.2: publickey - gpg@treypeacock.com - da008078.asc --]
[-- Type: application/pgp-keys, Size: 1339 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: PGTK-related misconceptions 2022-04-18 21:50 PGTK-related misconceptions Trey @ 2022-04-19 0:59 ` Po Lu 2022-04-19 3:28 ` Trey Peacock 0 siblings, 1 reply; 48+ messages in thread From: Po Lu @ 2022-04-19 0:59 UTC (permalink / raw) To: Trey; +Cc: Morgan Smith, emacs-devel Trey <gpg@treypeacock.com> writes: > Po Lu <luangruo@yahoo.com> writes: > >> Morgan Smith <morgan.j.smith@outlook.com> writes: >> >>> I'd like to report that my super key stopped registering. I suspected >>> commit 1404e16975 caused it so I did a quick `git revert 1404e16975` >>> ontop of 807682de1e and that fixed it. >> >> Crystal ball says you are using X Windows, and have to put >> >> remove mod4 = Hyper_L >> >> in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11 >> Emacs to work around the common kind of virtual modifier >> misconfiguration. >> > > I'm experiencing the same issue here. My super key no longer registers, > even using emacs -Q. However, I find it begins from the commit changing > to GDK modifier masks 1c1ae6ba802cc5813fa6f8f90f21050aae6bb459. I've > tested this with the following specs: > > WMs: River & Sway > Emacs Version: Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version > 3.24.33, cairo version 1.17.6) of 2022-04-18 What about GNOME Shell, which this change was tested on? Anyway, if GTK is not setting the GDK_SUPER_MASK on Wayland, it is a bug in GDK, and should be reported to its developers. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 0:59 ` Po Lu @ 2022-04-19 3:28 ` Trey Peacock 2022-04-19 4:27 ` Po Lu 2022-07-25 21:18 ` Akira Kyle 0 siblings, 2 replies; 48+ messages in thread From: Trey Peacock @ 2022-04-19 3:28 UTC (permalink / raw) To: Po Lu; +Cc: Morgan Smith, emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 2631 bytes --] "Po Lu" <luangruo@yahoo.com> writes: > Trey <gpg@treypeacock.com> writes: > >> Po Lu <luangruo@yahoo.com> writes: >> >>> Morgan Smith <morgan.j.smith@outlook.com> writes: >>> >>>> I'd like to report that my super key stopped registering. I suspected >>>> commit 1404e16975 caused it so I did a quick `git revert 1404e16975` >>>> ontop of 807682de1e and that fixed it. >>> >>> Crystal ball says you are using X Windows, and have to put >>> >>> remove mod4 = Hyper_L >>> >>> in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11 >>> Emacs to work around the common kind of virtual modifier >>> misconfiguration. >>> >> >> I'm experiencing the same issue here. My super key no longer registers, >> even using emacs -Q. However, I find it begins from the commit changing >> to GDK modifier masks 1c1ae6ba802cc5813fa6f8f90f21050aae6bb459. I've >> tested this with the following specs: >> >> WMs: River & Sway >> Emacs Version: Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version >> 3.24.33, cairo version 1.17.6) of 2022-04-18 > > What about GNOME Shell, which this change was tested on? > > Anyway, if GTK is not setting the GDK_SUPER_MASK on Wayland, it is a bug > in GDK, and should be reported to its developers. Neither of the WMs I mentioned use GNOME Shell, but they do both use wlroots. Looking into this, it seems that any wlroots based Wayland compositor will use GDK_MOD4_MASK as Super. However, mutter (GNOME's WM) uses GDK_SUPER_MASK. Rebuilding emacs with the below patch seems to have fixed the issue. I'm not sure if there could be further implications for pgtk_emacs_to_gtk_modifiers. diff --git a/src/pgtkterm.c b/src/pgtkterm.c index 2b04699fb3..d8ca89bbc0 100644 --- a/src/pgtkterm.c +++ b/src/pgtkterm.c @@ -5152,7 +5152,7 @@ pgtk_gtk_to_emacs_modifiers (struct pgtk_display_info *dpyinfo, int state) mod |= mod_ctrl; if (state & GDK_META_MASK || state & GDK_MOD1_MASK) mod |= mod_meta; - if (state & GDK_SUPER_MASK) + if (state & GDK_SUPER_MASK || state & GDK_MOD4_MASK) mod |= mod_super; if (state & GDK_HYPER_MASK) mod |= mod_hyper; @@ -5285,7 +5285,7 @@ key_press_event (GtkWidget *widget, GdkEvent *event, gpointer *user_data) /* While super is pressed, the input method will always always resend the key events ignoring super. As a workaround, don't filter key events with super or hyper pressed. */ - if (!(event->key.state & (GDK_SUPER_MASK | GDK_HYPER_MASK))) + if (!(event->key.state & (GDK_SUPER_MASK | GDK_HYPER_MASK | GDK_MOD4_MASK))) { if (pgtk_im_filter_keypress (f, &event->key)) return TRUE; [-- Attachment #1.2: publickey - gpg@treypeacock.com - da008078.asc --] [-- Type: application/pgp-keys, Size: 1339 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 249 bytes --] ^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 3:28 ` Trey Peacock @ 2022-04-19 4:27 ` Po Lu 2022-04-19 23:02 ` Trey Peacock 2022-07-25 21:18 ` Akira Kyle 1 sibling, 1 reply; 48+ messages in thread From: Po Lu @ 2022-04-19 4:27 UTC (permalink / raw) To: Trey Peacock; +Cc: Morgan Smith, emacs-devel Trey Peacock <gpg@treypeacock.com> writes: > Neither of the WMs I mentioned use GNOME Shell, but they do both use > wlroots. Looking into this, it seems that any wlroots based Wayland > compositor will use GDK_MOD4_MASK as Super. However, mutter (GNOME's > WM) uses GDK_SUPER_MASK. Rebuilding emacs with the below patch seems > to have fixed the issue. I'm not sure if there could be further > implications for pgtk_emacs_to_gtk_modifiers. GDK_MOD4_MASK is a real modifier. GDK_SUPER_MASK is a "virtual modifier" mask. The entire point of that change was to rely on GDK to compute the correspondence between real modifiers and virtual modifiers instead of doing it ourselves, since a real modifier can mean any number of virtual modifiers and vice versa. Hard-coding the meaning of GDK_MOD4_MASK would be a step backwards. This seems to either be a bug in wlroots or GDK, so I suggest that a bug be filed with their developers. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 4:27 ` Po Lu @ 2022-04-19 23:02 ` Trey Peacock 2022-04-20 0:48 ` Po Lu 0 siblings, 1 reply; 48+ messages in thread From: Trey Peacock @ 2022-04-19 23:02 UTC (permalink / raw) To: Po Lu; +Cc: Morgan Smith, emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1854 bytes --] "Po Lu" <luangruo@yahoo.com> writes: > Trey Peacock <gpg@treypeacock.com> writes: > >> Neither of the WMs I mentioned use GNOME Shell, but they do both use >> wlroots. Looking into this, it seems that any wlroots based Wayland >> compositor will use GDK_MOD4_MASK as Super. However, mutter (GNOME's >> WM) uses GDK_SUPER_MASK. Rebuilding emacs with the below patch seems >> to have fixed the issue. I'm not sure if there could be further >> implications for pgtk_emacs_to_gtk_modifiers. > > GDK_MOD4_MASK is a real modifier. GDK_SUPER_MASK is a "virtual > modifier" mask. > > The entire point of that change was to rely on GDK to compute the > correspondence between real modifiers and virtual modifiers instead of > doing it ourselves, since a real modifier can mean any number of virtual > modifiers and vice versa. It does not seem to be a requirement of GTK 3.2 or XKB to send virtual modifiers. 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. > Hard-coding the meaning of GDK_MOD4_MASK would be a step backwards. 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. > This seems to either be a bug in wlroots or GDK, so I suggest that a bug > be filed with their developers. 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. [-- Attachment #1.2: publickey - gpg@treypeacock.com - da008078.asc --] [-- Type: application/pgp-keys, Size: 1339 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 249 bytes --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 23:02 ` Trey Peacock @ 2022-04-20 0:48 ` Po Lu 2022-04-20 2:33 ` Trey Peacock 0 siblings, 1 reply; 48+ messages in thread From: Po Lu @ 2022-04-20 0:48 UTC (permalink / raw) To: Trey Peacock; +Cc: Morgan Smith, emacs-devel 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 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. > 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. > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-20 0:48 ` Po Lu @ 2022-04-20 2:33 ` Trey Peacock 2022-04-20 4:05 ` Po Lu 0 siblings, 1 reply; 48+ messages in thread From: Trey Peacock @ 2022-04-20 2:33 UTC (permalink / raw) To: Po Lu; +Cc: Morgan Smith, emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 3921 bytes --] "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; ... } [-- Attachment #1.2: publickey - gpg@treypeacock.com - da008078.asc --] [-- Type: application/pgp-keys, Size: 1339 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 249 bytes --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-20 2:33 ` Trey Peacock @ 2022-04-20 4:05 ` Po Lu 0 siblings, 0 replies; 48+ messages in thread From: Po Lu @ 2022-04-20 4:05 UTC (permalink / raw) To: Trey Peacock; +Cc: Morgan Smith, emacs-devel Trey Peacock <gpg@treypeacock.com> writes: >> 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. It's the documented behavior of GDK, and Emacs holds GDK to its documentation. Nowhere does the documentation say this is a "capability", "recognizes" is in the third-person present tense, which makes it a requirement. > 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. Great, one step forward would be to bring up the issue with either the GTK or Wayland compositor developers. Since you've already talked with the latter, and they say it's not their problem, please contact the former. > 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. It is, as specified in its documentation. > Your change seems to have removed a fallback in case there were no > virtual modifiers and reverses the previous logic: As you can see by the name of the function, it was directly ported over from X (the current version is in xterm.c), and is yet another example of the PGTK port translating X Windows code to GDK verbatim, duplicating what GDK is supposed to do itself. I will not change Emacs because the GTK developers, yet again, forgot to follow their own documentation when implementing some feature. It just makes Emacs code bloated, hard-to-follow and liable to break at the slightest whim of the GTK developers, who then respond that we're not using GTK "properly", because we try to work around their problems. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 3:28 ` Trey Peacock 2022-04-19 4:27 ` Po Lu @ 2022-07-25 21:18 ` Akira Kyle 2022-07-26 2:08 ` Po Lu 1 sibling, 1 reply; 48+ messages in thread From: Akira Kyle @ 2022-07-25 21:18 UTC (permalink / raw) To: Trey Peacock; +Cc: Po Lu, Morgan Smith, emacs-devel On Tue, Apr 19, 2022 at 03:28 AM, Trey Peacock <gpg@treypeacock.com> wrote: > Neither of the WMs I mentioned use GNOME Shell, but they do both > use > wlroots. Looking into this, it seems that any wlroots based > Wayland > compositor will use GDK_MOD4_MASK as Super. However, mutter > (GNOME's WM) > uses GDK_SUPER_MASK. Rebuilding emacs with the below patch seems > to have > fixed the issue. I'm not sure if there could be further > implications for > pgtk_emacs_to_gtk_modifiers. > > > diff --git a/src/pgtkterm.c b/src/pgtkterm.c > index 2b04699fb3..d8ca89bbc0 100644 > --- a/src/pgtkterm.c > +++ b/src/pgtkterm.c > @@ -5152,7 +5152,7 @@ pgtk_gtk_to_emacs_modifiers (struct > pgtk_display_info *dpyinfo, int state) > mod |= mod_ctrl; > if (state & GDK_META_MASK || state & GDK_MOD1_MASK) > mod |= mod_meta; > - if (state & GDK_SUPER_MASK) > + if (state & GDK_SUPER_MASK || state & GDK_MOD4_MASK) > mod |= mod_super; > if (state & GDK_HYPER_MASK) > mod |= mod_hyper; > @@ -5285,7 +5285,7 @@ key_press_event (GtkWidget *widget, > GdkEvent *event, gpointer *user_data) > /* While super is pressed, the input method will always > always > resend the key events ignoring super. As a workaround, > don't > filter key events with super or hyper pressed. */ > - if (!(event->key.state & (GDK_SUPER_MASK | > GDK_HYPER_MASK))) > + if (!(event->key.state & (GDK_SUPER_MASK | GDK_HYPER_MASK > | GDK_MOD4_MASK))) > { > if (pgtk_im_filter_keypress (f, &event->key)) > return TRUE; Thank you for this patch! I recently updated and ran into this issue. From the discussion in this thread, I really don't understand why this change was made. Is this fixing some issue for some other non-wlroots based compositor? If it isn't, but was just made "to comply with the GDK docs" this would seem to be just be making life more difficult for those of use on wlroots based compositors. Emacs has many other places where it tries to work around quirks and other issues with GTK for the benefit of the user, so why would this be any different? ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-25 21:18 ` Akira Kyle @ 2022-07-26 2:08 ` Po Lu 2022-07-26 12:10 ` Lars Ingebrigtsen 2022-07-26 21:36 ` Akira Kyle 0 siblings, 2 replies; 48+ messages in thread From: Po Lu @ 2022-07-26 2:08 UTC (permalink / raw) To: Akira Kyle; +Cc: Trey Peacock, Morgan Smith, emacs-devel Akira Kyle <akira@akirakyle.com> writes: > Thank you for this patch! I recently updated and ran into this > issue. From the discussion in this thread, I really don't understand > why this change was made. Is this fixing some issue for some other > non-wlroots based compositor? Yes, see below. > If it isn't, but was just made "to comply with the GDK docs" this > would seem to be just be making life more difficult for those of use > on wlroots based compositors. Emacs has many other places where it > tries to work around quirks and other issues with GTK for the benefit > of the user, so why would this be any different? It is to prevent errors when Mod4 is _not_ the super key. Very common on X (where Mod4 is commonly Hyper), and in fact it is caused by Mod4 not being part of the Super virtual modifier in the compositor's XKB configuration. The conclusion I eventually came to is that the problem lies in the XKB configuration of the Wayland compositor in question (namely, Sway), and not Emacs nor GDK. It works with GNOME Shell and kwin because they set up their keyboards with the correct virtual modifiers by default. So what I'd recommend is to start an X server where the Super key does work, run: xkbcomp $DISPLAY name/of/xkb/file.xkb and then use that file with Sway. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-26 2:08 ` Po Lu @ 2022-07-26 12:10 ` Lars Ingebrigtsen 2022-07-26 12:35 ` Po Lu 2022-07-26 21:36 ` Akira Kyle 1 sibling, 1 reply; 48+ messages in thread From: Lars Ingebrigtsen @ 2022-07-26 12:10 UTC (permalink / raw) To: Po Lu; +Cc: Akira Kyle, Trey Peacock, Morgan Smith, emacs-devel Po Lu <luangruo@yahoo.com> writes: > It is to prevent errors when Mod4 is _not_ the super key. Very common > on X (where Mod4 is commonly Hyper), and in fact it is caused by Mod4 > not being part of the Super virtual modifier in the compositor's XKB > configuration. But in this case, Emacs is running under wlroots, so there's no X, is there? Adding a workaround for what is apparently a really common problem here sounds like something we just have to do. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-26 12:10 ` Lars Ingebrigtsen @ 2022-07-26 12:35 ` Po Lu 2022-07-29 14:26 ` Stefan Monnier 0 siblings, 1 reply; 48+ messages in thread From: Po Lu @ 2022-07-26 12:35 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Akira Kyle, Trey Peacock, Morgan Smith, emacs-devel Lars Ingebrigtsen <larsi@gnus.org> writes: > But in this case, Emacs is running under wlroots, so there's no X, is > there? Wayland uses the same system of virtual modifiers as well. > Adding a workaround for what is apparently a really common problem here > sounds like something we just have to do. I'd rather document the workaround here in etc/PROBLEMS, once Akira confirms that it works. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-26 12:35 ` Po Lu @ 2022-07-29 14:26 ` Stefan Monnier 2022-07-30 0:58 ` Po Lu 0 siblings, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2022-07-29 14:26 UTC (permalink / raw) To: Po Lu Cc: Lars Ingebrigtsen, Akira Kyle, Trey Peacock, Morgan Smith, emacs-devel >> Adding a workaround for what is apparently a really common problem here >> sounds like something we just have to do. > I'd rather document the workaround here in etc/PROBLEMS, once Akira > confirms that it works. There should be a matching bug report in Sway, right? Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-29 14:26 ` Stefan Monnier @ 2022-07-30 0:58 ` Po Lu 0 siblings, 0 replies; 48+ messages in thread From: Po Lu @ 2022-07-30 0:58 UTC (permalink / raw) To: Stefan Monnier Cc: Lars Ingebrigtsen, Akira Kyle, Trey Peacock, Morgan Smith, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I'd rather document the workaround here in etc/PROBLEMS, once Akira >> confirms that it works. > > There should be a matching bug report in Sway, right? Yes, but it'd be easier to report the bug to them if we know the workaround. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-26 2:08 ` Po Lu 2022-07-26 12:10 ` Lars Ingebrigtsen @ 2022-07-26 21:36 ` Akira Kyle 2022-07-27 2:48 ` Po Lu 1 sibling, 1 reply; 48+ messages in thread From: Akira Kyle @ 2022-07-26 21:36 UTC (permalink / raw) To: Po Lu; +Cc: Trey Peacock, Morgan Smith, emacs-devel On Tue, Jul 26, 2022 at 10:08 AM, Po Lu <luangruo@yahoo.com> wrote: > It is to prevent errors when Mod4 is _not_ the super key. Very > common > on X (where Mod4 is commonly Hyper), and in fact it is caused by > Mod4 > not being part of the Super virtual modifier in the compositor's > XKB > configuration. > > The conclusion I eventually came to is that the problem lies in > the XKB > configuration of the Wayland compositor in question (namely, > Sway), and > not Emacs nor GDK. It works with GNOME Shell and kwin because > they set > up their keyboards with the correct virtual modifiers by > default. So > what I'd recommend is to start an X server where the Super key > does > work, run: > > xkbcomp $DISPLAY name/of/xkb/file.xkb > > and then use that file with Sway. This does not appear to work. I can attach the full .xkb file that xkbcomp generated if you like, but it's the default which you get from the following under the v2.34 xkeyboad-config files. xkb_keymap "my_dvorak_super" { xkb_keycodes { include "evdev" }; xkb_compatibility { include "complete" }; xkb_types { include "complete" }; xkb_symbols { include "us(dvorak)+pc(pc105)" }; }; Specifically, when I use the same .xkb file under X I get that emacs interprets the physical keycode <RWIN> as Super whereas under wayland with sway, emacs does not respond to <RWIN>. The relevant lines from the xkb_symbols section are key <RWIN> { [ Super_R ] }; modifier_map Mod4 { <RWIN> }; Reading through the links that Trey sent in previous emails to the gtk source which handles modifier keys in x11 versus wayland, I'm pretty convinced his diagnosis is correct. Namely gtk behaves differently in stetting GDK_SUPER_MASK on x11 versus wayland where on the former seeing the "Super_R" symbol will set the mask while on the latter, only the virtual modifier "Super" will set GDK_SUPER_MASK. Although it seems like in principle, one should be able to get xkb to set the "Super" virtual modifier so that GTK correctly picks it up in it's wayland code. However thus far I have been unable to make a set of xkb rules which will trigger the "Super" virtual modifier for the <RWIN> keycode despite much effort. Perhaps this is possible and I just don't understand xkb's rules sufficiently, or perhaps there is some issue in xkb which is preventing from GTK to picking up the "Super" virtual modifier. Thus far I have tried many variations on some configuration like the following default partial modifier_keys xkb_symbols "basic" { include "us(dvorak)" name[Group1] = "super"; key <RWIN> { symbols[Group1]= [ Super_R ], virtualMods= Super }; key <LWIN> { symbols[Group1]= [ Super_L ], virtualMods= Super }; }; What is also puzzling to me is that my .xkb file also includes the "misc" xkb_compatibility rules which look like the following interpret Super_R+Any { virtualModifier= Super; action = SetMods(modifiers=modMapMods); }; interpret Super_R { action = SetMods(modifiers=Super); }; ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-26 21:36 ` Akira Kyle @ 2022-07-27 2:48 ` Po Lu 2022-07-27 8:34 ` Trey Peacock 2022-07-28 1:39 ` Akira Kyle 0 siblings, 2 replies; 48+ messages in thread From: Po Lu @ 2022-07-27 2:48 UTC (permalink / raw) To: Akira Kyle; +Cc: Trey Peacock, Morgan Smith, emacs-devel Akira Kyle <akira@akirakyle.com> writes: > This does not appear to work. I can attach the full .xkb file that > xkbcomp generated if you like, but it's the default which you get from > the following under the v2.34 xkeyboad-config files. > > xkb_keymap "my_dvorak_super" { > xkb_keycodes { include "evdev" }; > xkb_compatibility { include "complete" }; > xkb_types { include "complete" }; > xkb_symbols { include "us(dvorak)+pc(pc105)" }; > }; > > Specifically, when I use the same .xkb file under X I get that emacs > interprets the physical keycode <RWIN> as Super whereas under wayland > with sway, emacs does not respond to <RWIN>. The relevant lines from > the xkb_symbols section are > > key <RWIN> { [ Super_R ] }; > modifier_map Mod4 { <RWIN> }; > > Reading through the links that Trey sent in previous emails to the gtk > source which handles modifier keys in x11 versus wayland, I'm pretty > convinced his diagnosis is correct. > Namely gtk behaves differently in stetting GDK_SUPER_MASK on x11 > versus wayland where on the former seeing the "Super_R" symbol will > set the mask while on the latter, only the virtual modifier "Super" > will set GDK_SUPER_MASK. That's because the Wayland compositor isn't sending a keymap that makes libxkbcommon assign Mod4 to Super. See this bit of gdkkeys-wayland.c: if (mods & (1 << xkb_keymap_mod_get_index (xkb_keymap, "Super"))) state |= GDK_SUPER_MASK; which is called from deliver_key_event and keyboard_handle_modifiers in gdkdevice-wayland.c: seat->key_modifiers = gdk_keymap_get_modifier_state (keymap); and uses an XKB keymap created in _gdk_wayland_keymap_update_from_fd. It is not a bug in GTK, but a bug in the default configuration of the Wayland compositor (regardless of what their developers say.) > Although it seems like in principle, one should be able to get xkb to > set the "Super" virtual modifier so that GTK correctly picks it up in > it's wayland code. However thus far I have been unable to make a set > of xkb rules which will trigger the "Super" virtual modifier for the > <RWIN> keycode despite much effort. Perhaps this is possible and I > just don't understand xkb's rules sufficiently, or perhaps there is > some issue in xkb which is preventing from GTK to picking up the > "Super" virtual modifier. Thus far I have tried many variations on Could you please send the entire XKB file generated? Thanks. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-27 2:48 ` Po Lu @ 2022-07-27 8:34 ` Trey Peacock 2022-07-27 9:10 ` Po Lu 2022-07-28 1:39 ` Akira Kyle 1 sibling, 1 reply; 48+ messages in thread From: Trey Peacock @ 2022-07-27 8:34 UTC (permalink / raw) To: Po Lu, Akira Kyle; +Cc: Morgan Smith, emacs-devel "Po Lu" <luangruo@yahoo.com> writes: > That's because the Wayland compositor isn't sending a keymap that makes > libxkbcommon assign Mod4 to Super. See this bit of gdkkeys-wayland.c: > > if (mods & (1 << xkb_keymap_mod_get_index (xkb_keymap, "Super"))) > state |= GDK_SUPER_MASK; > > which is called from deliver_key_event and keyboard_handle_modifiers in > gdkdevice-wayland.c: > > seat->key_modifiers = gdk_keymap_get_modifier_state (keymap); > > and uses an XKB keymap created in _gdk_wayland_keymap_update_from_fd. > It is not a bug in GTK, but a bug in the default configuration of the > Wayland compositor (regardless of what their developers say.) This section of code is in gdkkeys-x11.c and called from update_keymaps: mask = 0; for (j = 0; j < keymap_x11->keysyms_per_keycode; j++) { if (syms[j] == GDK_KEY_Meta_L || syms[j] == GDK_KEY_Meta_R) mask |= GDK_META_MASK; else if (syms[j] == GDK_KEY_Hyper_L || syms[j] == GDK_KEY_Hyper_R) mask |= GDK_HYPER_MASK; else if (syms[j] == GDK_KEY_Super_L || syms[j] == GDK_KEY_Super_R) mask |= GDK_SUPER_MASK; } Which seems like it accepts the GDK_KEY_Super_L/R and subsequently sets the mask, right? I believe this is the reason why the virtual mask is recognized when using Xwayland on wlroots based compositors. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-27 8:34 ` Trey Peacock @ 2022-07-27 9:10 ` Po Lu 2022-07-27 13:45 ` Trey Peacock 0 siblings, 1 reply; 48+ messages in thread From: Po Lu @ 2022-07-27 9:10 UTC (permalink / raw) To: Trey Peacock; +Cc: Akira Kyle, Morgan Smith, emacs-devel Trey Peacock <gpg@treypeacock.com> writes: > This section of code is in gdkkeys-x11.c and called from update_keymaps: > > mask = 0; > for (j = 0; j < keymap_x11->keysyms_per_keycode; j++) > { > if (syms[j] == GDK_KEY_Meta_L || > syms[j] == GDK_KEY_Meta_R) > mask |= GDK_META_MASK; > else if (syms[j] == GDK_KEY_Hyper_L || > syms[j] == GDK_KEY_Hyper_R) > mask |= GDK_HYPER_MASK; > else if (syms[j] == GDK_KEY_Super_L || > syms[j] == GDK_KEY_Super_R) > mask |= GDK_SUPER_MASK; > } > > Which seems like it accepts the GDK_KEY_Super_L/R and subsequently sets > the mask, right? I believe this is the reason why the virtual mask is > recognized when using Xwayland on wlroots based compositors. Why is Xwayland related in any way? And that code is only used when the XKB extension is _NOT_ present on the X server. Otherwise, the code under update_modmap is used. The exact analog in Emacs is x_find_modifier_meanings in xterm.c. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-27 9:10 ` Po Lu @ 2022-07-27 13:45 ` Trey Peacock 2022-07-27 13:52 ` Po Lu 0 siblings, 1 reply; 48+ messages in thread From: Trey Peacock @ 2022-07-27 13:45 UTC (permalink / raw) To: Po Lu; +Cc: Akira Kyle, Morgan Smith, emacs-devel "Po Lu" <luangruo@yahoo.com> writes: > Why is Xwayland related in any way? > > And that code is only used when the XKB extension is _NOT_ present on > the X server. Otherwise, the code under update_modmap is used. The > exact analog in Emacs is x_find_modifier_meanings in xterm.c. I was trying to determine why the attached script in python will recognize the virtual mod mask when run under Xwayland but not when run normally. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-27 13:45 ` Trey Peacock @ 2022-07-27 13:52 ` Po Lu 0 siblings, 0 replies; 48+ messages in thread From: Po Lu @ 2022-07-27 13:52 UTC (permalink / raw) To: Trey Peacock; +Cc: Akira Kyle, Morgan Smith, emacs-devel Trey Peacock <gpg@treypeacock.com> writes: > I was trying to determine why the attached script in python will > recognize the virtual mod mask when run under Xwayland but not when run > normally. I think that's because Xwayland uses the regular keyboard configuration also used by a "bare-metal" X server by default. Thanks. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-27 2:48 ` Po Lu 2022-07-27 8:34 ` Trey Peacock @ 2022-07-28 1:39 ` Akira Kyle 2022-07-28 2:50 ` Po Lu 1 sibling, 1 reply; 48+ messages in thread From: Akira Kyle @ 2022-07-28 1:39 UTC (permalink / raw) To: Po Lu; +Cc: Trey Peacock, Morgan Smith, emacs-devel [-- Attachment #1: Type: text/plain, Size: 2246 bytes --] On Wed, Jul 27, 2022 at 10:48 AM, Po Lu <luangruo@yahoo.com> wrote: >> Namely gtk behaves differently in stetting GDK_SUPER_MASK on >> x11 >> versus wayland where on the former seeing the "Super_R" symbol >> will >> set the mask while on the latter, only the virtual modifier >> "Super" >> will set GDK_SUPER_MASK. > > That's because the Wayland compositor isn't sending a keymap > that makes > libxkbcommon assign Mod4 to Super. See this bit of > gdkkeys-wayland.c: > > if (mods & (1 << xkb_keymap_mod_get_index (xkb_keymap, > "Super"))) > state |= GDK_SUPER_MASK; > > which is called from deliver_key_event and > keyboard_handle_modifiers in > gdkdevice-wayland.c: > > seat->key_modifiers = gdk_keymap_get_modifier_state (keymap); > > and uses an XKB keymap created in > _gdk_wayland_keymap_update_from_fd. > It is not a bug in GTK, but a bug in the default configuration > of the > Wayland compositor (regardless of what their developers say.) I'm not totally convinced, since sway should just be using the .xkb file I specify. The relevant code is in sway/input/keyboard.c where it uses the .xkb file in sway_keyboard_compile_keymap which then sway sets using wlr_keyboard_set_keymap inside sway_keyboard_configure. So this should be the same keymap that GTK is using. Perhaps the bug isn't in GTK but its that mutter is doing something special, but I don't immediately see how the function add_virtual_mods in src/wayland/meta-wayland-keyboard.c would cause this bug and I don't see anything else obviously related to this bug. >> Although it seems like in principle, one should be able to get >> xkb to >> set the "Super" virtual modifier so that GTK correctly picks it >> up in >> it's wayland code. However thus far I have been unable to make >> a set >> of xkb rules which will trigger the "Super" virtual modifier >> for the >> <RWIN> keycode despite much effort. Perhaps this is possible >> and I >> just don't understand xkb's rules sufficiently, or perhaps >> there is >> some issue in xkb which is preventing from GTK to picking up >> the >> "Super" virtual modifier. Thus far I have tried many variations >> on > > Could you please send the entire XKB file generated? Thanks. Attached. [-- Attachment #2: dvorak_super_compiled.xkb --] [-- Type: text/plain, Size: 46916 bytes --] xkb_keymap { xkb_keycodes "evdev" { minimum = 8; maximum = 255; <ESC> = 9; <AE01> = 10; <AE02> = 11; <AE03> = 12; <AE04> = 13; <AE05> = 14; <AE06> = 15; <AE07> = 16; <AE08> = 17; <AE09> = 18; <AE10> = 19; <AE11> = 20; <AE12> = 21; <BKSP> = 22; <TAB> = 23; <AD01> = 24; <AD02> = 25; <AD03> = 26; <AD04> = 27; <AD05> = 28; <AD06> = 29; <AD07> = 30; <AD08> = 31; <AD09> = 32; <AD10> = 33; <AD11> = 34; <AD12> = 35; <RTRN> = 36; <LCTL> = 37; <AC01> = 38; <AC02> = 39; <AC03> = 40; <AC04> = 41; <AC05> = 42; <AC06> = 43; <AC07> = 44; <AC08> = 45; <AC09> = 46; <AC10> = 47; <AC11> = 48; <TLDE> = 49; <LFSH> = 50; <BKSL> = 51; <AB01> = 52; <AB02> = 53; <AB03> = 54; <AB04> = 55; <AB05> = 56; <AB06> = 57; <AB07> = 58; <AB08> = 59; <AB09> = 60; <AB10> = 61; <RTSH> = 62; <KPMU> = 63; <LALT> = 64; <SPCE> = 65; <CAPS> = 66; <FK01> = 67; <FK02> = 68; <FK03> = 69; <FK04> = 70; <FK05> = 71; <FK06> = 72; <FK07> = 73; <FK08> = 74; <FK09> = 75; <FK10> = 76; <NMLK> = 77; <SCLK> = 78; <KP7> = 79; <KP8> = 80; <KP9> = 81; <KPSU> = 82; <KP4> = 83; <KP5> = 84; <KP6> = 85; <KPAD> = 86; <KP1> = 87; <KP2> = 88; <KP3> = 89; <KP0> = 90; <KPDL> = 91; <LVL3> = 92; <LSGT> = 94; <FK11> = 95; <FK12> = 96; <AB11> = 97; <KATA> = 98; <HIRA> = 99; <HENK> = 100; <HKTG> = 101; <MUHE> = 102; <JPCM> = 103; <KPEN> = 104; <RCTL> = 105; <KPDV> = 106; <PRSC> = 107; <RALT> = 108; <LNFD> = 109; <HOME> = 110; <UP> = 111; <PGUP> = 112; <LEFT> = 113; <RGHT> = 114; <END> = 115; <DOWN> = 116; <PGDN> = 117; <INS> = 118; <DELE> = 119; <I120> = 120; <MUTE> = 121; <VOL-> = 122; <VOL+> = 123; <POWR> = 124; <KPEQ> = 125; <I126> = 126; <PAUS> = 127; <I128> = 128; <I129> = 129; <HNGL> = 130; <HJCV> = 131; <AE13> = 132; <LWIN> = 133; <RWIN> = 134; <COMP> = 135; <STOP> = 136; <AGAI> = 137; <PROP> = 138; <UNDO> = 139; <FRNT> = 140; <COPY> = 141; <OPEN> = 142; <PAST> = 143; <FIND> = 144; <CUT> = 145; <HELP> = 146; <I147> = 147; <I148> = 148; <I149> = 149; <I150> = 150; <I151> = 151; <I152> = 152; <I153> = 153; <I154> = 154; <I155> = 155; <I156> = 156; <I157> = 157; <I158> = 158; <I159> = 159; <I160> = 160; <I161> = 161; <I162> = 162; <I163> = 163; <I164> = 164; <I165> = 165; <I166> = 166; <I167> = 167; <I168> = 168; <I169> = 169; <I170> = 170; <I171> = 171; <I172> = 172; <I173> = 173; <I174> = 174; <I175> = 175; <I176> = 176; <I177> = 177; <I178> = 178; <I179> = 179; <I180> = 180; <I181> = 181; <I182> = 182; <I183> = 183; <I184> = 184; <I185> = 185; <I186> = 186; <I187> = 187; <I188> = 188; <I189> = 189; <I190> = 190; <FK13> = 191; <FK14> = 192; <FK15> = 193; <FK16> = 194; <FK17> = 195; <FK18> = 196; <FK19> = 197; <FK20> = 198; <FK21> = 199; <FK22> = 200; <FK23> = 201; <FK24> = 202; <MDSW> = 203; <ALT> = 204; <META> = 205; <SUPR> = 206; <HYPR> = 207; <I208> = 208; <I209> = 209; <I210> = 210; <I211> = 211; <I212> = 212; <I213> = 213; <I214> = 214; <I215> = 215; <I216> = 216; <I217> = 217; <I218> = 218; <I219> = 219; <I220> = 220; <I221> = 221; <I222> = 222; <I223> = 223; <I224> = 224; <I225> = 225; <I226> = 226; <I227> = 227; <I228> = 228; <I229> = 229; <I230> = 230; <I231> = 231; <I232> = 232; <I233> = 233; <I234> = 234; <I235> = 235; <I236> = 236; <I237> = 237; <I238> = 238; <I239> = 239; <I240> = 240; <I241> = 241; <I242> = 242; <I243> = 243; <I244> = 244; <I245> = 245; <I246> = 246; <I247> = 247; <I248> = 248; <I249> = 249; <I250> = 250; <I251> = 251; <I252> = 252; <I253> = 253; <I254> = 254; <I255> = 255; indicator 1 = "Caps Lock"; indicator 2 = "Num Lock"; indicator 3 = "Scroll Lock"; indicator 4 = "Compose"; indicator 5 = "Kana"; indicator 6 = "Sleep"; indicator 7 = "Suspend"; indicator 8 = "Mute"; indicator 9 = "Misc"; indicator 10 = "Mail"; indicator 11 = "Charging"; virtual indicator 12 = "Shift Lock"; virtual indicator 13 = "Group 2"; virtual indicator 14 = "Mouse Keys"; alias <AC12> = <BKSL>; alias <MENU> = <COMP>; alias <HZTG> = <TLDE>; alias <LMTA> = <LWIN>; alias <RMTA> = <RWIN>; alias <OUTP> = <I235>; alias <KITG> = <I236>; alias <KIDN> = <I237>; alias <KIUP> = <I238>; alias <I121> = <MUTE>; alias <I122> = <VOL->; alias <I123> = <VOL+>; alias <I124> = <POWR>; alias <I125> = <KPEQ>; alias <I127> = <PAUS>; alias <I130> = <HNGL>; alias <I131> = <HJCV>; alias <I132> = <AE13>; alias <I133> = <LWIN>; alias <I134> = <RWIN>; alias <I135> = <COMP>; alias <I136> = <STOP>; alias <I137> = <AGAI>; alias <I138> = <PROP>; alias <I139> = <UNDO>; alias <I140> = <FRNT>; alias <I141> = <COPY>; alias <I142> = <OPEN>; alias <I143> = <PAST>; alias <I144> = <FIND>; alias <I145> = <CUT>; alias <I146> = <HELP>; alias <I191> = <FK13>; alias <I192> = <FK14>; alias <I193> = <FK15>; alias <I194> = <FK16>; alias <I195> = <FK17>; alias <I196> = <FK18>; alias <I197> = <FK19>; alias <I198> = <FK20>; alias <I199> = <FK21>; alias <I200> = <FK22>; alias <I201> = <FK23>; alias <I202> = <FK24>; alias <ALGR> = <RALT>; alias <KPPT> = <I129>; }; xkb_types "complete" { virtual_modifiers NumLock,Alt,LevelThree,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr,Meta,Super,Hyper; type "ONE_LEVEL" { modifiers= none; level_name[Level1]= "Any"; }; type "TWO_LEVEL" { modifiers= Shift; map[Shift]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; }; type "ALPHABETIC" { modifiers= Shift+Lock; map[Shift]= Level2; map[Lock]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "Caps"; }; type "KEYPAD" { modifiers= Shift+NumLock; map[NumLock]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "Number"; }; type "SHIFT+ALT" { modifiers= Shift+Alt; map[Shift+Alt]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "Shift+Alt"; }; type "PC_SUPER_LEVEL2" { modifiers= Mod4; map[Mod4]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "Super"; }; type "PC_CONTROL_LEVEL2" { modifiers= Control; map[Control]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "Control"; }; type "PC_LCONTROL_LEVEL2" { modifiers= LControl; map[LControl]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "LControl"; }; type "PC_RCONTROL_LEVEL2" { modifiers= RControl; map[RControl]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "RControl"; }; type "PC_ALT_LEVEL2" { modifiers= Alt; map[Alt]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "Alt"; }; type "PC_LALT_LEVEL2" { modifiers= LAlt; map[LAlt]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "LAlt"; }; type "PC_RALT_LEVEL2" { modifiers= RAlt; map[RAlt]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "RAlt"; }; type "CTRL+ALT" { modifiers= Shift+Control+Alt+LevelThree; map[Shift]= Level2; preserve[Shift]= Shift; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; preserve[Shift+LevelThree]= Shift; map[Control+Alt]= Level5; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; level_name[Level5]= "Ctrl+Alt"; }; type "LOCAL_EIGHT_LEVEL" { modifiers= Shift+Lock+Control+LevelThree; map[Shift+Lock]= Level1; map[Shift]= Level2; map[Lock]= Level2; map[LevelThree]= Level3; map[Shift+Lock+LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[Lock+LevelThree]= Level4; map[Control]= Level5; map[Shift+Lock+Control]= Level5; map[Shift+Control]= Level6; map[Lock+Control]= Level6; map[Control+LevelThree]= Level7; map[Shift+Lock+Control+LevelThree]= Level7; map[Shift+Control+LevelThree]= Level8; map[Lock+Control+LevelThree]= Level8; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Level3"; level_name[Level4]= "Shift Level3"; level_name[Level5]= "Ctrl"; level_name[Level6]= "Shift Ctrl"; level_name[Level7]= "Level3 Ctrl"; level_name[Level8]= "Shift Level3 Ctrl"; }; type "THREE_LEVEL" { modifiers= Shift+LevelThree; map[Shift]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level3; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Level3"; }; type "EIGHT_LEVEL" { modifiers= Shift+LevelThree+LevelFive; map[Shift]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[LevelFive]= Level5; map[Shift+LevelFive]= Level6; map[LevelThree+LevelFive]= Level7; map[Shift+LevelThree+LevelFive]= Level8; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; level_name[Level5]= "X"; level_name[Level6]= "X Shift"; level_name[Level7]= "X Alt Base"; level_name[Level8]= "X Shift Alt"; }; type "EIGHT_LEVEL_ALPHABETIC" { modifiers= Shift+Lock+LevelThree+LevelFive; map[Shift]= Level2; map[Lock]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[Lock+LevelThree]= Level4; map[Shift+Lock+LevelThree]= Level3; map[LevelFive]= Level5; map[Shift+LevelFive]= Level6; map[Lock+LevelFive]= Level6; map[LevelThree+LevelFive]= Level7; map[Shift+LevelThree+LevelFive]= Level8; map[Lock+LevelThree+LevelFive]= Level8; map[Shift+Lock+LevelThree+LevelFive]= Level7; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; level_name[Level5]= "X"; level_name[Level6]= "X Shift"; level_name[Level7]= "X Alt Base"; level_name[Level8]= "X Shift Alt"; }; type "EIGHT_LEVEL_LEVEL_FIVE_LOCK" { modifiers= Shift+Lock+NumLock+LevelThree+LevelFive; map[Shift]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[LevelFive]= Level5; map[Shift+LevelFive]= Level6; preserve[Shift+LevelFive]= Shift; map[LevelThree+LevelFive]= Level7; map[Shift+LevelThree+LevelFive]= Level8; map[NumLock]= Level5; map[Shift+NumLock]= Level6; preserve[Shift+NumLock]= Shift; map[NumLock+LevelThree]= Level7; map[Shift+NumLock+LevelThree]= Level8; map[Shift+NumLock+LevelFive]= Level2; map[NumLock+LevelThree+LevelFive]= Level3; map[Shift+NumLock+LevelThree+LevelFive]= Level4; map[Shift+Lock]= Level2; map[Lock+LevelThree]= Level3; map[Shift+Lock+LevelThree]= Level4; map[Lock+LevelFive]= Level5; map[Shift+Lock+LevelFive]= Level6; preserve[Shift+Lock+LevelFive]= Shift; map[Lock+LevelThree+LevelFive]= Level7; map[Shift+Lock+LevelThree+LevelFive]= Level8; map[Lock+NumLock]= Level5; map[Shift+Lock+NumLock]= Level6; preserve[Shift+Lock+NumLock]= Shift; map[Lock+NumLock+LevelThree]= Level7; map[Shift+Lock+NumLock+LevelThree]= Level8; map[Shift+Lock+NumLock+LevelFive]= Level2; map[Lock+NumLock+LevelThree+LevelFive]= Level3; map[Shift+Lock+NumLock+LevelThree+LevelFive]= Level4; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; level_name[Level5]= "X"; level_name[Level6]= "X Shift"; level_name[Level7]= "X Alt Base"; level_name[Level8]= "X Shift Alt"; }; type "EIGHT_LEVEL_ALPHABETIC_LEVEL_FIVE_LOCK" { modifiers= Shift+Lock+NumLock+LevelThree+LevelFive; map[Shift]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[LevelFive]= Level5; map[Shift+LevelFive]= Level6; preserve[Shift+LevelFive]= Shift; map[LevelThree+LevelFive]= Level7; map[Shift+LevelThree+LevelFive]= Level8; map[NumLock]= Level5; map[Shift+NumLock]= Level6; preserve[Shift+NumLock]= Shift; map[NumLock+LevelThree]= Level7; map[Shift+NumLock+LevelThree]= Level8; map[Shift+NumLock+LevelFive]= Level2; map[NumLock+LevelThree+LevelFive]= Level3; map[Shift+NumLock+LevelThree+LevelFive]= Level4; map[Lock]= Level2; map[Lock+LevelThree]= Level3; map[Shift+Lock+LevelThree]= Level4; map[Lock+LevelFive]= Level5; map[Shift+Lock+LevelFive]= Level6; map[Lock+LevelThree+LevelFive]= Level7; map[Shift+Lock+LevelThree+LevelFive]= Level8; map[Lock+NumLock]= Level5; map[Shift+Lock+NumLock]= Level6; map[Lock+NumLock+LevelThree]= Level7; map[Shift+Lock+NumLock+LevelThree]= Level8; map[Lock+NumLock+LevelFive]= Level2; map[Lock+NumLock+LevelThree+LevelFive]= Level4; map[Shift+Lock+NumLock+LevelThree+LevelFive]= Level3; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; level_name[Level5]= "X"; level_name[Level6]= "X Shift"; level_name[Level7]= "X Alt Base"; level_name[Level8]= "X Shift Alt"; }; type "EIGHT_LEVEL_SEMIALPHABETIC" { modifiers= Shift+Lock+LevelThree+LevelFive; map[Shift]= Level2; map[Lock]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[Lock+LevelThree]= Level3; preserve[Lock+LevelThree]= Lock; map[Shift+Lock+LevelThree]= Level4; preserve[Shift+Lock+LevelThree]= Lock; map[LevelFive]= Level5; map[Shift+LevelFive]= Level6; map[Lock+LevelFive]= Level6; preserve[Lock+LevelFive]= Lock; map[Shift+Lock+LevelFive]= Level6; preserve[Shift+Lock+LevelFive]= Lock; map[LevelThree+LevelFive]= Level7; map[Shift+LevelThree+LevelFive]= Level8; map[Lock+LevelThree+LevelFive]= Level7; preserve[Lock+LevelThree+LevelFive]= Lock; map[Shift+Lock+LevelThree+LevelFive]= Level8; preserve[Shift+Lock+LevelThree+LevelFive]= Lock; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; level_name[Level5]= "X"; level_name[Level6]= "X Shift"; level_name[Level7]= "X Alt Base"; level_name[Level8]= "X Shift Alt"; }; type "FOUR_LEVEL" { modifiers= Shift+LevelThree; map[Shift]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; }; type "FOUR_LEVEL_ALPHABETIC" { modifiers= Shift+Lock+LevelThree; map[Shift]= Level2; map[Lock]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[Lock+LevelThree]= Level4; map[Shift+Lock+LevelThree]= Level3; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; }; type "FOUR_LEVEL_SEMIALPHABETIC" { modifiers= Shift+Lock+LevelThree; map[Shift]= Level2; map[Lock]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[Lock+LevelThree]= Level3; preserve[Lock+LevelThree]= Lock; map[Shift+Lock+LevelThree]= Level4; preserve[Shift+Lock+LevelThree]= Lock; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; }; type "FOUR_LEVEL_MIXED_KEYPAD" { modifiers= Shift+NumLock+LevelThree; map[Shift+NumLock]= Level1; map[NumLock]= Level2; map[Shift]= Level2; map[LevelThree]= Level3; map[NumLock+LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[Shift+NumLock+LevelThree]= Level4; level_name[Level1]= "Base"; level_name[Level2]= "Number"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; }; type "FOUR_LEVEL_X" { modifiers= Shift+Control+Alt+LevelThree; map[LevelThree]= Level2; map[Shift+LevelThree]= Level3; map[Control+Alt]= Level4; level_name[Level1]= "Base"; level_name[Level2]= "Alt Base"; level_name[Level3]= "Shift Alt"; level_name[Level4]= "Ctrl+Alt"; }; type "SEPARATE_CAPS_AND_SHIFT_ALPHABETIC" { modifiers= Shift+Lock+LevelThree; map[Shift]= Level2; map[Lock]= Level4; preserve[Lock]= Lock; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[Lock+LevelThree]= Level3; preserve[Lock+LevelThree]= Lock; map[Shift+Lock+LevelThree]= Level3; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "AltGr Base"; level_name[Level4]= "Shift AltGr"; }; type "FOUR_LEVEL_PLUS_LOCK" { modifiers= Shift+Lock+LevelThree; map[Shift]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[Lock]= Level5; map[Shift+Lock]= Level2; map[Lock+LevelThree]= Level3; map[Shift+Lock+LevelThree]= Level4; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Shift Alt"; level_name[Level5]= "Lock"; }; type "FOUR_LEVEL_KEYPAD" { modifiers= Shift+NumLock+LevelThree; map[Shift]= Level2; map[NumLock]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level4; map[NumLock+LevelThree]= Level4; map[Shift+NumLock+LevelThree]= Level3; level_name[Level1]= "Base"; level_name[Level2]= "Number"; level_name[Level3]= "Alt Base"; level_name[Level4]= "Alt Number"; }; }; xkb_compatibility "complete" { virtual_modifiers NumLock,Alt,LevelThree,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr,Meta,Super,Hyper; interpret.useModMapMods= AnyLevel; interpret.repeat= False; interpret.locking= False; interpret ISO_Level2_Latch+Exactly(Shift) { useModMapMods=level1; action= LatchMods(modifiers=Shift,clearLocks,latchToLock); }; interpret Shift_Lock+AnyOf(Shift+Lock) { action= LockMods(modifiers=Shift); }; interpret Num_Lock+AnyOf(all) { virtualModifier= NumLock; action= LockMods(modifiers=NumLock); }; interpret ISO_Level3_Shift+AnyOf(all) { virtualModifier= LevelThree; useModMapMods=level1; action= SetMods(modifiers=LevelThree,clearLocks); }; interpret ISO_Level3_Latch+AnyOf(all) { virtualModifier= LevelThree; useModMapMods=level1; action= LatchMods(modifiers=LevelThree,clearLocks,latchToLock); }; interpret ISO_Level3_Lock+AnyOf(all) { virtualModifier= LevelThree; useModMapMods=level1; action= LockMods(modifiers=LevelThree); }; interpret Alt_L+AnyOf(all) { virtualModifier= Alt; action= SetMods(modifiers=modMapMods,clearLocks); }; interpret Alt_R+AnyOf(all) { virtualModifier= Alt; action= SetMods(modifiers=modMapMods,clearLocks); }; interpret Meta_L+AnyOf(all) { virtualModifier= Meta; action= SetMods(modifiers=modMapMods,clearLocks); }; interpret Meta_R+AnyOf(all) { virtualModifier= Meta; action= SetMods(modifiers=modMapMods,clearLocks); }; interpret Super_L+AnyOf(all) { virtualModifier= Super; action= SetMods(modifiers=modMapMods,clearLocks); }; interpret Super_R+AnyOf(all) { virtualModifier= Super; action= SetMods(modifiers=modMapMods,clearLocks); }; interpret Hyper_L+AnyOf(all) { virtualModifier= Hyper; action= SetMods(modifiers=modMapMods,clearLocks); }; interpret Hyper_R+AnyOf(all) { virtualModifier= Hyper; action= SetMods(modifiers=modMapMods,clearLocks); }; interpret Scroll_Lock+AnyOf(all) { virtualModifier= ScrollLock; action= LockMods(modifiers=modMapMods); }; interpret ISO_Level5_Shift+AnyOf(all) { virtualModifier= LevelFive; useModMapMods=level1; action= SetMods(modifiers=LevelFive,clearLocks); }; interpret ISO_Level5_Latch+AnyOf(all) { virtualModifier= LevelFive; useModMapMods=level1; action= LatchMods(modifiers=LevelFive,clearLocks,latchToLock); }; interpret ISO_Level5_Lock+AnyOf(all) { virtualModifier= LevelFive; useModMapMods=level1; action= LockMods(modifiers=LevelFive); }; interpret Mode_switch+AnyOfOrNone(all) { virtualModifier= AltGr; useModMapMods=level1; action= SetGroup(group=+1); }; interpret ISO_Level3_Shift+AnyOfOrNone(all) { action= SetMods(modifiers=LevelThree,clearLocks); }; interpret ISO_Level3_Latch+AnyOfOrNone(all) { action= LatchMods(modifiers=LevelThree,clearLocks,latchToLock); }; interpret ISO_Level3_Lock+AnyOfOrNone(all) { action= LockMods(modifiers=LevelThree); }; interpret ISO_Group_Latch+AnyOfOrNone(all) { virtualModifier= AltGr; useModMapMods=level1; action= LatchGroup(group=2); }; interpret ISO_Next_Group+AnyOfOrNone(all) { virtualModifier= AltGr; useModMapMods=level1; action= LockGroup(group=+1); }; interpret ISO_Prev_Group+AnyOfOrNone(all) { virtualModifier= AltGr; useModMapMods=level1; action= LockGroup(group=-1); }; interpret ISO_First_Group+AnyOfOrNone(all) { action= LockGroup(group=1); }; interpret ISO_Last_Group+AnyOfOrNone(all) { action= LockGroup(group=2); }; interpret KP_1+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=-1,y=+1); }; interpret KP_End+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=-1,y=+1); }; interpret KP_2+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+0,y=+1); }; interpret KP_Down+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+0,y=+1); }; interpret KP_3+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+1,y=+1); }; interpret KP_Next+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+1,y=+1); }; interpret KP_4+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=-1,y=+0); }; interpret KP_Left+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=-1,y=+0); }; interpret KP_6+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+1,y=+0); }; interpret KP_Right+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+1,y=+0); }; interpret KP_7+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=-1,y=-1); }; interpret KP_Home+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=-1,y=-1); }; interpret KP_8+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+0,y=-1); }; interpret KP_Up+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+0,y=-1); }; interpret KP_9+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+1,y=-1); }; interpret KP_Prior+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+1,y=-1); }; interpret KP_5+AnyOfOrNone(all) { repeat= True; action= PtrBtn(button=default); }; interpret KP_Begin+AnyOfOrNone(all) { repeat= True; action= PtrBtn(button=default); }; interpret KP_F2+AnyOfOrNone(all) { repeat= True; action= SetPtrDflt(affect=button,button=1); }; interpret KP_Divide+AnyOfOrNone(all) { repeat= True; action= SetPtrDflt(affect=button,button=1); }; interpret KP_F3+AnyOfOrNone(all) { repeat= True; action= SetPtrDflt(affect=button,button=2); }; interpret KP_Multiply+AnyOfOrNone(all) { repeat= True; action= SetPtrDflt(affect=button,button=2); }; interpret KP_F4+AnyOfOrNone(all) { repeat= True; action= SetPtrDflt(affect=button,button=3); }; interpret KP_Subtract+AnyOfOrNone(all) { repeat= True; action= SetPtrDflt(affect=button,button=3); }; interpret KP_Separator+AnyOfOrNone(all) { repeat= True; action= PtrBtn(button=default,count=2); }; interpret KP_Add+AnyOfOrNone(all) { repeat= True; action= PtrBtn(button=default,count=2); }; interpret KP_0+AnyOfOrNone(all) { repeat= True; action= LockPtrBtn(button=default,affect=lock); }; interpret KP_Insert+AnyOfOrNone(all) { repeat= True; action= LockPtrBtn(button=default,affect=lock); }; interpret KP_Decimal+AnyOfOrNone(all) { repeat= True; action= LockPtrBtn(button=default,affect=unlock); }; interpret KP_Delete+AnyOfOrNone(all) { repeat= True; action= LockPtrBtn(button=default,affect=unlock); }; interpret F25+AnyOfOrNone(all) { repeat= True; action= SetPtrDflt(affect=button,button=1); }; interpret F26+AnyOfOrNone(all) { repeat= True; action= SetPtrDflt(affect=button,button=2); }; interpret F27+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=-1,y=-1); }; interpret F29+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+1,y=-1); }; interpret F31+AnyOfOrNone(all) { repeat= True; action= PtrBtn(button=default); }; interpret F33+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=-1,y=+1); }; interpret F35+AnyOfOrNone(all) { repeat= True; action= MovePtr(x=+1,y=+1); }; interpret Pointer_Button_Dflt+AnyOfOrNone(all) { action= PtrBtn(button=default); }; interpret Pointer_Button1+AnyOfOrNone(all) { action= PtrBtn(button=1); }; interpret Pointer_Button2+AnyOfOrNone(all) { action= PtrBtn(button=2); }; interpret Pointer_Button3+AnyOfOrNone(all) { action= PtrBtn(button=3); }; interpret Pointer_DblClick_Dflt+AnyOfOrNone(all) { action= PtrBtn(button=default,count=2); }; interpret Pointer_DblClick1+AnyOfOrNone(all) { action= PtrBtn(button=1,count=2); }; interpret Pointer_DblClick2+AnyOfOrNone(all) { action= PtrBtn(button=2,count=2); }; interpret Pointer_DblClick3+AnyOfOrNone(all) { action= PtrBtn(button=3,count=2); }; interpret Pointer_Drag_Dflt+AnyOfOrNone(all) { action= LockPtrBtn(button=default,affect=both); }; interpret Pointer_Drag1+AnyOfOrNone(all) { action= LockPtrBtn(button=1,affect=both); }; interpret Pointer_Drag2+AnyOfOrNone(all) { action= LockPtrBtn(button=2,affect=both); }; interpret Pointer_Drag3+AnyOfOrNone(all) { action= LockPtrBtn(button=3,affect=both); }; interpret Pointer_EnableKeys+AnyOfOrNone(all) { action= LockControls(controls=MouseKeys); }; interpret Pointer_Accelerate+AnyOfOrNone(all) { action= LockControls(controls=MouseKeysAccel); }; interpret Pointer_DfltBtnNext+AnyOfOrNone(all) { action= SetPtrDflt(affect=button,button=+1); }; interpret Pointer_DfltBtnPrev+AnyOfOrNone(all) { action= SetPtrDflt(affect=button,button=-1); }; interpret AccessX_Enable+AnyOfOrNone(all) { action= LockControls(controls=AccessXKeys); }; interpret AccessX_Feedback_Enable+AnyOfOrNone(all) { action= LockControls(controls=AccessXFeedback); }; interpret RepeatKeys_Enable+AnyOfOrNone(all) { action= LockControls(controls=RepeatKeys); }; interpret SlowKeys_Enable+AnyOfOrNone(all) { action= LockControls(controls=SlowKeys); }; interpret BounceKeys_Enable+AnyOfOrNone(all) { action= LockControls(controls=BounceKeys); }; interpret StickyKeys_Enable+AnyOfOrNone(all) { action= LockControls(controls=StickyKeys); }; interpret MouseKeys_Enable+AnyOfOrNone(all) { action= LockControls(controls=MouseKeys); }; interpret MouseKeys_Accel_Enable+AnyOfOrNone(all) { action= LockControls(controls=MouseKeysAccel); }; interpret Overlay1_Enable+AnyOfOrNone(all) { action= LockControls(controls=Overlay1); }; interpret Overlay2_Enable+AnyOfOrNone(all) { action= LockControls(controls=Overlay2); }; interpret AudibleBell_Enable+AnyOfOrNone(all) { action= LockControls(controls=AudibleBell); }; interpret Terminate_Server+AnyOfOrNone(all) { action= Terminate(); }; interpret Alt_L+AnyOfOrNone(all) { action= SetMods(modifiers=Alt,clearLocks); }; interpret Alt_R+AnyOfOrNone(all) { action= SetMods(modifiers=Alt,clearLocks); }; interpret Meta_L+AnyOfOrNone(all) { action= SetMods(modifiers=Meta,clearLocks); }; interpret Meta_R+AnyOfOrNone(all) { action= SetMods(modifiers=Meta,clearLocks); }; interpret Super_L+AnyOfOrNone(all) { action= SetMods(modifiers=Super,clearLocks); }; interpret Super_R+AnyOfOrNone(all) { action= SetMods(modifiers=Super,clearLocks); }; interpret Hyper_L+AnyOfOrNone(all) { action= SetMods(modifiers=Hyper,clearLocks); }; interpret Hyper_R+AnyOfOrNone(all) { action= SetMods(modifiers=Hyper,clearLocks); }; interpret Shift_L+AnyOfOrNone(all) { action= SetMods(modifiers=Shift,clearLocks); }; interpret XF86Switch_VT_1+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=1,!same); }; interpret XF86Switch_VT_2+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=2,!same); }; interpret XF86Switch_VT_3+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=3,!same); }; interpret XF86Switch_VT_4+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=4,!same); }; interpret XF86Switch_VT_5+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=5,!same); }; interpret XF86Switch_VT_6+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=6,!same); }; interpret XF86Switch_VT_7+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=7,!same); }; interpret XF86Switch_VT_8+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=8,!same); }; interpret XF86Switch_VT_9+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=9,!same); }; interpret XF86Switch_VT_10+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=10,!same); }; interpret XF86Switch_VT_11+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=11,!same); }; interpret XF86Switch_VT_12+AnyOfOrNone(all) { repeat= True; action= SwitchScreen(screen=12,!same); }; interpret XF86LogGrabInfo+AnyOfOrNone(all) { repeat= True; action= Private(type=0x86,data[0]=0x50,data[1]=0x72,data[2]=0x47,data[3]=0x72,data[4]=0x62,data[5]=0x73,data[6]=0x00); }; interpret XF86LogWindowTree+AnyOfOrNone(all) { repeat= True; action= Private(type=0x86,data[0]=0x50,data[1]=0x72,data[2]=0x57,data[3]=0x69,data[4]=0x6e,data[5]=0x73,data[6]=0x00); }; interpret XF86Next_VMode+AnyOfOrNone(all) { repeat= True; action= Private(type=0x86,data[0]=0x2b,data[1]=0x56,data[2]=0x4d,data[3]=0x6f,data[4]=0x64,data[5]=0x65,data[6]=0x00); }; interpret XF86Prev_VMode+AnyOfOrNone(all) { repeat= True; action= Private(type=0x86,data[0]=0x2d,data[1]=0x56,data[2]=0x4d,data[3]=0x6f,data[4]=0x64,data[5]=0x65,data[6]=0x00); }; interpret ISO_Level5_Shift+AnyOfOrNone(all) { action= SetMods(modifiers=LevelFive,clearLocks); }; interpret ISO_Level5_Latch+AnyOfOrNone(all) { action= LatchMods(modifiers=LevelFive,clearLocks,latchToLock); }; interpret ISO_Level5_Lock+AnyOfOrNone(all) { action= LockMods(modifiers=LevelFive); }; interpret Caps_Lock+AnyOfOrNone(all) { action= LockMods(modifiers=Lock); }; interpret Any+Exactly(Lock) { action= LockMods(modifiers=Lock); }; interpret Any+AnyOf(all) { action= SetMods(modifiers=modMapMods,clearLocks); }; group 2 = AltGr; group 3 = AltGr; group 4 = AltGr; indicator "Caps Lock" { !allowExplicit; whichModState= locked; modifiers= Lock; }; indicator "Num Lock" { !allowExplicit; whichModState= locked; modifiers= NumLock; }; indicator "Scroll Lock" { whichModState= locked; modifiers= ScrollLock; }; indicator "Shift Lock" { !allowExplicit; whichModState= locked; modifiers= Shift; }; indicator "Group 2" { !allowExplicit; groups= 0xfe; }; indicator "Mouse Keys" { indicatorDrivesKeyboard; controls= mouseKeys; }; }; xkb_symbols "us(dvorak)+pc(pc105)" { name[group1]="English (Dvorak)"; key <ESC> { [ Escape ] }; key <AE01> { [ 1, exclam ] }; key <AE02> { [ 2, at ] }; key <AE03> { [ 3, numbersign ] }; key <AE04> { [ 4, dollar ] }; key <AE05> { [ 5, percent ] }; key <AE06> { type= "FOUR_LEVEL", symbols[Group1]= [ 6, asciicircum, dead_circumflex, dead_circumflex ] }; key <AE07> { [ 7, ampersand ] }; key <AE08> { [ 8, asterisk ] }; key <AE09> { type= "FOUR_LEVEL", symbols[Group1]= [ 9, parenleft, dead_grave, dead_breve ] }; key <AE10> { [ 0, parenright ] }; key <AE11> { [ bracketleft, braceleft ] }; key <AE12> { type= "FOUR_LEVEL", symbols[Group1]= [ bracketright, braceright, dead_tilde, NoSymbol ] }; key <BKSP> { [ BackSpace, BackSpace ] }; key <TAB> { [ Tab, ISO_Left_Tab ] }; key <AD01> { type= "FOUR_LEVEL", symbols[Group1]= [ apostrophe, quotedbl, dead_acute, dead_diaeresis ] }; key <AD02> { type= "FOUR_LEVEL", symbols[Group1]= [ comma, less, dead_cedilla, dead_caron ] }; key <AD03> { type= "FOUR_LEVEL", symbols[Group1]= [ period, greater, dead_abovedot, periodcentered ] }; key <AD04> { type= "ALPHABETIC", symbols[Group1]= [ p, P ] }; key <AD05> { type= "ALPHABETIC", symbols[Group1]= [ y, Y ] }; key <AD06> { type= "ALPHABETIC", symbols[Group1]= [ f, F ] }; key <AD07> { type= "ALPHABETIC", symbols[Group1]= [ g, G ] }; key <AD08> { type= "ALPHABETIC", symbols[Group1]= [ c, C ] }; key <AD09> { type= "ALPHABETIC", symbols[Group1]= [ r, R ] }; key <AD10> { type= "ALPHABETIC", symbols[Group1]= [ l, L ] }; key <AD11> { [ slash, question ] }; key <AD12> { [ equal, plus ] }; key <RTRN> { [ Return ] }; key <LCTL> { [ Control_L ] }; key <AC01> { type= "ALPHABETIC", symbols[Group1]= [ a, A ] }; key <AC02> { type= "ALPHABETIC", symbols[Group1]= [ o, O ] }; key <AC03> { type= "ALPHABETIC", symbols[Group1]= [ e, E ] }; key <AC04> { type= "ALPHABETIC", symbols[Group1]= [ u, U ] }; key <AC05> { type= "ALPHABETIC", symbols[Group1]= [ i, I ] }; key <AC06> { type= "ALPHABETIC", symbols[Group1]= [ d, D ] }; key <AC07> { type= "ALPHABETIC", symbols[Group1]= [ h, H ] }; key <AC08> { type= "ALPHABETIC", symbols[Group1]= [ t, T ] }; key <AC09> { type= "ALPHABETIC", symbols[Group1]= [ n, N ] }; key <AC10> { type= "ALPHABETIC", symbols[Group1]= [ s, S ] }; key <AC11> { [ minus, underscore ] }; key <TLDE> { type= "FOUR_LEVEL", symbols[Group1]= [ grave, asciitilde, dead_grave, dead_tilde ] }; key <LFSH> { [ Shift_L ] }; key <BKSL> { [ backslash, bar ] }; key <AB01> { type= "FOUR_LEVEL", symbols[Group1]= [ semicolon, colon, dead_ogonek, dead_doubleacute ] }; key <AB02> { type= "ALPHABETIC", symbols[Group1]= [ q, Q ] }; key <AB03> { type= "ALPHABETIC", symbols[Group1]= [ j, J ] }; key <AB04> { type= "ALPHABETIC", symbols[Group1]= [ k, K ] }; key <AB05> { type= "ALPHABETIC", symbols[Group1]= [ x, X ] }; key <AB06> { type= "ALPHABETIC", symbols[Group1]= [ b, B ] }; key <AB07> { type= "ALPHABETIC", symbols[Group1]= [ m, M ] }; key <AB08> { type= "ALPHABETIC", symbols[Group1]= [ w, W ] }; key <AB09> { type= "ALPHABETIC", symbols[Group1]= [ v, V ] }; key <AB10> { type= "ALPHABETIC", symbols[Group1]= [ z, Z ] }; key <RTSH> { [ Shift_R ] }; key <KPMU> { type= "CTRL+ALT", symbols[Group1]= [ KP_Multiply, KP_Multiply, KP_Multiply, KP_Multiply, XF86ClearGrab ] }; key <LALT> { [ Alt_L, Meta_L ] }; key <SPCE> { [ space ] }; key <CAPS> { [ Caps_Lock ] }; key <FK01> { type= "CTRL+ALT", symbols[Group1]= [ F1, F1, F1, F1, XF86Switch_VT_1 ] }; key <FK02> { type= "CTRL+ALT", symbols[Group1]= [ F2, F2, F2, F2, XF86Switch_VT_2 ] }; key <FK03> { type= "CTRL+ALT", symbols[Group1]= [ F3, F3, F3, F3, XF86Switch_VT_3 ] }; key <FK04> { type= "CTRL+ALT", symbols[Group1]= [ F4, F4, F4, F4, XF86Switch_VT_4 ] }; key <FK05> { type= "CTRL+ALT", symbols[Group1]= [ F5, F5, F5, F5, XF86Switch_VT_5 ] }; key <FK06> { type= "CTRL+ALT", symbols[Group1]= [ F6, F6, F6, F6, XF86Switch_VT_6 ] }; key <FK07> { type= "CTRL+ALT", symbols[Group1]= [ F7, F7, F7, F7, XF86Switch_VT_7 ] }; key <FK08> { type= "CTRL+ALT", symbols[Group1]= [ F8, F8, F8, F8, XF86Switch_VT_8 ] }; key <FK09> { type= "CTRL+ALT", symbols[Group1]= [ F9, F9, F9, F9, XF86Switch_VT_9 ] }; key <FK10> { type= "CTRL+ALT", symbols[Group1]= [ F10, F10, F10, F10, XF86Switch_VT_10 ] }; key <NMLK> { [ Num_Lock ] }; key <SCLK> { [ Scroll_Lock ] }; key <KP7> { [ KP_Home, KP_7 ] }; key <KP8> { [ KP_Up, KP_8 ] }; key <KP9> { [ KP_Prior, KP_9 ] }; key <KPSU> { type= "CTRL+ALT", symbols[Group1]= [ KP_Subtract, KP_Subtract, KP_Subtract, KP_Subtract, XF86Prev_VMode ] }; key <KP4> { [ KP_Left, KP_4 ] }; key <KP5> { [ KP_Begin, KP_5 ] }; key <KP6> { [ KP_Right, KP_6 ] }; key <KPAD> { type= "CTRL+ALT", symbols[Group1]= [ KP_Add, KP_Add, KP_Add, KP_Add, XF86Next_VMode ] }; key <KP1> { [ KP_End, KP_1 ] }; key <KP2> { [ KP_Down, KP_2 ] }; key <KP3> { [ KP_Next, KP_3 ] }; key <KP0> { [ KP_Insert, KP_0 ] }; key <KPDL> { [ KP_Delete, KP_Decimal ] }; key <LVL3> { [ ISO_Level3_Shift ] }; key <LSGT> { type= "FOUR_LEVEL", symbols[Group1]= [ less, greater, bar, brokenbar ] }; key <FK11> { type= "CTRL+ALT", symbols[Group1]= [ F11, F11, F11, F11, XF86Switch_VT_11 ] }; key <FK12> { type= "CTRL+ALT", symbols[Group1]= [ F12, F12, F12, F12, XF86Switch_VT_12 ] }; key <KPEN> { [ KP_Enter ] }; key <RCTL> { [ Control_R ] }; key <KPDV> { type= "CTRL+ALT", symbols[Group1]= [ KP_Divide, KP_Divide, KP_Divide, KP_Divide, XF86Ungrab ] }; key <PRSC> { type= "PC_ALT_LEVEL2", symbols[Group1]= [ Print, Sys_Req ] }; key <RALT> { type= "TWO_LEVEL", symbols[Group1]= [ Alt_R, Meta_R ] }; key <HOME> { [ Home ] }; key <UP> { [ Up ] }; key <PGUP> { [ Prior ] }; key <LEFT> { [ Left ] }; key <RGHT> { [ Right ] }; key <END> { [ End ] }; key <DOWN> { [ Down ] }; key <PGDN> { [ Next ] }; key <INS> { [ Insert ] }; key <DELE> { [ Delete ] }; key <KPEQ> { [ KP_Equal ] }; key <PAUS> { type= "PC_CONTROL_LEVEL2", symbols[Group1]= [ Pause, Break ] }; key <I129> { [ KP_Decimal, KP_Decimal ] }; key <LWIN> { [ Super_L ] }; key <RWIN> { [ Super_R ] }; key <COMP> { [ Menu ] }; key <MDSW> { [ Mode_switch ] }; key <ALT> { [ NoSymbol, Alt_L ] }; key <META> { [ NoSymbol, Meta_L ] }; key <SUPR> { [ NoSymbol, Super_L ] }; key <HYPR> { [ NoSymbol, Hyper_L ] }; key <I235> { [ XF86Display ] }; key <I236> { [ XF86KbdLightOnOff ] }; key <I237> { [ XF86KbdBrightnessDown ] }; key <I238> { [ XF86KbdBrightnessUp ] }; modifier_map Control { <LCTL> }; modifier_map Shift { <LFSH> }; modifier_map Shift { <RTSH> }; modifier_map Mod1 { <LALT> }; modifier_map Lock { <CAPS> }; modifier_map Mod2 { <NMLK> }; modifier_map Mod5 { <LVL3> }; modifier_map Control { <RCTL> }; modifier_map Mod1 { <RALT> }; modifier_map Mod4 { <LWIN> }; modifier_map Mod4 { <RWIN> }; modifier_map Mod5 { <MDSW> }; modifier_map Mod1 { <META> }; modifier_map Mod4 { <SUPR> }; modifier_map Mod4 { <HYPR> }; }; }; ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-07-28 1:39 ` Akira Kyle @ 2022-07-28 2:50 ` Po Lu 0 siblings, 0 replies; 48+ messages in thread From: Po Lu @ 2022-07-28 2:50 UTC (permalink / raw) To: Akira Kyle; +Cc: Trey Peacock, Morgan Smith, emacs-devel Akira Kyle <akira@akirakyle.com> writes: > I'm not totally convinced, since sway should just be using the .xkb > file I specify. The relevant code is in sway/input/keyboard.c where it > uses the .xkb file in sway_keyboard_compile_keymap which then sway > sets using wlr_keyboard_set_keymap inside > sway_keyboard_configure. So this should be the same keymap that GTK is > using. It would be nice if you (or someone else) set a breakpoint here: ->if (mods & (1 << xkb_keymap_mod_get_index (xkb_keymap, "Super"))) state |= GDK_SUPER_MASK; in the GDK source code to see what real modifier gets returned under Sway. TIA. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions
@ 2022-04-20 7:52 Trey Peacock
2022-04-20 8:25 ` Po Lu
0 siblings, 1 reply; 48+ messages in thread
From: Trey Peacock @ 2022-04-20 7:52 UTC (permalink / raw)
To: Po Lu; +Cc: Morgan Smith, emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 3202 bytes --]
"Po Lu" <luangruo@yahoo.com> writes:
> Trey Peacock <gpg@treypeacock.com> writes:
>
>>> 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.
>
> It's the documented behavior of GDK, and Emacs holds GDK to its
> documentation. Nowhere does the documentation say this is a
> "capability", "recognizes" is in the third-person present tense, which
> makes it a requirement.
>
>> 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.
>
> Great, one step forward would be to bring up the issue with either the
> GTK or Wayland compositor developers. Since you've already talked with
> the latter, and they say it's not their problem, please contact the
> former.
>
>> 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.
>
> It is, as specified in its documentation.
>
>> Your change seems to have removed a fallback in case there were no
>> virtual modifiers and reverses the previous logic:
>
> As you can see by the name of the function, it was directly ported over
> from X (the current version is in xterm.c), and is yet another example
> of the PGTK port translating X Windows code to GDK verbatim, duplicating
> what GDK is supposed to do itself.
>
> I will not change Emacs because the GTK developers, yet again, forgot to
> follow their own documentation when implementing some feature. It just
> makes Emacs code bloated, hard-to-follow and liable to break at the
> slightest whim of the GTK developers, who then respond that we're not
> using GTK "properly", because we try to work around their problems.
You have already changed Emacs from accepting both MOD4 and SUPER_MASK
as its Super key modifiers to only accepting SUPER_MASK. I imagine this
response is born of more than just this issue but I would not let it
cloud an easy solution.
GTK 3.24.33 still accepts Mod2-5 masks, recognizes them separately from
the virtual modifier masks, and unlike the x11 implementation does not
contain the logic to set convert Super_L or Super_R to GDK_SUPER_MASK.
So what you have done is actually held Emacs to GDK's x11
implementation and documentation rather than looking at the code itself.
https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/wayland/gdkkeys-wayland.c#L249-316
https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/x11/gdkkeys-x11.c#L396-398
If the PGTK branch is meant for "alternative window systems available on
GNU/Linux and some Unix systems, such as Wayland" then I do think there
should be more consideration taken compositors that do not share
Mutter's workaround. Had you been using any other compositor, surely you
would not have made this change. Perhaps even filing a bug yourself.
This will be my last comment on the matter as I don't think its
productive for either of us to belabor our points.
[-- Attachment #1.2: publickey - gpg@treypeacock.com - da008078.asc --]
[-- Type: application/pgp-keys, Size: 1339 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: PGTK-related misconceptions 2022-04-20 7:52 Trey Peacock @ 2022-04-20 8:25 ` Po Lu 2022-04-20 13:13 ` Brian Cully 0 siblings, 1 reply; 48+ messages in thread From: Po Lu @ 2022-04-20 8:25 UTC (permalink / raw) To: Trey Peacock; +Cc: Morgan Smith, emacs-devel Trey Peacock <gpg@treypeacock.com> writes: > You have already changed Emacs from accepting both MOD4 and SUPER_MASK > as its Super key modifiers to only accepting SUPER_MASK. I imagine > this response is born of more than just this issue but I would not let > it cloud an easy solution. First of all, the GDK_MODN_MASKs (aside from GDK_MOD1_MASK) are simply not set on Broadway, the other GDK backend that we try to support. Secondly, nothing is guaranteed about the behavior of the real modifier masks after GDK_MOD1_MASK. We cannot assume it means Super at all, since it is not documented to mean that. What if GDK changes its meaning in the future? Or the Wayland compositor developers? I am not going to settle for non-solutions (or half-solutions) like what you proposed, at least unless the GTK developers still haven't fixed this by the time Emacs 29.1 is released. > GTK 3.24.33 still accepts Mod2-5 masks, recognizes them separately > from the virtual modifier masks, and unlike the x11 implementation > does not contain the logic to set convert Super_L or Super_R to > GDK_SUPER_MASK. So what you have done is actually held Emacs to GDK's > x11 implementation and documentation rather than looking at the code > itself. Nowhere in the documentation for GdkModifierType does it say that the automatic mapping from real modifiers to virtual modifiers is X11-specific, so this is clearly a GTK bug. I'm pretty sure GTK accelerators that specify <Super> as a modifier will not work on those other Wayland compositors either, if what you say is true. > If the PGTK branch is meant for "alternative window systems available > on GNU/Linux and some Unix systems, such as Wayland" then I do think > there should be more consideration taken compositors that do not share > Mutter's workaround. Had you been using any other compositor, surely > you would not have made this change. Perhaps even filing a bug > yourself. I would still have made this change and then proceeded to ask someone else to report a GTK bug. I can't do that myself, since GNOME has been persistently been making it more and more difficult to report bugs without registering an account on whatever platform they currently use for bug reports, and putting up with the associated e-mail spam. But I don't use any other Wayland compositors, so that point is moot. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-20 8:25 ` Po Lu @ 2022-04-20 13:13 ` Brian Cully 0 siblings, 0 replies; 48+ messages in thread From: Brian Cully @ 2022-04-20 13:13 UTC (permalink / raw) To: Po Lu; +Cc: Morgan Smith, Trey Peacock, emacs-devel Po Lu <luangruo@yahoo.com> writes: > Nowhere in the documentation for GdkModifierType does it say that the > automatic mapping from real modifiers to virtual modifiers is > X11-specific, so this is clearly a GTK bug. I'm pretty sure GTK > accelerators that specify <Super> as a modifier will not work on those > other Wayland compositors either, if what you say is true. FWIW, using the PGTK branch under Wayland, the <Super> modifier works correctly with KDE Plasma, but not Sway. -bjc ^ permalink raw reply [flat|nested] 48+ messages in thread
[parent not found: <DM5PR03MB3163BBCF9626AD3B88900011C5EE9@DM5PR03MB3163.namprd03.prod.outlook.com>]
* PGTK-related misconceptions [not found] <DM5PR03MB3163BBCF9626AD3B88900011C5EE9@DM5PR03MB3163.namprd03.prod.outlook.com> @ 2022-04-15 2:29 ` Po Lu 2022-04-15 7:11 ` Byung-Hee HWANG ` (3 more replies) 0 siblings, 4 replies; 48+ messages in thread From: Po Lu @ 2022-04-15 2:29 UTC (permalink / raw) To: Morgan Smith; +Cc: emacs-devel Morgan Smith <morgan.j.smith@outlook.com> writes: > I'd like to report that my super key stopped registering. I suspected > commit 1404e16975 caused it so I did a quick `git revert 1404e16975` > ontop of 807682de1e and that fixed it. Crystal ball says you are using X Windows, and have to put remove mod4 = Hyper_L in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11 Emacs to work around the common kind of virtual modifier misconfiguration. People using X should _never_ use PGTK. The regular X build does a much better job at supporting that than PGTK ever will. It is completely pointless to put up with half-working child frames, random keyboard-related lossage, random frame placement/resizing failures, so the actual fix is to delete `--with-pgtk' from your calls to configure. Similarly, people building packages with PGTK enabled that are labeled "enhanced" are doing their users a disservice. No packager should enable PGTK by default, and every package should ideally come with a big disclaimer warning against using PGTK on window systems otherwise supported by Emacs, since time and experience shows that Emacs generally does a much better job at their support than GTK. Many people are also being mislead by articles on the internet claiming that PGTK leads to faster redisplay, such as this one: http://www.cesarolea.com/posts/emacs-native-compile That is not true, since regular Emacs with cairo uses more-or-less the same rendering path as PGTK, except when PGTK runs on Wayland, where it uses software rendering and does image compositing in software, and is thus slower than everything else. Scrolling on PGTK is also not as efficient as XCopyArea requests. But the difference in speed even on Wayland is negligible, not easy to benchmark, and not at all visible to the human eye. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-15 2:29 ` Po Lu @ 2022-04-15 7:11 ` Byung-Hee HWANG 2022-04-15 16:24 ` Eric Abrahamsen ` (2 subsequent siblings) 3 siblings, 0 replies; 48+ messages in thread From: Byung-Hee HWANG @ 2022-04-15 7:11 UTC (permalink / raw) To: emacs-devel Po Lu <luangruo@yahoo.com> writes: > (...thanks...) > People using X should _never_ use PGTK. ... +9999; REALLY, i am of the same opinion! Sincerely, Gnus fan Byung-Hee -- ^고맙습니다 _救濟蒼生_ 감사합니다_^))// ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-15 2:29 ` Po Lu 2022-04-15 7:11 ` Byung-Hee HWANG @ 2022-04-15 16:24 ` Eric Abrahamsen 2022-04-18 5:18 ` Sean Whitton 2022-04-19 9:10 ` Dirk-Jan C. Binnema 3 siblings, 0 replies; 48+ messages in thread From: Eric Abrahamsen @ 2022-04-15 16:24 UTC (permalink / raw) To: emacs-devel Po Lu <luangruo@yahoo.com> writes: > Morgan Smith <morgan.j.smith@outlook.com> writes: > >> I'd like to report that my super key stopped registering. I suspected >> commit 1404e16975 caused it so I did a quick `git revert 1404e16975` >> ontop of 807682de1e and that fixed it. > > Crystal ball says you are using X Windows, and have to put > > remove mod4 = Hyper_L > > in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11 > Emacs to work around the common kind of virtual modifier > misconfiguration. > > People using X should _never_ use PGTK. The regular X build does a much > better job at supporting that than PGTK ever will. Hey, thanks for this! I'd set --with-pgtk on my X11 machine ages ago, not even knowing why, and reconfiguring without that flag solved my problems with "C-;" being received as plain ";" (and some other funky key misreadings). This is why we don't copy-n-paste config! Thanks again, Eric ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-15 2:29 ` Po Lu 2022-04-15 7:11 ` Byung-Hee HWANG 2022-04-15 16:24 ` Eric Abrahamsen @ 2022-04-18 5:18 ` Sean Whitton 2022-04-18 5:31 ` Po Lu 2022-04-19 9:10 ` Dirk-Jan C. Binnema 3 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2022-04-18 5:18 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel Hello, On Fri 15 Apr 2022 at 10:29am +08, Po Lu wrote: > People using X should _never_ use PGTK. The regular X build does a much > better job at supporting that than PGTK ever will. The discussion of pgtk in INSTALL doesn't say this. If I was packaging Emacs for a distro I think I could be misled into thinking I should replace my gtk package with pgtk. But in fact I should supply both. Here is a very simple suggested addition: > diff --git a/INSTALL b/INSTALL > index b1e3c72c4b..6cbd74ed55 100644 > --- a/INSTALL > +++ b/INSTALL > @@ -253,6 +253,10 @@ to force GTK+ to run under Broadway, start Emacs like this: > > (where '...' denotes any further options you may want to pass to Emacs). > > +If you use X exclusively, do not use the PGTK port. There are a > +number of respects in which the regular --with-x-toolkit=gtk build > +works better. > + > The GNUstep build also supports the Wayland window system. If that is > what you want, see nextstep/INSTALL. -- Sean Whitton ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-18 5:18 ` Sean Whitton @ 2022-04-18 5:31 ` Po Lu 2022-04-18 5:43 ` Sean Whitton 0 siblings, 1 reply; 48+ messages in thread From: Po Lu @ 2022-04-18 5:31 UTC (permalink / raw) To: Sean Whitton; +Cc: emacs-devel Sean Whitton <spwhitton@spwhitton.name> writes: > Hello, > > On Fri 15 Apr 2022 at 10:29am +08, Po Lu wrote: > >> People using X should _never_ use PGTK. The regular X build does a much >> better job at supporting that than PGTK ever will. > > The discussion of pgtk in INSTALL doesn't say this. If I was packaging > Emacs for a distro I think I could be misled into thinking I should > replace my gtk package with pgtk. But in fact I should supply both. INSTALL already recommends PGTK only for using alternative window systems, not X, which is explained first. Thanks. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-18 5:31 ` Po Lu @ 2022-04-18 5:43 ` Sean Whitton 2022-04-18 5:57 ` Po Lu 0 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2022-04-18 5:43 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel Hello, On Mon 18 Apr 2022 at 01:31pm +08, Po Lu wrote: > Sean Whitton <spwhitton@spwhitton.name> writes: > >> Hello, >> >> On Fri 15 Apr 2022 at 10:29am +08, Po Lu wrote: >> >>> People using X should _never_ use PGTK. The regular X build does a much >>> better job at supporting that than PGTK ever will. >> >> The discussion of pgtk in INSTALL doesn't say this. If I was packaging >> Emacs for a distro I think I could be misled into thinking I should >> replace my gtk package with pgtk. But in fact I should supply both. > > INSTALL already recommends PGTK only for using alternative window > systems, not X, which is explained first. It recommends it /for/ using alternative window systems, not /only for/ using alternative window systems, so far as I can tell. For example With the PGTK build, you will be able to switch between running Emacs on X, Wayland and Broadway using the 'GDK_BACKEND' environment variable. really makes it sound like it's find to use it if you're using only X. -- Sean Whitton ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-18 5:43 ` Sean Whitton @ 2022-04-18 5:57 ` Po Lu 2022-04-18 18:27 ` Sean Whitton 2022-04-18 19:49 ` Jim Porter 0 siblings, 2 replies; 48+ messages in thread From: Po Lu @ 2022-04-18 5:57 UTC (permalink / raw) To: Sean Whitton; +Cc: emacs-devel Sean Whitton <spwhitton@spwhitton.name> writes: > It recommends it /for/ using alternative window systems, not /only for/ > using alternative window systems, so far as I can tell. For example > > With the PGTK build, you will be able to switch between running > Emacs on X, Wayland and Broadway using the 'GDK_BACKEND' environment > variable. > > really makes it sound like it's find to use it if you're using only X. I don't see a difference between "for" and "only for" in this case, because above the section talking about PGTK (and also in the details below) is a large amount of commentary discussing the regular X build. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-18 5:57 ` Po Lu @ 2022-04-18 18:27 ` Sean Whitton 2022-04-18 19:49 ` Jim Porter 1 sibling, 0 replies; 48+ messages in thread From: Sean Whitton @ 2022-04-18 18:27 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel Hello, On Mon 18 Apr 2022 at 01:57PM +08, Po Lu wrote: > Sean Whitton <spwhitton@spwhitton.name> writes: > >> It recommends it /for/ using alternative window systems, not /only for/ >> using alternative window systems, so far as I can tell. For example >> >> With the PGTK build, you will be able to switch between running >> Emacs on X, Wayland and Broadway using the 'GDK_BACKEND' environment >> variable. >> >> really makes it sound like it's find to use it if you're using only X. > > I don't see a difference between "for" and "only for" in this case, > because above the section talking about PGTK (and also in the details > below) is a large amount of commentary discussing the regular X build. Well, I can only reiterate that on my reading the file does not clearly express the idea that PGTK should be avoided if you don't absolutely require it. And I'm someone relatively familiar with PGTK. I can easily imagine us seeing distros replacing the package emacs-gtk with emacs-pgtk on the assumption that it is a straight upgrade. It will be hard to undo that. You mentioned that various blog posts give people the wrong idea. We could decide to make the point extra clearly in INSTALL for the sake of counteracting a misconception that is continuing to spread, and is showing no signs of stopping. -- Sean Whitton ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-18 5:57 ` Po Lu 2022-04-18 18:27 ` Sean Whitton @ 2022-04-18 19:49 ` Jim Porter 2022-04-19 1:02 ` Po Lu 2022-04-19 2:18 ` Tim Cross 1 sibling, 2 replies; 48+ messages in thread From: Jim Porter @ 2022-04-18 19:49 UTC (permalink / raw) To: Po Lu, Sean Whitton; +Cc: emacs-devel On 4/17/2022 10:57 PM, Po Lu wrote: > Sean Whitton <spwhitton@spwhitton.name> writes: > >> It recommends it /for/ using alternative window systems, not /only for/ >> using alternative window systems, so far as I can tell. For example >> >> With the PGTK build, you will be able to switch between running >> Emacs on X, Wayland and Broadway using the 'GDK_BACKEND' environment >> variable. >> >> really makes it sound like it's find to use it if you're using only X. > > I don't see a difference between "for" and "only for" in this case, > because above the section talking about PGTK (and also in the details > below) is a large amount of commentary discussing the regular X build. Reading through these sections of INSTALL, I found it very easy to assume that PGTK was a direct upgrade that would just let me "switch between running Emacs on X, Wayland and Broadway". An extremely-careful reader might then wonder why "--with-pgtk" isn't enabled by default on systems with the necessary dependencies, but that only *implies* that there are downsides to PGTK rather than stating it. I think it would be best to state explicitly that there are problems with the PGTK build, though INSTALL probably doesn't need to go into any more detail than that. In practice, a lot of people will probably just skim the documentation, so they might miss some of the more subtle points unless they're very clearly called out. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-18 19:49 ` Jim Porter @ 2022-04-19 1:02 ` Po Lu 2022-04-19 2:46 ` Sean Whitton 2022-04-19 2:18 ` Tim Cross 1 sibling, 1 reply; 48+ messages in thread From: Po Lu @ 2022-04-19 1:02 UTC (permalink / raw) To: Jim Porter; +Cc: Sean Whitton, emacs-devel Jim Porter <jporterbugs@gmail.com> writes: > Reading through these sections of INSTALL, I found it very easy to > assume that PGTK was a direct upgrade that would just let me "switch > between running Emacs on X, Wayland and Broadway". An > extremely-careful reader might then wonder why "--with-pgtk" isn't > enabled by default on systems with the necessary dependencies, but > that only *implies* that there are downsides to PGTK rather than > stating it. > > I think it would be best to state explicitly that there are problems > with the PGTK build, though INSTALL probably doesn't need to go into > any more detail than that. In practice, a lot of people will probably > just skim the documentation, so they might miss some of the more > subtle points unless they're very clearly called out. Sure, I won't insist if everyone else seems to agree this should be mentioned (again) in INSTALL. Feel free to install changes to that effect. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 1:02 ` Po Lu @ 2022-04-19 2:46 ` Sean Whitton 0 siblings, 0 replies; 48+ messages in thread From: Sean Whitton @ 2022-04-19 2:46 UTC (permalink / raw) To: Po Lu, Jim Porter; +Cc: emacs-devel Hello, On Tue 19 Apr 2022 at 09:02AM +08, Po Lu wrote: > Jim Porter <jporterbugs@gmail.com> writes: > >> Reading through these sections of INSTALL, I found it very easy to >> assume that PGTK was a direct upgrade that would just let me "switch >> between running Emacs on X, Wayland and Broadway". An >> extremely-careful reader might then wonder why "--with-pgtk" isn't >> enabled by default on systems with the necessary dependencies, but >> that only *implies* that there are downsides to PGTK rather than >> stating it. >> >> I think it would be best to state explicitly that there are problems >> with the PGTK build, though INSTALL probably doesn't need to go into >> any more detail than that. In practice, a lot of people will probably >> just skim the documentation, so they might miss some of the more >> subtle points unless they're very clearly called out. > > Sure, I won't insist if everyone else seems to agree this should be > mentioned (again) in INSTALL. > > Feel free to install changes to that effect. Cool, now done. -- Sean Whitton ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-18 19:49 ` Jim Porter 2022-04-19 1:02 ` Po Lu @ 2022-04-19 2:18 ` Tim Cross 2022-04-19 5:56 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Tim Cross @ 2022-04-19 2:18 UTC (permalink / raw) To: Jim Porter; +Cc: Po Lu, emacs-devel, Sean Whitton Jim Porter <jporterbugs@gmail.com> writes: > > I think it would be best to state explicitly that there are problems with the > PGTK build, though INSTALL probably doesn't need to go into any more detail than > that. In practice, a lot of people will probably just skim the documentation, so > they might miss some of the more subtle points unless they're very clearly > called out. I agree. I think this is the main point being missed by others who have argued the existing documentation is clear enough. Like it or not, people often don't read the documentation or NEWS file carefully. There is also a tendency for people to believe any new feature is an improvement and I suspect many people will think a pure GTK build is going to be better than a hybrid X/GTK one. We should just add a very explicit and clear warning not to use --with-pgtk if your running under X and put this statement right at the beginning of the section in the NEWS file about this new option. It might even be worthwhile adding a warning in configure as well (like the one we have about pop support). Like others, I expect many distributions are going to bundle emacs-gtk believing it is an improvement. I suspect it is going to be a bigger issue given that some popular distributions, like fedora, will be shipping with wayland as their default but there will likely be many who will choose to switch back to X, but then be faced with an Emacs built with pgtk to better support the default wayland setup. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 2:18 ` Tim Cross @ 2022-04-19 5:56 ` Eli Zaretskii 2022-04-19 8:13 ` Tim Cross 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2022-04-19 5:56 UTC (permalink / raw) To: Tim Cross; +Cc: luangruo, jporterbugs, spwhitton, emacs-devel > From: Tim Cross <theophilusx@gmail.com> > Date: Tue, 19 Apr 2022 12:18:07 +1000 > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org, > Sean Whitton <spwhitton@spwhitton.name> > > I agree. I think this is the main point being missed by others who have > argued the existing documentation is clear enough. Like it or not, > people often don't read the documentation or NEWS file carefully. There > is also a tendency for people to believe any new feature is an > improvement and I suspect many people will think a pure GTK build is > going to be better than a hybrid X/GTK one. > > We should just add a very explicit and clear warning not to use > --with-pgtk if your running under X and put this statement right at the > beginning of the section in the NEWS file about this new option. Aren't you contradicting yourself here? If people don't read documentation, how can any addition to the documentation solve this issue? (Of course, I don't object to saying something in INSTALL about that, just pointing out that it's hard to have it both ways.) > It might even be worthwhile adding a warning in configure as well (like > the one we have about pop support). I object to annoying people who build Emacs with such warnings. Besides, warnings (as opposed to errors) in the configure script are easily overlooked, because people tend to leave the build run unattended, and do other useful things while it runs. > Like others, I expect many distributions are going to bundle > emacs-gtk believing it is an improvement. I suspect it is going to > be a bigger issue given that some popular distributions, like > fedora, will be shipping with wayland as their default but there > will likely be many who will choose to switch back to X, but then be > faced with an Emacs built with pgtk to better support the default > wayland setup. IME, there's nothing we can do against such misconceptions. We will get bug reports and will respond by pointing people to NEWS and INSTALL. Eventually, enough people will bump into this to realize the truth, and the issue will go away. No catastrophe that I could spot, and no need to get too excited. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 5:56 ` Eli Zaretskii @ 2022-04-19 8:13 ` Tim Cross 2022-04-19 10:32 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Tim Cross @ 2022-04-19 8:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, jporterbugs, spwhitton, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Tim Cross <theophilusx@gmail.com> >> Date: Tue, 19 Apr 2022 12:18:07 +1000 >> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org, >> Sean Whitton <spwhitton@spwhitton.name> >> >> I agree. I think this is the main point being missed by others who have >> argued the existing documentation is clear enough. Like it or not, >> people often don't read the documentation or NEWS file carefully. There >> is also a tendency for people to believe any new feature is an >> improvement and I suspect many people will think a pure GTK build is >> going to be better than a hybrid X/GTK one. >> >> We should just add a very explicit and clear warning not to use >> --with-pgtk if your running under X and put this statement right at the >> beginning of the section in the NEWS file about this new option. > > Aren't you contradicting yourself here? If people don't read > documentation, how can any addition to the documentation solve this > issue? (Of course, I don't object to saying something in INSTALL > about that, just pointing out that it's hard to have it both ways.) > Eli, rather ironically you just proved my point. I didn't say they didn't read the documentation, I said they didn't read it carefully. Just like you did with my post, they skim read it and can easily miss crucial points. The fact people are building with pgtk when only running under X would tend to indicate the messaging is not adequate. Making a clear concise statement not to use pgtk when using X early, even at the start, would increase the likelihood skim readers see it. >> It might even be worthwhile adding a warning in configure as well (like >> the one we have about pop support). > > I object to annoying people who build Emacs with such warnings. > Besides, warnings (as opposed to errors) in the configure script are > easily overlooked, because people tend to leave the build run > unattended, and do other useful things while it runs. > I guess there not terribly annoying if they are easily overlooked! Just like the warning about removal of pop support and pointer to mail utils, this warning could be at the end of the build. At any rate, seems like a more important warning than one about no longer supporting pop3, which few mail providers support anymore anyway. >> Like others, I expect many distributions are going to bundle >> emacs-gtk believing it is an improvement. I suspect it is going to >> be a bigger issue given that some popular distributions, like >> fedora, will be shipping with wayland as their default but there >> will likely be many who will choose to switch back to X, but then be >> faced with an Emacs built with pgtk to better support the default >> wayland setup. > > IME, there's nothing we can do against such misconceptions. We will > get bug reports and will respond by pointing people to NEWS and > INSTALL. Eventually, enough people will bump into this to realize the > truth, and the issue will go away. No catastrophe that I could spot, > and no need to get too excited. You do seem to like jumping to extremes. I don't think anyone has been screaming catastrophe. All I've seen is people asking to make this more obvious and explicit. Maybe it won't make a big difference, but then again, maybe it will. The cost of making the limitations of pgtk more explicit in NEWS and INSTALL is very low and even if it only stops a few people from doing the wrorng build, reporting a 'non-bug' and getting directed back to NEW/INSTALL and having to rebuild, I think the cost has been justified. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 8:13 ` Tim Cross @ 2022-04-19 10:32 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2022-04-19 10:32 UTC (permalink / raw) To: Tim Cross; +Cc: luangruo, jporterbugs, spwhitton, emacs-devel > From: Tim Cross <theophilusx@gmail.com> > Cc: jporterbugs@gmail.com, luangruo@yahoo.com, emacs-devel@gnu.org, > spwhitton@spwhitton.name > Date: Tue, 19 Apr 2022 18:13:03 +1000 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> I agree. I think this is the main point being missed by others who have > >> argued the existing documentation is clear enough. Like it or not, > >> people often don't read the documentation or NEWS file carefully. There > >> is also a tendency for people to believe any new feature is an > >> improvement and I suspect many people will think a pure GTK build is > >> going to be better than a hybrid X/GTK one. > >> > >> We should just add a very explicit and clear warning not to use > >> --with-pgtk if your running under X and put this statement right at the > >> beginning of the section in the NEWS file about this new option. > > > > Aren't you contradicting yourself here? If people don't read > > documentation, how can any addition to the documentation solve this > > issue? (Of course, I don't object to saying something in INSTALL > > about that, just pointing out that it's hard to have it both ways.) > > > > Eli, rather ironically you just proved my point. I didn't say they > didn't read the documentation, I said they didn't read it carefully. If there's a significant difference, for the purposes of this discussion, between "don't read" and "don't read carefully", then I'm afraid I don't understand what you wanted to say. Either people will miss what we say or they won't. In the latter case, what we already say is enough; in the former case it doesn't matter what we will say or add to what we did already, because both INSTALL and NEWS are large files and contain a lot of stuff. So I fail to see how the fine point of "carefully" is relevant here. > > I object to annoying people who build Emacs with such warnings. > > Besides, warnings (as opposed to errors) in the configure script are > > easily overlooked, because people tend to leave the build run > > unattended, and do other useful things while it runs. > > > > I guess there not terribly annoying if they are easily overlooked! They are easily overlooked by one part of the people (usually, those who don't read the documentation "carefully" enough), and are annoying to the other part, those who don't overlook the warnings (because they usually already read the documentation and did TRT). > Just like the warning about removal of pop support and pointer > to mail utils, this warning could be at the end of the build. The warning about pop support and Mailutils is at the end of the configure script, not the end of the build. If you build by saying just "make" (which is the normal way of building Emacs these days), then you won't see the warning "at the end" because Make runs the Makefiles immediately after the configure script finishes. > At any > rate, seems like a more important warning than one about no longer > supporting pop3, which few mail providers support anymore anyway. That's not what that warning is about, not at all. I guess you didn't read it "carefully" enough. > > IME, there's nothing we can do against such misconceptions. We will > > get bug reports and will respond by pointing people to NEWS and > > INSTALL. Eventually, enough people will bump into this to realize the > > truth, and the issue will go away. No catastrophe that I could spot, > > and no need to get too excited. > > You do seem to like jumping to extremes. I don't think anyone has been > screaming catastrophe. This thread amassed 2 dozen messages already, so I think there are some who do think it's a big deal. > All I've seen is people asking to make this more obvious and > explicit. Maybe it won't make a big difference, but then again, > maybe it will. The cost of making the limitations of pgtk more > explicit in NEWS and INSTALL is very low and even if it only stops a > few people from doing the wrorng build, reporting a 'non-bug' and > getting directed back to NEW/INSTALL and having to rebuild, I think > the cost has been justified. If you read what I wrote, I explicitly said I didn't object to adding this stuff to INSTALL. But I don't think it will solve the problem of people who don't read the documentation "carefully" enough to pay attention. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-15 2:29 ` Po Lu ` (2 preceding siblings ...) 2022-04-18 5:18 ` Sean Whitton @ 2022-04-19 9:10 ` Dirk-Jan C. Binnema 2022-04-19 10:42 ` Po Lu 2022-04-19 11:53 ` Phil Sainty 3 siblings, 2 replies; 48+ messages in thread From: Dirk-Jan C. Binnema @ 2022-04-19 9:10 UTC (permalink / raw) To: emacs-devel On Friday Apr 15 2022, Po Lu wrote: > Morgan Smith <morgan.j.smith@outlook.com> writes: > >> I'd like to report that my super key stopped registering. I suspected >> commit 1404e16975 caused it so I did a quick `git revert 1404e16975` >> ontop of 807682de1e and that fixed it. > > Crystal ball says you are using X Windows, and have to put > > remove mod4 = Hyper_L > > in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11 > Emacs to work around the common kind of virtual modifier > misconfiguration. > > People using X should _never_ use PGTK. The regular X build does a much > better job at supporting that than PGTK ever will. > > It is completely pointless to put up with half-working child frames, > random keyboard-related lossage, random frame placement/resizing > failures, so the actual fix is to delete `--with-pgtk' from your calls > to configure. > > Similarly, people building packages with PGTK enabled that are labeled > "enhanced" are doing their users a disservice. No packager should > enable PGTK by default, and every package should ideally come with a big > disclaimer warning against using PGTK on window systems otherwise > supported by Emacs, since time and experience shows that Emacs generally > does a much better job at their support than GTK. > > Many people are also being mislead by articles on the internet claiming > that PGTK leads to faster redisplay, such as this one: > http://www.cesarolea.com/posts/emacs-native-compile > > That is not true, since regular Emacs with cairo uses more-or-less the > same rendering path as PGTK, except when PGTK runs on Wayland, where it > uses software rendering and does image compositing in software, and is > thus slower than everything else. Scrolling on PGTK is also not as > efficient as XCopyArea requests. > > But the difference in speed even on Wayland is negligible, not easy to > benchmark, and not at all visible to the human eye. Appreciate the efforts on this, but the outcome seems somewhat unsatisfactory, if I understand correctly: - we have the "non-pure" gtk build which supports X (although gtk has a wayland backend, non-pure gtk assumes X) - we have "pure" gtk, which supports X and Wayland, but now it turns out there's a bunch of limitations on X. From the the time before pgtk got merged, I can't remember any wide discussion of it being wayland-only. Perhaps I misremember. I regularly use both X and Wayland, and having to have two emacsen (and remember to use the right one) just for that seems sub-optimal. Wouldn't it be better to have a single gtk3 backend? For users and developers and distributors? But maybe the problems is small, i.e. perhaps pgtk works fine on X, but doesn't currently implement a handful of things, which we can document? Then users can decide if they can live with that. Kind regards, Dirk. -- Dirk-Jan C. Binnema Helsinki, Finland e:djcb@djcbsoftware.nl gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 9:10 ` Dirk-Jan C. Binnema @ 2022-04-19 10:42 ` Po Lu 2022-04-19 11:53 ` Phil Sainty 1 sibling, 0 replies; 48+ messages in thread From: Po Lu @ 2022-04-19 10:42 UTC (permalink / raw) To: Dirk-Jan C. Binnema; +Cc: emacs-devel "Dirk-Jan C. Binnema" <djcb.bulk@gmail.com> writes: > Appreciate the efforts on this, but the outcome seems somewhat > unsatisfactory, if I understand correctly: > > - we have the "non-pure" gtk build which supports X (although gtk has a > wayland backend, non-pure gtk assumes X) "Non-pure GTK" uses GTK for widgets, but directly uses X Windows APIs for input and display, and some other features too. > - we have "pure" gtk, which supports X and Wayland, but now it turns > out there's a bunch of limitations on X. Yes. > From the the time before pgtk got merged, I can't remember any wide > discussion of it being wayland-only. Perhaps I misremember. I looked over those discussions not too long ago, and it seems that nobody really used the PGTK build on X Windows. Those who did immediately ran into resizing glitches, keyboard input issues, and some features just not being implemented, such as responding to configure events. > I regularly use both X and Wayland, and having to have two emacsen (and > remember to use the right one) just for that seems sub-optimal. Wouldn't > it be better to have a single gtk3 backend? For users and developers and > distributors? That isn't possible, at least not without a lot of work. > But maybe the problems is small, i.e. perhaps pgtk works fine on X, but > doesn't currently implement a handful of things, which we can document? > Then users can decide if they can live with that. That list would be very long, would include serious types of misbehavior, be liable to change at the whim of the GTK developers, so the truth is that users should simply stay away from PGTK on X. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 9:10 ` Dirk-Jan C. Binnema 2022-04-19 10:42 ` Po Lu @ 2022-04-19 11:53 ` Phil Sainty 2022-04-19 13:58 ` Sean Whitton 2022-04-19 16:51 ` Yuri Khan 1 sibling, 2 replies; 48+ messages in thread From: Phil Sainty @ 2022-04-19 11:53 UTC (permalink / raw) To: Dirk-Jan C. Binnema; +Cc: emacs-devel On 2022-04-19 21:10, Dirk-Jan C. Binnema wrote: > I regularly use both X and Wayland, and having to have two emacsen > (and remember to use the right one) just for that seems sub-optimal. I believe there's something called "X-Wayland" for running X programs under Wayland, in case that's the missing piece of the puzzle? IIUC you can use that to run the same (single) X build of emacs when you're using Wayland that you use when you're not, which avoids the problem you've described. -Phil ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 11:53 ` Phil Sainty @ 2022-04-19 13:58 ` Sean Whitton 2022-04-20 3:29 ` Phil Sainty 2022-04-19 16:51 ` Yuri Khan 1 sibling, 1 reply; 48+ messages in thread From: Sean Whitton @ 2022-04-19 13:58 UTC (permalink / raw) To: Phil Sainty, Dirk-Jan C. Binnema; +Cc: emacs-devel Hello, On Tue 19 Apr 2022 at 11:53pm +12, Phil Sainty wrote: > On 2022-04-19 21:10, Dirk-Jan C. Binnema wrote: >> I regularly use both X and Wayland, and having to have two emacsen >> (and remember to use the right one) just for that seems sub-optimal. > > I believe there's something called "X-Wayland" for running X programs > under Wayland, in case that's the missing piece of the puzzle? > > IIUC you can use that to run the same (single) X build of emacs when > you're using Wayland that you use when you're not, which avoids the > problem you've described. It's a compatibility layer, basically, and not a great one. I was having various basic focus and clipboard problems when running Lucid Emacs under Xwayland. -- Sean Whitton ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 13:58 ` Sean Whitton @ 2022-04-20 3:29 ` Phil Sainty 2022-04-20 4:48 ` Stefan Monnier 0 siblings, 1 reply; 48+ messages in thread From: Phil Sainty @ 2022-04-20 3:29 UTC (permalink / raw) To: Sean Whitton; +Cc: Dirk-Jan C. Binnema, emacs-devel On 2022-04-20 01:58, Sean Whitton wrote: >> On 2022-04-19 21:10, Dirk-Jan C. Binnema wrote: >>> I regularly use both X and Wayland, and having to have two emacsen >>> (and remember to use the right one) just for that seems sub-optimal. >> >> I believe there's something called "X-Wayland" for running X programs >> under Wayland > > It's a compatibility layer, basically, and not a great one. I was > having various basic focus and clipboard problems when running Lucid > Emacs under Xwayland. Ah, ok. In that case I guess one really would prefer to install both builds, if using both Wayland and X at different times. I imagine one could mostly circumvent the "remember to use the right one" issue by automatically setting PATH based on which system you were using at that time, so that "emacs" was always going to be the correct emacs. -Phil ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-20 3:29 ` Phil Sainty @ 2022-04-20 4:48 ` Stefan Monnier 0 siblings, 0 replies; 48+ messages in thread From: Stefan Monnier @ 2022-04-20 4:48 UTC (permalink / raw) To: Phil Sainty; +Cc: Sean Whitton, Dirk-Jan C. Binnema, emacs-devel > I imagine one could mostly circumvent the "remember to use the right one" > issue by automatically setting PATH based on which system you were using > at that time, so that "emacs" was always going to be the correct emacs. Ideally, it should be possible to build a single Emacs executable that can simultaneously open frames on a tty, on an X server (some using GNUstep and others using Lucid), and on a Wayland server. It would/will require a fair bit of code changes, but AFAIK almost all of it should be "simple/repetitive": it shouldn't require any fundamental change. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 11:53 ` Phil Sainty 2022-04-19 13:58 ` Sean Whitton @ 2022-04-19 16:51 ` Yuri Khan 2022-04-22 5:44 ` Pankaj Jangid 1 sibling, 1 reply; 48+ messages in thread From: Yuri Khan @ 2022-04-19 16:51 UTC (permalink / raw) To: Phil Sainty; +Cc: Dirk-Jan C. Binnema, Emacs developers On Tue, 19 Apr 2022 at 18:54, Phil Sainty <psainty@orcon.net.nz> wrote: > I believe there's something called "X-Wayland" for running X programs > under Wayland, in case that's the missing piece of the puzzle? > > IIUC you can use that to run the same (single) X build of emacs when > you're using Wayland that you use when you're not, which avoids the > problem you've described. If you have a HiDPI monitor, an X application on an X server gets full resolution, a Wayland application on a Wayland compositor gets full resolution, but an X application via Xwayland on a Wayland compositor gets rendered at low resolution and then upscaled. It’s a non-starter. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: PGTK-related misconceptions 2022-04-19 16:51 ` Yuri Khan @ 2022-04-22 5:44 ` Pankaj Jangid 0 siblings, 0 replies; 48+ messages in thread From: Pankaj Jangid @ 2022-04-22 5:44 UTC (permalink / raw) To: emacs-devel Yuri Khan <yuri.v.khan@gmail.com> writes: > On Tue, 19 Apr 2022 at 18:54, Phil Sainty <psainty@orcon.net.nz> wrote: > >> I believe there's something called "X-Wayland" for running X programs >> under Wayland, in case that's the missing piece of the puzzle? >> >> IIUC you can use that to run the same (single) X build of emacs when >> you're using Wayland that you use when you're not, which avoids the >> problem you've described. > > If you have a HiDPI monitor, an X application on an X server gets full > resolution, a Wayland application on a Wayland compositor gets full > resolution, but an X application via Xwayland on a Wayland compositor > gets rendered at low resolution and then upscaled. It’s a non-starter. Yup. I had a very hard time without-pgtk on a HiDPI monitor. Tried all sorts of scaling and font-sizing. Nothing worked. I am using xwayland. Because that is now default in Debian desktop environment (Gnome). So I started using PGTK build. And for my use-case, I have not faced any issues till now. It has been two months. Fonts look awesome. ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2022-07-30 0:58 UTC | newest]
Thread overview: 48+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-04-18 21:50 PGTK-related misconceptions Trey
2022-04-19 0:59 ` Po Lu
2022-04-19 3:28 ` Trey Peacock
2022-04-19 4:27 ` Po Lu
2022-04-19 23:02 ` Trey Peacock
2022-04-20 0:48 ` Po Lu
2022-04-20 2:33 ` Trey Peacock
2022-04-20 4:05 ` Po Lu
2022-07-25 21:18 ` Akira Kyle
2022-07-26 2:08 ` Po Lu
2022-07-26 12:10 ` Lars Ingebrigtsen
2022-07-26 12:35 ` Po Lu
2022-07-29 14:26 ` Stefan Monnier
2022-07-30 0:58 ` Po Lu
2022-07-26 21:36 ` Akira Kyle
2022-07-27 2:48 ` Po Lu
2022-07-27 8:34 ` Trey Peacock
2022-07-27 9:10 ` Po Lu
2022-07-27 13:45 ` Trey Peacock
2022-07-27 13:52 ` Po Lu
2022-07-28 1:39 ` Akira Kyle
2022-07-28 2:50 ` Po Lu
-- strict thread matches above, loose matches on Subject: below --
2022-04-20 7:52 Trey Peacock
2022-04-20 8:25 ` Po Lu
2022-04-20 13:13 ` Brian Cully
[not found] <DM5PR03MB3163BBCF9626AD3B88900011C5EE9@DM5PR03MB3163.namprd03.prod.outlook.com>
2022-04-15 2:29 ` Po Lu
2022-04-15 7:11 ` Byung-Hee HWANG
2022-04-15 16:24 ` Eric Abrahamsen
2022-04-18 5:18 ` Sean Whitton
2022-04-18 5:31 ` Po Lu
2022-04-18 5:43 ` Sean Whitton
2022-04-18 5:57 ` Po Lu
2022-04-18 18:27 ` Sean Whitton
2022-04-18 19:49 ` Jim Porter
2022-04-19 1:02 ` Po Lu
2022-04-19 2:46 ` Sean Whitton
2022-04-19 2:18 ` Tim Cross
2022-04-19 5:56 ` Eli Zaretskii
2022-04-19 8:13 ` Tim Cross
2022-04-19 10:32 ` Eli Zaretskii
2022-04-19 9:10 ` Dirk-Jan C. Binnema
2022-04-19 10:42 ` Po Lu
2022-04-19 11:53 ` Phil Sainty
2022-04-19 13:58 ` Sean Whitton
2022-04-20 3:29 ` Phil Sainty
2022-04-20 4:48 ` Stefan Monnier
2022-04-19 16:51 ` Yuri Khan
2022-04-22 5:44 ` Pankaj Jangid
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).