Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S637743AbXECVDb (ORCPT ); Thu, 3 May 2007 17:03:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S637736AbXECVDb (ORCPT ); Thu, 3 May 2007 17:03:31 -0400 Received: from scrub.xs4all.nl ([194.109.195.176]:1972 "EHLO scrub.xs4all.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031352AbXECVD3 (ORCPT ); Thu, 3 May 2007 17:03:29 -0400 Date: Thu, 3 May 2007 23:01:23 +0200 (CEST) From: Roman Zippel X-X-Sender: roman@scrub.home To: Dmitry Torokhov cc: Michael Schmitz , Geert Uytterhoeven , Linus Torvalds , Andrew Morton , linux-m68k@vger.kernel.org, linux-kernel@vger.kernel.org, Michael Schmitz Subject: Re: [patch 04/33] m68k: Atari keyboard and mouse support. In-Reply-To: Message-ID: References: <20070501195052.390551603@mail.of.borg> <20070501195129.842338339@mail.of.borg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2382 Lines: 55 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 . > > > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/