From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Akira Kyle Newsgroups: gmane.emacs.devel Subject: Re: PGTK-related misconceptions Date: Tue, 26 Jul 2022 15:36:15 -0600 Message-ID: <87fsino7gd.fsf@akirakyle.com> References: <87y202f4dq.fsf@treypeacock.com> <87o80xhor2.fsf@yahoo.com> <877d7lrbta.fsf@treypeacock.com> <87czdszy2r.fsf@akirakyle.com> <875yjkzkuc.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22116"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.11; emacs 29.0.50 Cc: Trey Peacock , Morgan Smith , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 27 00:07:54 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oGSiY-0005VY-3f for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Jul 2022 00:07:54 +0200 Original-Received: from localhost ([::1]:38398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oGSiW-00077z-ML for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Jul 2022 18:07:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGSgy-000695-Bf for emacs-devel@gnu.org; Tue, 26 Jul 2022 18:06:16 -0400 Original-Received: from ms11p00im-qufo17291901.me.com ([17.58.38.48]:60078) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGSgw-0003kN-HL for emacs-devel@gnu.org; Tue, 26 Jul 2022 18:06:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akirakyle.com; s=sig1; t=1658873170; bh=z8g8DRB5vNqKmA9NTVnu3dOH4vPEs6G0YV+j/daQmTg=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=vREKodIxKeI6R4rvO2TPs/LrnImJrA97ykJ8KHBTKwNzxPymPoy1K8g608qzu+Ny+ HLp+F2rG0jU/18+XZbCdjP5vZSXEGtVvywRINaIfrFCFit4hGkEoI/yx/obxnjRLmV 1JDP2Ox9//TQr330C9iQfnMwWDX1AXU2WMT7GtaLYCpkD/Yx1cCjiEIfeHe03B+eQN ANKL9GTt1Xe961H4OCnBrlCqIEdo3ZEYwWy/YMWLZnZyFpORH0E9knNpEk+u2SkvLl EOr1c2H9juZNS4h3iA78R4LT3GIcMw9xUFWyxOjDzcdVr7+8FTN7kLjHVvJ3O8YISo TJKcv0quzBOng== Original-Received: from data (ms11p00im-dlb-asmtpmailmevip.me.com [17.57.154.19]) by ms11p00im-qufo17291901.me.com (Postfix) with ESMTPSA id 4C3B1BC0446; Tue, 26 Jul 2022 22:06:09 +0000 (UTC) In-reply-to: <875yjkzkuc.fsf@yahoo.com> X-Proofpoint-GUID: orGyaULce-HT6Lej2FPB1CIjqhLwO8GW X-Proofpoint-ORIG-GUID: orGyaULce-HT6Lej2FPB1CIjqhLwO8GW X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.572,17.11.62.513.0000000_definitions?= =?UTF-8?Q?=3D2022-01-14=5F01:2022-01-14=5F01,2020-02-14=5F11,2021-12-02?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=869 suspectscore=0 mlxscore=0 spamscore=0 phishscore=0 clxscore=1030 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207260084 Received-SPF: pass client-ip=17.58.38.48; envelope-from=akira@akirakyle.com; helo=ms11p00im-qufo17291901.me.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292720 Archived-At: On Tue, Jul 26, 2022 at 10:08 AM, Po Lu 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 as Super whereas under wayland with sway, emacs does not respond to . The relevant lines from the xkb_symbols section are key { [ Super_R ] }; modifier_map Mod4 { }; 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 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 { symbols[Group1]= [ Super_R ], virtualMods= Super }; key { 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); };