bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Campbell Barton]

With PGTK enabled (--with-pgtk) the following occurs:

- Press C-S-u
- Press a

The character 'a' is entered.

Without PGTK enabled, the following occurs:

- Press C-S-u
- Press a

The character 'aaaa' is entered 4x.

Note that PGTK seems to swallow this binding, since it's not possible to
check what the shortcut does by pressing:

C-H, K, C-S-u

Which reports without PGTK: (universal-argument)



In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.31, cairo version 1.17.4)
 of 2022-01-12 built on austpc
Repository revision: 8555a3e1ed1d34cbaa172bde86eb3b11a1cd7940
Repository branch: master
System Description: Arch Linux

Configured using:
 'configure --prefix=/opt/emacs --with-sound=no --disable-acl
 --with-file-notification=no --with-xpm --with-native-compilation
 --with-jpeg --with-tiff --with-gif --with-png --without-rsvg
 --without-lcms2 --without-libsystemd --without-gsettings
 --without-harfbuzz --without-m17n-flt --without-libotf --without-gpm
 --without-dbus --without-gsettings --without-gconf --without-selinux
 --without-gnutls --with-pgtk --without-makeinfo --without-libgmp
 --with-zlib --with-compress-install --with-threads
 --without-toolkit-scroll-bars --with-x-toolkit=gtk3 --with-xft
 --with-modules 'CFLAGS=-O3 -mtune=native -march=native -pipe
 -fomit-frame-pointer''

Configured features:
CAIRO FREETYPE GIF GLIB JPEG JSON LIBXML2 MODULES NATIVE_COMP PDUMPER
PGTK PNG SECCOMP SQLITE3 THREADS TIFF WEBP XIM GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

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

Load-path shadows:
None found.

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

Memory information:
((conses 16 45508 6842)
 (symbols 48 5609 1)
 (strings 32 18557 3267)
 (string-bytes 1 622864)
 (vectors 16 10816)
 (vector-slots 8 157953 15748)
 (floats 8 25 28)
 (intervals 56 255 0)
 (buffers 992 11))

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

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

Campbell Barton <ideasman42@gmail.com> writes:

> With PGTK enabled (--with-pgtk) the following occurs:
>
> - Press C-S-u
> - Press a
>
> The character 'a' is entered.
>
> Without PGTK enabled, the following occurs:
>
> - Press C-S-u
> - Press a
>
> The character 'aaaa' is entered 4x.
>
> Note that PGTK seems to swallow this binding, since it's not possible to
> check what the shortcut does by pressing:
>
> C-H, K, C-S-u
>
> Which reports without PGTK: (universal-argument)

