On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
> On Sun, 05 Apr 2009 18:00:04 -0400
> Andy Walls <[email protected]> wrote:
>
> > On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> >
> >
> > > What can not be translated to the input system I would like to know.
> > > Andy seems to have closer looked into that.
> >
> > 1. IR blasting: sending IR codes to transmit out to a cable convertor
> > box, DTV to analog convertor box, or similar devices to change channels
> > before recording starts. An input interface doesn't work well for
> > output.
>
> On my understanding, IR output is a separate issue. AFAIK, only a very few
> ivtv
> devices support IR output. I'm not sure how this is currently implemented.
For the pvrusb2 driver, MCE style 24xxx devices (2nd generation 24xxx)
and HVR-1950 devices have IR blasting capabilities. At the moment,
people have gotten this to work on the 24xxx model with the appropriate
lirc driver. In theory it should be doable for HVR-1950 as well (and
the pvrusb2 does what is needed to make it possible) but I don't think
anyone has succeeded there yet.
Sure IR output as a concept and interface is a separate issue. But it
can be implemented in the same chip (which is the case in the two
examples I list above). So the issue is not separate; it must be dealt
with as a whole. Two drivers implementing different features but trying
to share one chip is just not fun.
>
>
> > 2. Sending raw IR samples to user space: user space applications can
> > then decode or match an unknown or non-standard IR remote protocol in
> > user space software. Timing information to go along with the sample
> > data probably needs to be preserved. I'm assuming the input interface
> > currently doesn't support that.
>
> If the driver processes correctly the IR samples, I don't see why you would
> need to pass the raw protocols to userspace. Maybe we need to add some ioctls
> at the API to allow certain controls, like, for example, ask kernel to decode
> IR using RC4 instead or RC5, on devices that supports more than one IR
> protocol.
Ugh. Why should v4l-dvb get into this business when it's already solved
somewhere else? In userspace even.
I see in so many other places people arguing for V4L functionality that
needs to be kicked out of the kernel and put into userspace. For
example, there's all that silliness over pixel formats that I'm soon
going to have to deal with...
Yet in this case with IR, there already exists a subsystem that does
*more* than ir-kbd-i2c.c, AND it does all the crazy configuration /
control in userspace - and yet you argue that ir-kbd-i2c.c should be
preferred? Purely because lirc is not in-tree? Well heck, lirc should
be in-tree. Let's help them get there and forget ever having to deal
with IR again ourselves. Let them do it.
>
> > That's all the Gerd mentioned.
> >
> >
> > One more nice feature to have, that I'm not sure how easily the input
> > system could support:
> >
> > 3. specifying remote control code to key/button translations with a
> > configuration file instead of recompiling a module.
>
> The input and the current drivers that use input already supports this
> feature.
> You just need to load a new code table to replace the existing one.
>
> See v4l2-apps/util/keytable.c to see how easy is to change a key code. It
> contains a complete code to fully replace a key code table. Also, the Makefile
> there will extract the current keytables for the in-kernel drivers.
>
> Btw, with only 12 lines, you can create a keycode replace "hello world!":
>
> #include <fcntl.h> /* due to O_RDONLY */
> #include <stdio.h> /* open() */
> #include <linux/input.h> /* input ioctls and keycode macros */
> #include <sys/ioctl.h> /* ioctl() */
> void main(void)
> {
> int codes[2];
> int fd = open("/dev/video0", O_RDONLY); /* Hmm.. in real apps, we
> should check for errors */
> codes[0] = 10; /* Scan code */
> codes[1] = KEY_UP; /* Key code */
> ioctl(fd, EVIOCSKEYCODE, codes); /* hello world! */
> }
I just looked at this. I freely admit I haven't noticed this before,
but having looked at it now, and having examined ir-kbd-i2c.c, I still
don't see the whole picture here:
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?
2. Your example above is opening the video device endpoint and issuing
ioctl()s that are not part of V4L. That is supposed to work?!?
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.
4. I imagine that the input event framework in the kernel has a means
for programmatic mapping of scan codes to key codes, but looking at
ir-kbd-i2c.c, it appears to only be selecting from among a very small
set of kernel-compiled translation tables. I must be missing something
here.
In an earlier post (from Andy?) some history was dug up about
ir-kbd-i2c.c. From what I understand, the only reason ir-kbd-i2c.c came
into existence was because lirc was late in supporting 2.6.x series
kernels and Gerd needed *something* to allow IR to work. So he created
this module, knowing full well that it didn't cover all possible cases.
Rather it covered the common cases he cared about. That was a while
ago. And we need to do all the cases - or at least not mess up what
already exists elsewhere that does handle the "uncommon" cases. The
lirc drivers do work in 2.6. And apparently they were on the scene
before ir-kbd-i2c.c, just unfortunately not in-tree. The lirc drivers
really need to get into the kernel. From where I'm sitting the long
term goal should be to get lirc into the kernel.
-Mike
--
Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
