On Thu, Mar 21, 2013 at 06:00:09AM +0000, Miod Vallat wrote:
> > > Well, it conflicts with the codes listed in the `USB HID to PS/2 Scan
> > > Code Translation Table'
> > 
> > Yes, but that document just lists the codes that Windows translates to
> > internally when a USB keyboard is in use.  I have no reason to believe
> > that any PS/2 device actually uses them in hardware, and good reason to
> > believe that they don't, (and wouldn't).
> 
> Hmm. You're right. According to 
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-5.html
> the IBM 122 key keyboard, which seems to be the most common 122-key
> keyboard around, matches the scan codes from your diff.

The scan codes for the other keys, (left function keys, extra keypad key,
etc), match as well.

> > > If your IBM keyboard uses different scancodes for
> > > the extra function keys, then it would be better to handle them with a
> > > specific submap, as already done in the declk or iopener submaps.
> > 
> > I'm happy to use a submap for 122 key terminal keyboards, anyway.
> 
> I think this would be easier. But on the other hand this would restrict
> the use of the extra keys to the us layout. So for the sake of
> hypothetical localized 122 key keyboards, I think your diff is the way
> to go, with a range test added to the PS/2-to-USB map converter to skip
> those keys.

I think it's safe and useful to add F13-F24 to the main us layout, but
best to leave the other extra keys to a submap.  That way, the use of
F13-F24 can be relied on as fairly standard, and we can add submaps as
required to do funky things with the left hand keys if people choose to
use them.

> > Since most of these functions do not relate to OpenBSD, I set mine to
> > switch between virtual consoles.  However, this required a hack to the
> > kernel to disable the need to hold down control and alt to select VC,
> > because that is hard-coded in wskbd.c.
> 
> That's a different story. We probably need a way to know that a given
> key has been assigned only one function, and remove the need for the two
> main command modifiers to be down in that case.

I notice that scrollback buffer keys are hard-coded to require shift
as well.  I think it would be nice to define all this somewhere in the
keyboard map, but I don't know if other people might consider it to be
unnecessarily bloating things, because the existing system works well
enough for most users, (who don't have loads of extra keys, ha! ha! ha!). 

-- 
Creamy

Reply via email to