From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17448 invoked by alias); 13 Nov 2014 20:10:40 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 17436 invoked by uid 89); 13 Nov 2014 20:10:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Nov 2014 20:10:38 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id EA83D8E0BAC; Thu, 13 Nov 2014 21:10:35 +0100 (CET) Date: Thu, 13 Nov 2014 20:10:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: Unexpected behavior using arrow keys on the terminal Message-ID: <20141113201035.GU2782@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <476974939.62973.1415788538204.JavaMail.yahoo@jws106102.mail.bf1.yahoo.com> <20141112154654.GA2782@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m8RPluiNA7RIyL8J" Content-Disposition: inline In-Reply-To: <20141112154654.GA2782@calimero.vinschen.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-11/txt/msg00002.txt.bz2 --m8RPluiNA7RIyL8J Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3884 On Nov 12 16:46, Corinna Vinschen wrote: > Hi George, >=20 > On Nov 12 10:35, George Prekas wrote: > > Using Cygwin 1.7.32, mintty 1.1.3 and OpenSSH_6.7p1 I am getting > > unexpected behavior regarding the use of arrow keys on the terminal. > > You can reproduce the behavior by doing the following: > >=20 > > ssh linux > > cd /usr/src/linux/tools/perf > > make > > cd ~ > > /usr/src/linux/tools/perf/perf record echo 42 > > /usr/src/linux/tools/perf/perf report > >=20 > > Pressing UP or DOWN should highlight one of the rows displayed. You > > can verify expected behavior by using either PuTTY or native Linux. > >=20 > > Observation #1: You can fix perf's behavior by applying perf.patch > > (attached). > >=20 > > Observation #2: Using Wireshark, I've observed that when I ssh to a > > host and press UP or DOWN on my terminal 3 packets are transmitted > > from the client. PuTTY on the other hand transmits only 1 packet > > (larger in size). > >=20 > > Observation #3: I wrote the program test.c (attached). If I run it and > > press UP or DOWN: > > * on Windows from cmd.exe it says "Read 3 bytes. First is 27." > > * on Linux it says "Read 3 bytes. First is 27." > > * on Linux via PuTTY it says "Read 3 bytes. First is 27." > > * on Windows from mintty.exe it says "Read 1 bytes. First is 27. Read > > 1 bytes. First is 91. Read 1 bytes. First is 65." > >=20 > > My understanding is that the unexpected behavior occurs because Cygwin > > sends the UP/DOWN sequence one byte at a time. Specifically: > >=20 > > * winsup\cygwin\fhandler_tty.cc @ fhandler_pty_master::write > > This is the function called by the write system call invoked by > > mintty. Here len =3D 3. line_edit is invoked 3 times. > > * winsup\cygwin\fhandler_termios.cc @ fhandler_termios::line_edit > > This is called by the previous and it calls accept_input. > > * winsup\cygwin\fhandler_tty.cc @ fhandler_pty_master::accept_input > > This does the actual WriteFile to the pipe. > >=20 > > I would have provided a patch to fix the problem, but I am not sure I > > completely understand the semantics of the above mentioned methods. >=20 > I have to admit that I'm not quite sure either. In theory I'd say that > the perf tool is making some invalid assumption here. You can't rely on > a set of bytes sent from any input source to be always sent or received > as a single package, unless you're working with a transport guaranteing > this. >=20 > Your analyzes of the underlying mechanism in Cygwin is correct, though. > Despite what I said above, I take a look into this and perhaps I can fix > the code to send more than 1 byte at a time.=20=20 In fact, both sides of the pipe were writing/reading in single byte chunks. The slave read side did something weird: Before reading, it always checked if the number of bytes available in the pipe is > VMIN. If so, it only read VMIN bytes. Since VMIN is 1 by default, it always reads only single bytes, since changing VMIN is only done rather seldomly by applications. This code snippet is actually 12 years old. Much of the code surrounding it changed considerably, just this snippet persisted. I disabled it now since it really looks like a remnant from the past, and it certainly doesn't reflect how it works on other OSes. On the master write side I applied a possible, but definitely experimental fix, which solves this issue by writing in 32 byte chunks in non-canonical mode. This should (mostly) circumvent the above effect, but it doesn't quite guarantee it. With luck, this change also speeds up tty output by reducing the # of calls to WriteFile/ReadFile. I uploaded a new snapshot to https://cygwin.com/snapshots, the one from today. Please give it a try. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --m8RPluiNA7RIyL8J Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUZRA7AAoJEPU2Bp2uRE+g7zQP/0c1g7P9OQKhDK/mYIBVz0M6 Pxi0PwRu5Lz/jrbINZiyHMSjwv7XbgEy4swIyx1xI0FqGRlL96X5jXETFtfrZNAZ uZ/roU7zmnOak5Y/BAzD5AvskN5/zrkGt2jiC5ruabL+8LURx4nHvxJCd6gQ3JMr r/Jt0HPCnz0G6zfCdYvIJ//FhfMgMmvrDwHcpehKHfaXutOtRut+VHGI5Hf9+Gjd ocj8bg0yUWJ7r8EZDuB/UZ3Psb0afi1qYtV4lAXOrylIt3Y8715I79r5M5qAxRSz QxeL1JTTlhtWaKnjvGlnVUybUE6TO4syOSSlVii1re4JGHfLnAPHB49mx9YZHNU/ eqSccuSVsdDK7lgtey3WQVl9Uj763Bv0LbL+bGP+ttuBNXSM0xkPpJD5ktNWl9Qg m4ZKROqLfnAL8UxDysj7QsVhvLtMjAHSFeX6VeI5Xjrp7rGbHqJ1uyDQQ5N5TPSW XT/0MCe2mlWVYDnlwzo5xc1+zGQ0TrcnxFooNS5S4lVvJ/6QLQaiCm12J+TF1eec aerjFHx7aHnx74jn5euMjlENKah+fM1+istA+q6T7S/yjMUmEcBUMGIDIxFrgeuO 1F4o6nAwNzBjnoSNvdWNYobiLMTlJSN9EFYvPnemihE+Wul4fzn+iMVPtbzYRYzO rN59dIeeTx7xFsWv3nn5 =szZi -----END PGP SIGNATURE----- --m8RPluiNA7RIyL8J--