From patchwork Sun Apr 29 22:04:24 2007 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artur Skawina X-Patchwork-Id: 12454 Received: from mx12.go2.pl ([193.17.41.142] helo=poczta.o2.pl) by www.linuxtv.org with esmtp (Exim 4.50) id 1HiHVq-0001s4-9t for vdr@linuxtv.org; Mon, 30 Apr 2007 00:04:58 +0200 Received: from poczta.o2.pl (mx12 [127.0.0.1]) by poczta.o2.pl (Postfix) with ESMTP id 7C5FB3E807A for ; Mon, 30 Apr 2007 00:04:25 +0200 (CEST) Received: from dku126.neoplus.adsl.tpnet.pl (dku126.neoplus.adsl.tpnet.pl [83.24.24.126]) by poczta.o2.pl (Postfix) with ESMTP for ; Mon, 30 Apr 2007 00:04:25 +0200 (CEST) Received: (qmail 8286 invoked from network); 29 Apr 2007 22:04:24 -0000 Received: from unknown (HELO ?172.19.43.221?) (172.19.43.221) by 172.19.43.250 with SMTP; 29 Apr 2007 22:04:24 -0000 Message-ID: <46351668.3050303@o2.pl> Date: Mon, 30 Apr 2007 00:04:24 +0200 From: Artur Skawina User-Agent: Thunderbird 3.0a1 (X11/20070428) MIME-Version: 1.0 To: Oliver Endriss X-Enigmail-Version: 0.95b Cc: VDR Mailing List Subject: [vdr] remote plugin ignoring some keys X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2007 22:04:58 -0000 Status: O X-Status: X-Keywords: X-UID: 12756 A while ago the remote plugins "telnet" server started acting strangely here; it would sometimes ignore all cursor and function keys, yet other keys would work perfectly. I'm not sure when exactly this began, most likely a newer kernel triggered this. It does not happen always, but when it does it makes navigating the OSD practically impossible. Turns out the remote plugin gets confused when a read() call returns not a full escape sequence, but just the first \0x27 byte and the next read() receives the remaining two or three bytes. And this is exactly what happens (the client for some reason actually sends two tcp packets containing just eg "\0x1b" and "\0x5b\0x43"). This quick patch made the remote osd usable again; it isn't perfect as keys can still be lost (see comments), but it's a huge improvement - only some key repeats are dropped, not all multibyte sequences. artur diff -urNp remote-0.3.9.org/remote.c remote-0.3.9/remote.c --- remote-0.3.9.org/remote.c 2006-12-03 14:46:55.000000000 +0000 +++ remote-0.3.9/remote.c 2007-04-29 20:45:13.000000000 +0000 @@ -517,6 +517,27 @@ uint64_t cRemoteDevTty::getKey(void) uint64_t code = 0; n = read(fh, &code, sizeof code); + + if (code==27 && n==1) + { + // Ugh. What happened: user pressed a key that generates an escape + // sequence (eg up/down) and we got only the first '\e'; now we have + // to fetch the remaining bytes as otherwise we end up ignoring almost + // every such key press and navigating the osd becomes impossible. + // We try to read more bytes and hope that the result makes sense; + // this often works, but not always. When eg holding down a key we + // can receive several (repeated) sequences and these are then ignored. + // Dropping a few key presses (mostly repeats) is still much better + // than dropping nearly _all_ of them... + // (Unfortunately the sequences do differ in length, hence either + // parsing them or matching them w/ the expected ones would be needed + // to avoid loosing sync here) + int m = read(fh, ((char*)&code)+1, sizeof code-1); + if (m > 0) + n += m; + } + //dsyslog("cRemoteDevTty::getKey: %d %lld", n, code); + return (n > 0) ? code : INVALID_KEY; }