linux-kernel - Re: [patch 04/33] m68k: Atari keyboard and mouse support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0705032245550.2956@scrub.home>
Date:	Thu, 3 May 2007 23:01:23 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Michael Schmitz <schmitz@...l.biophys.uni-duesseldorf.de>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-m68k@...r.kernel.org, linux-kernel@...r.kernel.org,
	Michael Schmitz <schmitz@...ian.org>
Subject: Re: [patch 04/33] m68k: Atari keyboard and mouse support.

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/