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

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: <1259024037.3871.36.camel@palomino.walls.org>
Date:	Mon, 23 Nov 2009 19:53:57 -0500
From:	Andy Walls <awalls@...ix.net>
To:	Christoph Bartelmus <lirc@...telmus.de>
Cc:	khc@...waw.pl, dmitry.torokhov@...il.com, j@...nau.net,
	jarod@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	mchehab@...hat.com, superm1@...ntu.com
Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was:
 Re: [PATCH 1/3 v2] lirc core device driver infrastructure

On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> Czesc Krzysztof,
> 
> on 23 Nov 09 at 15:14, Krzysztof Halasa wrote:
> [...]
> > I think we shouldn't at this time worry about IR transmitters.
> 
> Sorry, but I have to disagree strongly.
> Any interface without transmitter support would be absolutely unacceptable  
> for many LIRC users, including myself.

I agree with Christoph.  

Is it that the input subsystem is better developed and seen as a
leverage point for development and thus an "easier" place to get results
earlier?  If so, then one should definitely deal with transmitters early
in the design, as that is where the most unknowns lie.

With the end of analog TV, people will have STBs feeding analog only
video cards.  Being able to change the channel on the STB with an IR
transmitter controlled by applications like MythTV is essential.

And on some different notes:

I generally don't understand the LIRC aversion I perceive in this thread
(maybe I just have a skewed perception).  Aside for a video card's
default remote setup, the suggestions so far don't strike me as any
simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
already works for both transmit and receive and has existing support in
applications such as MythTV and mplayer.

I believe Jarod's intent is to have the LIRC components, that need to be
in kernel modules, moved into kernel mainline to avoid the headaches of
out of kernel driver maintenance.  I'm not sure it is time well spent
for developers, or end users, to develop yet another IR receive
implementation in addition to the ones we suffer with now.

I would also note that RC-6 Mode 6A, used by most MCE remotes, was
developed by Philips, but Microsoft has some sort of licensing interest
in it and it is almost surely encumbered somwhow:

http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt

"Microsoft recommends the Microsoft-Philips IR protocol (based on RC6)
              * You can become a licensee at no charge to you
[...]
  * How to license RC6
      * Contact RemoteMC @ microsoft.com for license agreement"

I would much rather that RC-6 be handled as much as possible in user
space than in the kernel.  LIRC userspace components already handle it,
IIRC.

Regards,
Andy "LIRC Fan-Boy" Walls

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