All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: Hans de Goede <j.w.r.degoede@hhs.nl>
Cc: Jiri Kosina <jikos@jikos.cz>, "H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stanislav Brabec <sbrabec@suse.cz>
Subject: Re: Proposal: change keycode for scancode e0 32 from 150 to 172
Date: Wed, 13 Jun 2007 15:02:08 +0200	[thread overview]
Message-ID: <20070613130208.GG19888@suse.cz> (raw)
In-Reply-To: <466FB80E.7050902@hhs.nl>

On Wed, Jun 13, 2007 at 11:25:34AM +0200, Hans de Goede wrote:
> Jiri Kosina wrote:
> >On Tue, 12 Jun 2007, H. Peter Anvin wrote:
> >
> >>In PS/2 mode it reports E0 32 which gets converted to keycode 150. In 
> >>USB mode it reports E0 02 which gets converted to keycode 172.
> >>I don't know if it's the keyboard itself that's being inconsistent, or 
> >>if it is the table in usbkbd.c that's broken (in which case it should be 
> >>fixed to be consistent with the keyboard in PS/2 mode.)
> >
> >Hi Peter,
> >
> >First, usbkbd.c has very probably zero business with this - the mappings 
> >are being done in hid-input.c, usbkdb.c is only for embedded/debugging 
> >cases, and is almost never used on modern systems (see the corresponding 
> >Kconfig help text).
> >
> >>You seem to be of the opinion that "usb behaviour is correct", but don't 
> >>give any motivation why usb should take precedence.  Offhand, I would 
> >>expect there to be fewer translation layers for PS/2 and would therefore 
> >>assume PS/2 is more inherently correct.
> >
> >For USB, we have Hid Usage Pages, which define this to be KEY_HOMEPAGE. 
> >There is no such specification for PS/2 though, so what Hans is proposing 
> >is to make it consistent with behavior of USB HID devices, which I agree 
> >with.
> 
> Good to hear, so as everyone smees to agree, shall I write a (massive, 
> complex, intrusive) patch to fix this, or are there until now silent 
> parties that object?

Just don't forget to update the char/keyboard.c scancode synthesis table
to generate e0 32 for keycode 172 instead for the current 150.

-- 
Vojtech Pavlik
Director SuSE Labs

  parent reply	other threads:[~2007-06-13 13:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-12 21:47 Proposal: change keycode for scancode e0 32 from 150 to 172 Hans de Goede
2007-06-12 22:29 ` H. Peter Anvin
2007-06-13  6:06   ` Hans de Goede
2007-06-13  9:18   ` Jiri Kosina
2007-06-13  9:25     ` Hans de Goede
2007-06-13  9:32       ` Jiri Kosina
2007-06-13 13:45         ` Dmitry Torokhov
2007-06-18 22:59           ` PATCH: " Hans de Goede
2007-06-19 13:44             ` Vojtech Pavlik
2007-06-13 13:02       ` Vojtech Pavlik [this message]
2007-06-13 10:38   ` Proposal: " Vojtech Pavlik
2007-06-14 12:35     ` Stanislav Brabec
2007-06-13 10:29 ` Vojtech Pavlik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070613130208.GG19888@suse.cz \
    --to=vojtech@suse.cz \
    --cc=hpa@zytor.com \
    --cc=j.w.r.degoede@hhs.nl \
    --cc=jikos@jikos.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sbrabec@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.