Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 5 Apr 2009, Mike Isely wrote:
> 1. The switch statement in ir-kbd-i2c.c:ir_attach() is apparently
> implicitly trying to assume a particular type of remote based on the I2C
> address of the IR receiver it's talking to.  Yuck.  That's really not
> right at all.  The IR receiver used does not automatically mean which
> remote is used.  What if the vendor switches remotes?  That's happened
> with the PVR-USB2 hardware in the past (based on photos I've seen).
> Who's to say the next remote to be supplied is compatible?

IMHO, the way the remote supported is compiled into the kernel is absurd.
The system I setup 12 years ago was better than this.  At least the remote
was compiled into a userspace daemon and multiple remotes were supported at
the same time.  The keycode system I used had a remote id/key id split, so
you could have volume up key on any remote control the mixer but make the
power buttons on different remotes turn on different apps.

> 3. A given IR remote may be described by much more than what 'scan
> codes' it produces.  I don't know a lot about IR, but looking at the
> typical lirc definition for a remote, there's obvious timing and
> protocol parameters as well.  Just being able to swap scan codes around
> is not always going to be enough.

A remote typically sends a header sequence of a long pulse and space before
the code.  The length of the pulse on the space varies greatly by remote
and makes a good way to identify the remote when multiple ones are
supported.

Then a pulse coded remote sends a sequence bits, usually 8 to 32.  The
length of the pulse identifies 1s or 0s.  Different remotes have different
pulse lengths and different spaces between them.  RC5 remotes use
Manchester encoding for this part.

When you hold a key down some remotes just repeat the same sequence over
and over again.  Some repeat the scan code but omit the header part.  Some
send out a special pulse sequence to indicate the last key is being held
down.  With the latter two methods you can tell the difference between a
key being held down and a key being pressed repeatedly.  With the first you
have guess based on how fast the repeats are coming in.  This is very
different than a keyboard, which sends a code when you press a key and
another when you release it.

The rate at which remotes repeat varies greatly.  You might find that one
remote makes your volume change annoying slowly while another is much too
fast to be usable.  Remote keys usually start repeating without delay, so
if you let a toggle like 'mute' repeat it becomes almost impossible to hit
it just once.  Entering numbers becomes impossible as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux