Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S272943AbTHKR7P (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 11 Aug 2003 13:59:15 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S273031AbTHKR66
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 11 Aug 2003 13:58:58 -0400
Received: from mail.convergence.de ([212.84.236.4]:21454 "EHLO
	mail.convergence.de") by vger.kernel.org with ESMTP id S272963AbTHKR4p
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 11 Aug 2003 13:56:45 -0400
Date: Mon, 11 Aug 2003 19:56:42 +0200
From: Johannes Stezenbach <js@convergence.de>
To: Gerd Knorr <kraxel@bytesex.org>
Cc: Flameeyes <dgp85@users.sourceforge.net>, Pavel Machek <pavel@suse.cz>,
       Christoph Bartelmus <columbus@hit.handshake.de>,
       LIRC list <lirc-list@lists.sourceforge.net>,
       LKML <linux-kernel@vger.kernel.org>, vojtech@suse.cz
Subject: Re: [PATCH] lirc for 2.5/2.6 kernels - 20030802
Message-ID: <20030811175642.GC2053@convergence.de>
Mail-Followup-To: Johannes Stezenbach <js@convergence.de>,
	Gerd Knorr <kraxel@bytesex.org>,
	Flameeyes <dgp85@users.sourceforge.net>,
	Pavel Machek <pavel@suse.cz>,
	Christoph Bartelmus <columbus@hit.handshake.de>,
	LIRC list <lirc-list@lists.sourceforge.net>,
	LKML <linux-kernel@vger.kernel.org>, vojtech@suse.cz
References: <1060616931.8472.22.camel@defiant.flameeyes> <20030811163913.GA16568@bytesex.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030811163913.GA16568@bytesex.org>
User-Agent: Mutt/1.5.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1502
Lines: 37

Gerd Knorr wrote:
> 
> > We can drop /dev/lirc*, and use input events with received codes, but I
> > think that lircd is still needed to translate them into userland
> > commands...
> 
> That translation isn't done by lircd, but by the lirc_client library.
> This is no reason for keeping lircd as event dispatcher, the input layer
> would do equally well (with liblirc_client picking up events from
> /dev/input/event<x> instead of lircd).

IMHO there's one problem:

If a remote control has e.g. a "1" key this doesn't mean that a user
wants a "1" to be written into your editor while editing source code.
The "1" key on a remote control simply has a differnt _meaning_ than
the "1" key on your keyboard -- depending of course on what the user
thinks this key should mean.

- users should be able to prevent remote keys from being fed into
  the normal keyboard input queue; non lirc aware programs should
  not recieve these events
  (OTOH, if you use an IR keyboard...)
- IR events should reach the applications independant of X keyboard
  focus (well, maybe; the user should be able to decide)

With the current input subsystem, the only possiblity is lircd
grabbing the remote events with EVIOCGRAB, and passing them
on to the applications.


Johannes
-
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/