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, Mauro Carvalho Chehab wrote:

> On Sun, 05 Apr 2009 18:00:04 -0400
> Andy Walls <awalls@xxxxxxxxx> 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 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