From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK5tf-0006uU-RD for qemu-devel@nongnu.org; Mon, 04 Jul 2016 11:34:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bK5tb-0000dt-1w for qemu-devel@nongnu.org; Mon, 04 Jul 2016 11:34:55 -0400 Received: from mail-qt0-x242.google.com ([2607:f8b0:400d:c0d::242]:33417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK5ta-0000dn-T0 for qemu-devel@nongnu.org; Mon, 04 Jul 2016 11:34:50 -0400 Received: by mail-qt0-x242.google.com with SMTP id f89so11733636qtd.0 for ; Mon, 04 Jul 2016 08:34:50 -0700 (PDT) Date: Mon, 4 Jul 2016 11:34:48 -0400 From: Kevin O'Connor Message-ID: <20160704153448.GB2039@morn.lan> References: <1467370471-20554-1-git-send-email-kraxel@redhat.com> <1467370471-20554-3-git-send-email-kraxel@redhat.com> <20160701170739.GB11200@morn.lan> <1467623805.15123.166.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1467623805.15123.166.camel@redhat.com> Subject: Re: [Qemu-devel] [SeaBIOS] [RFC PATCH 2/2] serial console, input List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: seabios@seabios.org, qemu-devel@nongnu.org On Mon, Jul 04, 2016 at 11:16:45AM +0200, Gerd Hoffmann wrote: > Hi, > > > > +#define FLAG_CTRL (1<<0) > > > +#define FLAG_SHIFT (1<<1) > > > + > > > +VARLOW struct { > > > + u8 flags; > > > + u8 scancode; > > > +} termchr[256] = { > > > + [ '1' ] = { .scancode = 0x02, }, > > > > I think this table should be generated at runtime from > > kbd.c:scan_to_keycode[]. Since it doesn't change at runtime, > > malloc_fseg() / GET_GLOBAL() could be used instead of VARLOW. > > Ah, ok. Didn't notice this one can be used for ascii -> scancode > lookups. > > I'm wondering whenever it makes sense to build a reverse table. We > could simply search scan_to_keycode[] instead. Sure it is slower than a > table lookup, but still _way_ faster than any human can type, and we > would save some real-mode memory. Agreed. [...] > > There's a lot of complexity to implement buffering for > > that unusual case. I wonder if the buffer could be avoided - I played > > with it a little and came up with the below (totally untested). I'm > > not sure if it's an improvement. > > Hmm, so you avoid the buffer by maintaining an index into termseq and > matched byte count instead. Hmm. Yes, avoids the buffer and also a few > cpu cycles because you can continue searching where you left off. I > find the code flow harder to follow though. Right. Yeah, also not sure it's an improvement. Does the original code flush the multi-byte sequence on a timeout? I suspect it is important that one can hit ESC without having to type another key. Also, I'd prefer to avoid backwards gotos if possible. -Kevin