[patch] add keymap data to make random laptop vendor keys work

[Matthew Garrett]

I'm not /entirely/ clear on what the problem space here is, so I'd like 
to just try to clear that up first.

For the most part, USB and ADB keyboards are already dealt with, so lets 
concentrate on AT ones. There's two cases here:

1) Keyboards built into the machine
2) External keyboards

(1) is fairly straightforward. We can key off SMBIOS data at boot-time 
and make sure that the kernel's table matches reality. (2) is hard, due 
to there being no useful ID strings in the PS/2 protocol. We'll get back 
to that later.

For almost all use-cases, the reason we care about the keyboard setup is 
because we want X applications to receive the appropriate keysym when a 
key is pressed. Assuming that all the keys are mapped to /a/ keycode 
(generally the case on external keyboards, much less so on laptop 
keyboards), we have two ways of achieving that - we can modify the 
keycode in order map it to a standard keycode, or we can modify the 
keycode->keysym mapping. The first of these requires root privileges, 
the second doesn't.

In an ideal world, we'd be able to map the keyboard appropriately at 
boot time and everything would get the correct keysyms and the world 
would be happy. However, realistically we can only do this for case (1) 
above. Case (2) leaves us with a more awkward situation. Do we try to 
remap the keycodes (something that will require root privileges), or do 
we just get the user to change their X keymap?

If we decide that the "correct" thing to do is to map external keyboards 
at boot time (ps/2 hotplug is not realistically expected to work, so we 
can ignore that case) or in response to some user configuration, then we 
probably also want to remove the majority of keyboard definitions from X 
- they'd only confuse things. But doing that without breaking existing 
setups or user expectation may be awkward.

There's also the mad corner case of people plugging external keyboards 
into their laptops. I /suspect/ (but haven't verified) that there's no 
way of telling the difference between the keyboards. If both of them 
produce the same scancode for different keys, we've already lost.

Before deciding what the solution is here, I think we need to come to 
some sort of conclusion about what we want the user experience to be.
-- 
Matthew Garrett | mjg59 at srcf.ucam.org