From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id EEB2923084 for ; Sat, 29 Jun 2024 18:33:15 +0200 (CEST) Received: from mail-pj1-f46.google.com ([209.85.216.46]) by 9front; Sat Jun 29 12:31:36 -0400 2024 Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-2c7cd2f077fso283444a91.2 for <9front@9front.org>; Sat, 29 Jun 2024 09:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719678694; x=1720283494; darn=9front.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oOxwzgelfSluTtaF+ebDStfCDZ+2cMUYhilPmSYefog=; b=NGitGpakjxoI03IpNl3J1WRQbDfJpknv8J3vL0PKlBpm9xdotkwuIeEEi5G0L2LFTo gpFxHpEP4onxoAPX3X7hGGabd+FEpIJS7lE8gzSdYKkavrQNAVWfjMIAzuXeT7oDcbNw HvZWCgbdKJJNADXzUI2KNOvValj5qnnF6GT7q5u4PhGQ6cJjgr0d6iHc7xf/4VD920hu hNB73BOqR2kVSNBRRMCtnD80WyBD9pcTnI6CA/+opDX+1A0KVmw9KFTluzqf72+1U3JT gMnnyme4A7peDpqmXx6sTsiBJ/wyxx0eDNpwMi43SQzaWljsOUmz6uyS/DIbBguCQ3Y4 bV3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719678694; x=1720283494; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oOxwzgelfSluTtaF+ebDStfCDZ+2cMUYhilPmSYefog=; b=EEEgGlQrmh853NrqivmPh+C440UATV1YBWLo0urKR6hvWbhJrk2iAhrIndS6EeB462 dm8QTvzODIMazHQQhx2ad5sWbP1SFv9VAcEED4BOXW2cgMHYMO1MESivY1K4T1ozfEzn +kxLBZzp0r42b5ooVxQYkIGonRzJDQNAiV+8IQXH35CtEygeA3hzqtJ4m0iaFO23rnf8 fM1Ba4Qjq9yngSYjJ0VTIDJd5AiV/ITW1mjknQUKbxfvj3oUaeudDl8LZ/08O1lcN067 jtr4oio5bxS55VP2C7y1SyHSu/q8RlD1F4ox3mJ/r1JTbiqaj+jvx4fay2Y4U+b1lGQJ e3Sw== X-Gm-Message-State: AOJu0YzyPcH3aLRzZwCIHPde8ElOgEEJMtueEWgdFy/jjk9lNno6OOEO 0gO/KP9vg77aaEoi2K9pbvmjR0dyKx3iWOxXgwRFniN3pc1s+P6Y/IEvOwM7fHRAqgcXT4Iicwv UAGGEM1tIrwvpMNVABVVZWK8rH0+e9w== X-Google-Smtp-Source: AGHT+IEIckle9eXexElP+PsdJFkfmJPnDXNv6PfOrVZInHyqk95Z9h59mT682ht8fsig2ppgQhk/5CoI12w4fvZRtMI= X-Received: by 2002:a17:90a:f182:b0:2c2:204d:6c2 with SMTP id 98e67ed59e1d1-2c93d766ba7mr1309437a91.2.1719678694225; Sat, 29 Jun 2024 09:31:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: hiro <23hiro@gmail.com> Date: Sat, 29 Jun 2024 18:31:22 +0200 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: hardware plugin cloud-aware pipelining proxy-aware deep-learning optimizer Subject: Re: [9front] [PATCH] Fix shift release events in X11 drawterm with shift:both_capslock xmodmap option Reply-To: 9front@9front.org Precedence: bulk what exactly are you receiving from x11 when you "enable" your double-shift-caps-lock? 1. shiftdown_left 2. shiftdown_right 3. capslockdown 4. shiftup_left 5. shiftup_right 6. capslocksup ? which of these are visible, or are they in a different order? e.g. i can easily imagine something like 123645 On Sat, Jun 29, 2024 at 1:53=E2=80=AFAM Timothy Robert Bednarzyk wrote: > > I have recently started using 9front on a couple of different machines > (including a native installation on my Thinkpad T470) and use drawterm > on my main laptop (which uses the X11 window manager dwm on Artix Linux) > to connect to one of them. However, on that laptop, I have the caps lock > key remapped to be another control key (ctrl:no_caps) and I have it set > to toggle caps lock when I press both shift keys at the same time > (shift:both_capslock). As it turns out, when the latter xmodmap option > is set, XLookupString interprets shift key release events as caps lock > key release events. This was causing my middle and right mouse buttons > to effectively be swapped permanently after pressing a shift key even > once in a drawterm session (although I didn't know why it was happening > until I did some research and found someone else mentioning them having > shift-related problems in a different program whenever they were using > shift:both_capslock). > > I ended up solving this by utilizing the rather strange and unintuitive > fact that the xkey event's state still has the ShiftMask bit set during > the release event (even for actual shift key release events, according > to what I found during my research) and using that to determine whether > the release event should be interpreted as being for a shift key or for > the caps lock key. This likely will cause the middle and right mouse > buttons to unswap if the user is holding down the shift key while > releasing the caps lock key, but considering how unlikely of a scenario > that is and the fact that it is only a temporary and mild problem (all > they would have to do is release and re-press the shift key), I think > this fix is acceptable enough (unless someone else can think of a better > solution, which I would greatly appreciate). > > diff --git a/gui-x11/x11.c b/gui-x11/x11.c > index b4f1ad3..8f2b694 100644 > --- a/gui-x11/x11.c > +++ b/gui-x11/x11.c > @@ -882,7 +882,16 @@ xkeyboard(XEvent *e) > break; > case XK_Shift_Lock: > case XK_Caps_Lock: > - k =3D Kcaps; > + /* > + * Using the xmodmap option shift:both_capslock c= auses shift > + * release events to appear as capslock release e= vents instead. > + * Not having this causes the middle and right mo= use buttons to > + * be swapped permanently after the shift key is = pressed once. > + */ > + if(e->xany.type =3D=3D KeyRelease && (e->xkey.sta= te & ShiftMask)) > + k =3D Kshift; > + else > + k =3D Kcaps; > break; > case XK_Scroll_Lock: > k =3D Kscroll; > > -- > trb