From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from yow.a-b.xyz ([45.32.152.219]) by ewsd; Tue Feb 18 06:46:30 EST 2020 Received: by yow.a-b.xyz (OpenSMTPD) with ESMTPSA id 0aa35320 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Tue, 18 Feb 2020 12:46:22 +0100 (CET) Message-ID: <708AA3D68C26498CFC501A962772BB03@a-b.xyz> To: 9front@9front.org Subject: Re: [9front] drawterm bug report Date: Tue, 18 Feb 2020 12:46:21 +0100 From: kvik@a-b.xyz In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: immutable database-based manager > I imagine other people have noticed this. sometimes when I > switch virtual workspaces on xfce4, drawterm's input gets > stuck somehow and when I type, control characters come out. Drawterm registers the keydown event, this trickles down to kbdfs, rio, and whatever, modifying their input states; then, drawterm's input focus is taken away by external forces, you release the key but drawterm doesn't ever get that keyup event, therefore everything continues to believe you are holding down that Ctrl key for life. I remember trying to work this out at some point, with the idea of tracking the keys being pressed and explicitly releasing them on focuslost event, or something like that. You can't do it wholesale or naively either, because for example Alt triggers the kbdfs compose mode that must be exited by pressing Alt again.