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

On Fri, 2009-12-04 at 22:45 -0500, Jon Smirl wrote:
On Fri, Dec 4, 2009 at 8:48 PM, Andy Walls <awalls@xxxxxxxxx> wrote:
On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote:
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus <lirc@xxxxxxxxxxxx> wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
codes. Anyone here has docs on the XMP protocol?

Assuming a general purpose receiver (not one with fixed hardware
decoding), is it important for Linux to receive IR signals from all
possible remotes no matter how old or obscure?

Importance of any particular requirement is relative/subjective. As is
usefulness of any existing functionality.

Personally, I just think it's cool to pick up a random remote and use
Linux to figure out its protocol and its codes and get it working.

You are a technical user.

Yes, I agree. I do not know what percentage of current Linux users are
technical vs non-technical, so I cannot gauge the current improtance.

I can see the trend line though: as time goes by, the percentage of all
linux users that have a technical bent will only get smaller.




I've been working off the premise of getting rid of obscure remotes
and replacing them with a universal one. The universal one can be set
to send a common protocol like JVC or Sony. That implies that we only
need one or two protocol decoders in-kernel which greatly reduces the
surface area of the problem.

The design should serve the users, the users should not serve the
design. If the reduction of requirements scope starts forcing users to
buy new hardware, are we really serving the users or just asking them to
pay to compensate for our shortcomings?

Use of arbitrary remotes is a complex process. It almost certainly can
not be done in a transparent "just works" manner.

Let me rephrase, is it ok to tell people to buy a new remote if they
want to avoid a complex, technical configuration process that isn't
even guaranteed to work (they might have a 56K remote and a 38K
receiver or a Sony remote and a fixed RC-5 receiver).

"Recommended hardware" to guide users is usually an acceptable concept.

I have a feeling though, we may end up with a lot of "hey I got this
remote and video card on eBay and ..."

If the in kernel IR Rx handling is going to be really limited in trying
to "keep it simple", then that remote control hardware recommendation
should probably be strictly "the remote bundled with your IR receiver
hardware" to handle the most important use case for the in kernel IR Rx
handling to meet.



I'm not proposing that we prevent arbitrary remotes from working,
you're just going to need to expend more effort to make them work.
For example, you have to have a fair amount of IR knowledge to figure
out why those two cases above don't work. You might have to install
LIRC and futz with irrecord and build your own config files and
mapping tables, etc...

It doesn't have to only be a universal remote, we can pre-install
mapping tables for the remotes commonly shipped with the v4l hardware.

At least one vendor, has shipped two different type of remote with the
same board over the years. Also MCE versions of cards usually ship with
an MCE remote versus the standard one.

I think it still could be possible to avoid a user interview process,
but I suspect you'll need a userspace set of "scripting" tools to take
detection data from the kernel and select the right kepymap.



When the v4l drivers load they could even poke the default map for
their bundled remotes directly into the input system if they wanted
to. Doing that might save a lot of config issues.

They do that right now (well some of them and ir-kbd-i2c). But there is
*no* intelligence beyond the most current or popular remote for a board.
Also, some things require things a manual or scripted module load by the
user: ir-kbd-i2c and lirc_i2c can't currently hook to the same I2C
device at once, so the user has to set one or the other up to be loaded.


How this for new goals?
Specific IR drivers autoload maps for their bundled remotes by
poking them into the input subsystem during module load
IR always has default map for a universal remote - it provides five
devices and uses a common protocol like JVC (may not work for fixed
hardware, you have to set these five common devices into the universal
remote)
All of these maps can be overriden with user space commands (which
lets you configure funky remotes)

This looks like it just adds the option for the user to trade away
mental effort with purchasing power (for a universal remote). Not an
unacceptable trade for many people I guess.

I suppose it gives the user one option than he had before, if you have a
target set of universal remote hardware. I'd like to see some vendor
diversity in that target set of "just works" universal remotes.




My whole thought on the in-kernel IR Rx implementation is try to do it
all, or do just enough to get by.

The just works case is improtant enough for me to relent that something
should reside in kernel. I'm certainly OK with folks not spending a lot
of effort on it and not adding lots of code in kernel, so it works just
enough to hit the ground running for 80% of users. But if that's the
case, do we need to also allow LIRC to process more than just raw pulse
data?


BTW, I found this breif a while ago that gives an algorithm for multiple
protocol recognition/discrimination:

http://www.audiodevelopers.com/temp/Remote_Controls.ppt

Maybe this would be easier for protocol detection than running
"parallel" decoders that spit out an answer and a confidence factor.


Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Same Problem
    ... It's the small black IR transmitter attached to the IR cable.The transmitter part gets affixed to the remote sensor area of the Set Top Box in front of the IR Receiver. ... IR Hardware Not Detected on Vista Ultimate ... It worked fine with COX TV, but when I switched to Verizon FIOS it would not get past the IR Hardware/cable detection problem. ...
    (microsoft.public.windows.mediacenter)
  • Re: Windows Media Centre useless without remote?
    ... can do it change the channel on the SAT receiver. ... I will NEVER need to use the IRB since if I want to PVR something I ... I have to attach a piece of hardware that is useless to me just so I can ... remote controls so why make an IRB manditory? ...
    (microsoft.public.windows.mediacenter)
  • Re: VPN Issue
    ... This really sounds more and more like hardware. ... remote location over RWW, but the server doesn't have outbound Internet? ... SBS is using for Internet - in other words, ...
    (microsoft.public.windows.server.sbs)
  • Re: BCP Domain Disaster Recovery..., Which way should i go??!!??
    ... The important thing for you to do regardless of the plan is to do ... We have just invested in a dark fibre connection to a remote location ... Build the DC's on either separate hardware or on virtual machines. ...
    (microsoft.public.windows.server.active_directory)
  • BCP Domain Disaster Recovery..., Which way should i go??!!??
    ... Our IT area is only responsible for providing support for two domains ... We have just invested in a dark fibre connection to a remote location ... Build the DC's on either separate hardware or on virtual machines. ... we may need to re-connect a separate link to the root forest ...
    (microsoft.public.windows.server.active_directory)