Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Ferenc Wagner
Mauro Carvalho Chehab writes:

 Jon Smirl wrote:

 This model is complicated by the fact that some remotes that look
 like multi-function remotes aren't really multifunction. The remote
 bundled with the MS MCE receiver is one. That remote is a single
 function device even though it has function buttons for TV, Music,
 Pictures, etc.

 An unsolved question on my mind is how should we map such IR's? Should
 we provide a way for them to emulate a multifunction IR (for example,
 after pressing TV key, subsequent keystrokes would be directed to the
 TV evdev device?), or should we let this up to some userspace app to
 handle this case?

This case feels similar to that of Caps Lock, Num Lock and Scrool Lock,
but I don't know if that scheme could be applied here.
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [RFC v2] Another approach to IR

2009-12-04 Thread Ferenc Wagner
Dmitry Torokhov writes:

 On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
 Ferenc Wagner wrote:
 Mauro Carvalho Chehab writes:
 We should not forget that simple IR's don't have any key to select the 
 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

 Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
 media inputs in a device/application. My receiver accepts codes like

Sorry, my point wasn't the event names, I picked them for their
superficial correspondence to the TV, DVD, SAT etc. buttons found on
multifunction remotes.  Obviously I picked wrong.

I was also wrong to assume that remotes with such buttons are always
multifunction remotes in the sense that they are meant to control
separate devices.  As Mauro pointed out, (some) bundled remotes with
such buttons aren't; thus I wouldn't consider them multifunction at all.
They simply have some extra buttons labelled TV, DVD etc, which probably
shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry
different semantics) but should be mapped to something else.  Or not, if
these buttons change some internal decoder state instead, modifying the
mapping or destination input device of the other keys.

It's just a different scenario, where the kernel could reasonably give
rather different representations to simple applications aiming at
plugplay: letting through the function change events untouched, or
masking and using them internally.

True multifunction devices don't send such events, the TV, DVD etc
buttons on them change their internal state and the scan codes sent by
the other keys, if I understand this correctly.

I'd prefer if these two behaviours could be abstacted from, and the
input layer interface would provide destination selection events +
generic events, or (to be defined) device specific events only in either
case.  Is that possible or even reasonable?

Ps: I'm writing this in the hope to clean up the landscape and possibly
help in choosing the best design.  I'm not at all familiar with IR, and
the above distinction was pretty surprising for me.  Also, I'm just
lurking here, so don't take me too seriously. :)
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Ferenc Wagner
Mauro Carvalho Chehab writes:

 Dmitry Torokhov wrote:

 On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:

 Now I understand that if 2 remotes send completely identical
 signals we won't be able to separete them, but in cases when we
 can I think we should.

 They are the same key events (Lets's say KEY_PLAY) but one is
 supposed to affect CD player while another DVD player
 application. Evdev will not be able to distinguish them but if we had
 2 separate devices then applications could read from the one thet
 user assigned to them.

 This is clear, but the point is that the two distinguish scancodes can
 (and, in practice, will) be generated by the same IR. For example, my
 Satellite IR produces two different sets of codes. if you press SAT,
 all keys you press after that will have the sat address. If you
 press TV, they'll get a different address.

The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
by any remote (ok, I'm stretching it a bit).  Instead, a multifunction
remote (or two distinct remotes) would send different scan codes[1],
which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
Btw. the former is already defined, besides the generic KEY_PLAY.

Even if all this worked, user space would need integration with
hal/devicekit to open the new input devices appearing on the fly (if
it's initiated by the arrival of a scan code belonging to some new
protocol), and also be able to decide whether the new event source is
for it or not.

Given that commodity home appliances manage not to be confused by
multiple or multifunction remotes, decent software should be able to do
so as well.

[1] scan codes in the broadest possible sense, containing vendor,
address and whatever, and only treating the case which is possible to
handle in principle.
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-11-27 Thread Ferenc Wagner
Jon Smirl writes:

 On Fri, Nov 27, 2009 at 12:29 PM, Christoph Bartelmus 

 Maybe we decide to take the existing LIRC system as is and not
 integrate it into the input subsystem. But I think there is a window
 here to update the LIRC design to use the latest kernel features.

 If it ain't broke, don't fix it.  [...]

 We already agreed last year that we can include an interface in
 lirc_dev that feeds the signal data to an in-kernel decoder if noone
 from userspace reads it.  [...]

 I also understand that people want to avoid dependency on external
 userspace tools. All I can tell you is that the lirc tools already do
 support everything you need for IR control. And as it includes a lot of
 drivers that are implemented in userspace already, LIRC will just continue
 to do it's work even when there is an alternative in-kernel.

 Christoph, take what you know from all of the years of working on LIRC
 and design the perfect in-kernel system.


I'm reading this thread with great interest.  Thank you (plural) for the
very informative conversation, I think I learnt a lot.  But now I
somehow lost the point, please correct me if the following is wrong.

It looks like having lirc_dev (or a similar raw interface) is a must.
It could be disguised as an input device, or changed in various ways,
but is it worth the effort?  As I understand Christoph, he does not want
to do so, because he finds it wasted work, and also there's already a
*single* user space daemon using it and doing everything users could
want.  Except for plugplay.

On the other hand, a one-liner could make in-kernel decoding possible,
so those who haven't got lircd running could have plugplay easily, if
somebody writes the necessary in-kernel decoders to feed the input
subsystem (which lircd also does, through uinput).

But even if you can't find anybody at the moment to write those, this is
still good stuff (I don't know about the code), which is hurt by being
developed out of kernel.  Is there any reason to keep this so?
Admittedly, I don't know why /dev/mouse is evil, maybe I'd understand if
somebody pointed me to some reading.
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at