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.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	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 ED73C2382F
	for <ml@inbox.vuxu.org>; Sat, 29 Jun 2024 02:36:20 +0200 (CEST)
Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Fri Jun 28 20:30:36 -0400 2024
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org;
	s=20200506; t=1719620998;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=qBBAhSYJbQyKU9G8QD2MdhzalIXUdu9rS0eRVWy5eb4=;
	b=FgovYX1vqb71nRXNs7wEEycl+kp1audlCEnzH4JgdrEqlJ1c1aZ+BytOeLgIof28Fw5lWt
	2aI37e55BTJzbyNdTAjBsKPh/fbdbpBht2RxLpcuFXgLOCmBHaQ878NNel9T0Y+yMl9YgU
	Pa/kfQPyX1nZrKyJKNrcptDHIakNz/0=
Received: from [192.168.168.200] (<unknown> [207.45.82.38])
	by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 6bf82390 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for <9front@9front.org>;
	Fri, 28 Jun 2024 19:29:58 -0500 (CDT)
Message-ID: <0e48ff1e-f33e-49ed-b40c-ea2f442e4c56@posixcafe.org>
Date: Fri, 28 Jun 2024 19:30:34 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: 9front@9front.org
References: <D2C1ZF3C3YRR.2AQJHJN1OMK9S@trbsw.dev>
Content-Language: en-US
From: Jacob Moody <moody@posixcafe.org>
In-Reply-To: <D2C1ZF3C3YRR.2AQJHJN1OMK9S@trbsw.dev>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: self-healing RESTful replication reduce/map standard content-driven-scale manager 
Subject: Re: [9front] [PATCH] Fix shift release events in X11 drawterm with
 shift:both_capslock xmodmap option
Reply-To: 9front@9front.org
Precedence: bulk

On 6/28/24 18:53, 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).

Seems reasonable to me. Thanks for debugging this.
My only suggestion would be to axe the "Not having this causes the mouse ...".
What it causes is the shift key to be held down, which then causes the mouse button swapping.
Drawterm itself isn't doing that bit, it's rio.

Thanks,
moody