From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] Paravirt framebuffer backend tools [2/5] Date: Fri, 08 Sep 2006 10:23:11 -0400 Message-ID: <45017CCF.9050707@cs.utexas.edu> References: <20060904090150.GC4812@cam.ac.uk> <44FC224D.3090300@bull.net> <20060906091505.GD3257@cam.ac.uk> <44FEB3DE.5070502@bull.net> <20060906171006.GA5306@cam.ac.uk> <44FFCAC0.6060809@bull.net> <20060907083848.GA3078@cam.ac.uk> <45016F8E.1030300@cs.utexas.edu> <20060908141248.GA6845@cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060908141248.GA6845@cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steven Smith Cc: Laurent Vivier , xen-devel , Markus Armbruster , sos22@srcf.ucam.org, Jeremy Katz List-Id: xen-devel@lists.xenproject.org Steven Smith wrote: >> I'm a bit surprised here. If we generate a KEY_Q event in Linux that >> may show up as a KEY_A key? There are keysyms for all the extended keys >> I thought. >> > I'm glad I'm not the only one who finds this confusing. :) > And I've been trying to figure this out longer :-) > The KEY_ constants in linux/input.h are a lot closer to scancodes than > to traditional X-style keysyms. This becomes obvious once you notice > that there's no KEY_COLON, and there's only one KEY_A rather than a > KEY_A and a KEY_a. While there is some small amount of normalisation, > so that you can mostly use the same keymaps for (say) AT and USB > keyboards, input core key events are best thought of as scan codes. > Calling them KEY_A etc. is more than a little bit deceptive, since > they actually refer more to places on the keyboard than actual > characters. > Okay, I didn't realize the KEY_ constants weren't keycodes. I guess we're stuck using a keymap :-/ Regards, Anthony Liguori > The actual key mapping is implemented in drivers/char/keyboard.c (look > for key_maps), and we're going to have to go through that whether we > want to or not. > > Of course, I completely failed to understand what was going on here a > couple of days ago, so there's a decent chance I've failed to > understand this time as well. > > Steven. >