This has been reported at least twice already.  Someone should volunteer
to find and merge all those bugs, but in short: most GTK input method
modules stupidly eat the shift modifier, and the only workaround is to
disable the use of GTK input methods by setting `pgtk-use-im-context' to
nil.

This is really a bug in the various input modules and should be reported
to their developers instead instead.  If you're using ibus, for example,
complain to ibus developers about their IM context not setting the shift
modifier mask in an event sent by the filter.

Alternatively, you can use the regular X build, which is a much superior
experience over the PGTK port as long as you're not using Wayland.

Thanks, and please let us know about the progress of your complaining to
the IM module developers.  It would be greatly appreciated.

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> This has been reported at least twice already.  Someone should volunteer
> to find and merge all those bugs

I found bug#49211, which seems to be the same problem, so I've merged
this with that one.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I found bug#49211, which seems to be the same problem, so I've merged
> this with that one.

Great, thanks!

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Morgan Smith]

Hello,

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.

I'm running pgtk on wayland with (pgtk-use-im-context nil) 
(although that doesn't seem to affect this issue). 

Thanks,

Morgan

PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Byung-Hee HWANG]

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

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//

Re: PGTK-related misconceptions

[Eric Abrahamsen]

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

Re: PGTK-related misconceptions

[Sean Whitton]

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

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Sean Whitton]

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

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Sean Whitton]

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

Re: PGTK-related misconceptions

[Jim Porter]

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.

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Sean Whitton]

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

Re: PGTK-related misconceptions

[Tim Cross]

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. 

Re: PGTK-related misconceptions

[Eli Zaretskii]

> 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.

Re: PGTK-related misconceptions

[Tim Cross]

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.

Re: PGTK-related misconceptions

[Eli Zaretskii]

> 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.

Re: PGTK-related misconceptions

[Dirk-Jan C. Binnema]

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

Re: PGTK-related misconceptions

[Po Lu]

"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.

Re: PGTK-related misconceptions

[Phil Sainty]

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

Re: PGTK-related misconceptions

[Sean Whitton]

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

Re: PGTK-related misconceptions

[Phil Sainty]

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

Re: PGTK-related misconceptions

[Stefan Monnier]

> 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

Re: PGTK-related misconceptions

[Yuri Khan]

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.

Re: PGTK-related misconceptions

[Pankaj Jangid]

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.

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[daanturo]

> 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.
 
Hello,
 
I can't find commit 1404e16975 in Emacs' master tree, but even when having IM disabled via `(setq pgtk-use-im-context-on-new-connection nil)` in init.el, Emacs is unable to recognize any Super-modified keys.
 
It's reproducible in `emacs -q` then `(pgtk-use-im-context nil)`.
 
I'm on Emacs master (8f3e0ed2b99b9b2ad42693cab2b3c0c291e3c3d0).
 
--  
Daanturo.

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Morgan Smith]

Hello,

daanturo <daanturo@gmail.com> writes:
> Emacs is unable to recognize any Super-modified keys. 

My bad, I gave the wrong git hash.  I meant this hash: 1c1ae6ba80. 
If you want to re-enable super modified keys you have to make the 
following change.  If I remember correctly Po Lu thinks this is a 
bug in some other software and that the GDK_SUPER_MASK bit should 
be set so they don't want to add the GDK_MOD4_MASK bit. 
Personally, I think GDK_MOD4_MASK should be added and we should 
just add a todo comment to look into it more later.

I suppose the thought is that in theory someone could use MOD4 as 
a custom modifier instead of using it as super but realistically I 
think someone trying to do that would have lots of problems.  It 
would be cool if that was possible though so I do support trying 
to rid ourselves of odd grandfathered in quirks.


diff --git a/src/pgtkterm.c b/src/pgtkterm.c index 
b9d0b7b512..3ef643a075 100644 --- a/src/pgtkterm.c +++ 
b/src/pgtkterm.c @@ -5018,7 +5018,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; 
@@ -5151,7 +5151,8 @@ 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_MOD4_MASK | GDK_HYPER_MASK))) 
 	{ if (pgtk_im_filter_keypress (f, &event->key)) return TRUE; 

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

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

Morgan Smith <morgan.j.smith@outlook.com> writes:

> Hello,
>
> daanturo <daanturo@gmail.com> writes:
>> Emacs is unable to recognize any Super-modified keys. 
>
> My bad, I gave the wrong git hash.  I meant this hash: 1c1ae6ba80. If
> you want to re-enable super modified keys you have to make the
> following change.  If I remember correctly Po Lu thinks this is a bug
> in some other software and that the GDK_SUPER_MASK bit should be set
> so they don't want to add the GDK_MOD4_MASK bit. Personally, I think
> GDK_MOD4_MASK should be added and we should just add a todo comment to
> look into it more later.
>
> I suppose the thought is that in theory someone could use MOD4 as a
> custom modifier instead of using it as super but realistically I think
> someone trying to do that would have lots of problems.  It would be
> cool if that was possible though so I do support trying to rid
> ourselves of odd grandfathered in quirks.

No.  It is safe to use Mod4 for something else than Super.  (On X
Windows it is often Hyper, or both at the same time, or else.)

The only modifier that is not safe to change is Mod1, which GTK always
assumes to be alt.

Please let the GTK developers know that the bug is important here:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4913

Otherwise, they will keep ignoring it, as usual.

Re: PGTK-related misconceptions

[Trey]

[-- 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 --]

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Trey Peacock]

[-- 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 --]

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Trey Peacock]

[-- 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 --]

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Trey Peacock]

[-- 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 --]

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Akira Kyle]

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?

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Lars Ingebrigtsen]

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.

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Stefan Monnier]

>> 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

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Akira Kyle]

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);
    };

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Trey Peacock]

"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.

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Trey Peacock]

"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.

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Akira Kyle]

[-- 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> };
};

};

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Trey Peacock]

[-- 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 --]

Re: PGTK-related misconceptions

[Po Lu]

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.

Re: PGTK-related misconceptions

[Brian Cully]

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