Hi,
On Thu, 3 May 2007, Dmitry Torokhov wrote:
I never said that. Many keyboard _types_ need a separate key mapping.
Localization is a completely different problem (and could be solved via
separate localization tables).
Most of it can be solved in userspace and we wouldn't have to enumerate
every possible single key the kernel never cares about in <linux/input.h>.
I am not sure that solving it all in userspace is right solution.
What userspace are you talking about? There is one main user - X, for it
and all the rest you could provide a simple input library.
Consider a sleep button. It can be hooked up via ACPI, located on AT
keyboard, USB keyboard or even on a remote control or some userspace
daemon getting data from the network. If kernel just passes raw data
to userspace then userspace programs need to know all these potential
sources and handle them separately. But with unified input device
interface userspace program only needs to monotor appearance of new
event devices, latch onto them and wait for EV_KEY/KEY_SLEEP. And it
is not much burden for the kernel because kernel already interfaces
with all these devices. In fact there probably savings because kernel
uses single interface layer.
If the kernel would do it properly, you would have a point...
You still completely ignore the problem of how said application should
properly support multiple keyboard mappings...
I am afraid this statement is too vague, we need to discuss specific
scenarios...
Consider this scenario:
You use 2 PS/2 keyboards with your laptop - built-in and external one
on a separate serio port. Your built-in has media keys generating some
non-standard scancodes. The external one also has same media keys but
generating different set of keycodes. With unified input events you
can "fix" your keboards to generate same input events and the rest of
your stack does not care.
That's not the problem. Your keycode mapping has no idea about alternative
mappings. How does the application know that "Shift"+"2" may mean '"' or
'@'?
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
