From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, RDNS_NONE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 14088 invoked from network); 26 Jun 2021 15:59:53 -0000 Received: from unknown (HELO 1ess.inri.net) (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 26 Jun 2021 15:59:53 -0000 Received: from pb-smtp20.pobox.com ([173.228.157.52]) by 1ess; Sat Jun 26 02:04:38 -0400 2021 Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 23AF313A95F for <9front@9front.org>; Sat, 26 Jun 2021 02:04:26 -0400 (EDT) (envelope-from unobe@cpan.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=message-id :to:subject:date:from:in-reply-to:mime-version:content-type :content-transfer-encoding; s=sasl; bh=v/6gXwATPefYF+pGbA6Ftp4je gfCjip0CP1/EK69bYo=; b=qOAf6vJvfq0Uxg8PrZFHuMDOZoe0xEfnAGiubGpEb JSoiGCSubdN0mMpTml4mmbeaN6bkVrw05VKpOzSegk/svcqD63AUmFwxHj3PK7uR 6C1z2rxSTXqJUmkEGFMumwC80G9w8ZkdLWSeT7F5GTNeR6q7OynAAjpfCHOxmlAM ks= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 1C4B813A95E for <9front@9front.org>; Sat, 26 Jun 2021 02:04:26 -0400 (EDT) (envelope-from unobe@cpan.org) Received: from samwise (unknown [47.34.135.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 46EB313A95C for <9front@9front.org>; Sat, 26 Jun 2021 02:04:23 -0400 (EDT) (envelope-from unobe@cpan.org) Message-ID: To: 9front@9front.org Date: Fri, 25 Jun 2021 23:04:20 -0700 From: unobe@cpan.org In-Reply-To: <16E08562D70F59B59716B917E13062F4@eigenstate.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 5ABE101A-D644-11EB-8227-D5C30F5B5667-09620299!pb-smtp20.pobox.com List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: self-healing non-blocking standard SOAP over SVG just-in-time software replication Subject: Re: [9front] vt: fix scrolling over ssh, add mouse scrolling Reply-To: 9front@9front.org Precedence: bulk Quoth ori@eigenstate.org: > Testing requested. > > We were setting 'resize_flag = 1' in backup(), which was > causing resized() to get called, which was causing us to > call exportsize(), which was eventually singalling sshd, > which forwarded the signal over to the process on the > other end of the ssh pipe. > > This was causing a SIGINT to get sent, which was screwing > up the scrolling. Reviewing the logic of what resize_flag does, your patch makes sense: when can you ever resize the window when scrolling/paging back or forward? I don't see how that can be done simultaneously, but maybe there's something else afoot. I want to make sure I understand what you're experiencing so I can test it properly. Here's what I've pieced togeter without running anything: 1. You start vt(1) 2. You ssh(1) into a foreign host. Since vt(1) sets the TERM environment variable, raw mode is on in ssh(1), which sets the vt(1) console winch to 1 @ /sys/src/cmd/vt/fs.c:/winchon due to the write @ /sys/src/cmd/ssh.c:/^rawon . 3. You start a long-running process that spews a lot of text. 4. You then use 'backup'. That signals to the foreign host to set the environment variables, which is performed. No problem there. 5. However, at the end of exportsize() an interrupt is sent because ssh(1) had set winch to 1: if(cs->winch) send_interrupt(); Thus the problem? Related to this, I see resize_flag is set to 1 in only one other scenario, and that deals with the page menu item and when blocked is true. Blocked is only set to 1 in /sys/src/cmd/vt/main.c:^newline from what I see. That's only done after newline() is called in /sys/src/cmd/vt/vt.c and only when: a) pagemode is true; and b) the number of lines goes beyond the screen size max. So perhaps the resize_flag set to 1 for 'backup' is to handle a special case that we're not aware of currently? Maybe ssh.c is being too aggressive in setting winchon? Or maybe your fix is the best.