Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Oldrich, On Thu, 9 Apr 2009 21:15:30 +0200, Oldrich Jedlicka wrote: I've tried your patches with AverMedia Cardbus Hybrid (E506R) and they works fine. Thanks for testing and reporting, and sorry for the late answer. My current experience with AverMedia's IR chip (I don't know which one is on the card) is that I2C probing didn't find anything, but it got the chip into some strange state - next operation failed (so that the autodetection on address 0x40 and subaddress 0x0b/0x0d failed). OK, that makes sense. Many I2C devices only support a limited subset of the I2C protocol, and if you try to address them with a message format they don't support, their state machine goes into a bad state. That's probably what was happening there. This is the reason why we should always instantiate I2C devices explicitly when possible: whatever probing method you use, you have no guarantee that every device will like it. The chip at address 0x40 needs the write first (one byte: 0x0b or 0x0d) and immediate read, otherwise it would not respond. The saa7134's I2C 0xfd quirk (actually I would call it a hack :-)) caused failures in communication with the IR chip. I didn't know about this hack. The implementation choice seems wrong to me. The hack should be triggered only when needed, rather than by default with an exception for address 0x40. This goes beyond the scope of my patch though, and I don't want to touch that kind of code without hardware at hand to test my changes. The way I'm doing the IR reading is the same as the Windows driver does - I got the information through the Qemu with pci-proxy patch applied. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Mauro Carvalho Chehab wrote: On Tue, 07 Apr 2009 23:02:43 -0400 CityK ci...@rogers.com wrote: Regarding the KS003 ( KS007; the other mystery chip): Upon further investigation of some info from a post from last year (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html), it appears that these (assuming that they are the same IC across the various MSI, Leadtek KWorld cards; and I believe that to be true) are the AT8PS54/S56 chip from Feeling Technology ... the datasheet for that part is available through a google search probing further (as I had never heard of FT before and so I looked them up), it looks like FT renamed and/or upgraded the chip to the FM8PS54/S56 ... the near identical datasheet for that second version is also available: http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05Category=100018 From what I've investigated, several of those IR chips are micro-controllers like the one you pointed. I've seen a few boards whose IR chip is not masked. On those, I always went into some micro-controller datasheet. Those IR's with a micro-controller have some software inside it to decode one IR protocol and generate scan-code sequences that can be received via GPIO or via I2C, depending on the firmware content. The datasheet of those chips are useless, since the behaviour of the device is programmed inside their ROM/EEPROM [1]. So, even being the same chip, you could have two K007 devices with different firmwares, listening on different i2c addresses and eventually generating different scan-codes for the same IR. On the other hand, for USB devices and for bttv, saa7134 and cx88, there are some easy ways to monitor what i2c messages or GPIO pins are involved with IR. In general, the IR received messages generated by the firmware are some header, a scan code, a repeat key bit and a trailer. So, it is not hard to generate a get-key routine to get the scan code and the repeat bit from the protocol. That's why the modern ir-kbd-i2c approach is to select the proper IR parameters after binding the module, at the bridge driver. The bridge driver is the one who knows what's the IR scan code of the original IR (to set it as the default), and the proper get-key function. With the new i2c behaviour, the bridge driver can also specify the proper i2c address for each device. Cheers, Mauro [1] It doesn't seem to be practical for me to get their internal software.In general, such micro-controllers block EEPROM/ROM read of the software inside. If this is the case of this chip, the only remaining option to get the internal software would be to cut the plastic and try to see the state of each eeprom bit with the help of a good microscope. Anyway, assuming that there are some way to read the ROM content, in order to see the device behavior, one should remove the chip from the board, get the ROM/EEPROM content, write a disassembler for this processor, disassemble the code and analyse the results. This would be a real hard work, would take a lot of time, and I doubt that this would help to improve the driver, since we already know how to read scan codes from those devices. Thanks for the detailed response Mauro. I've actually been wondering about whether the specific KS00x designation/label might refer to the embedded firmware or to a dataline, so that thought is certainly consistent with your description. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi! Am Sonntag, den 12.04.2009, 13:37 -0400 schrieb CityK: Mauro Carvalho Chehab wrote: On Tue, 07 Apr 2009 23:02:43 -0400 CityK ci...@rogers.com wrote: Regarding the KS003 ( KS007; the other mystery chip): Upon further investigation of some info from a post from last year (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html), it appears that these (assuming that they are the same IC across the various MSI, Leadtek KWorld cards; and I believe that to be true) are the AT8PS54/S56 chip from Feeling Technology ... the datasheet for that part is available through a google search probing further (as I had never heard of FT before and so I looked them up), it looks like FT renamed and/or upgraded the chip to the FM8PS54/S56 ... the near identical datasheet for that second version is also available: http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05Category=100018 From what I've investigated, several of those IR chips are micro-controllers like the one you pointed. I've seen a few boards whose IR chip is not masked. On those, I always went into some micro-controller datasheet. Those IR's with a micro-controller have some software inside it to decode one IR protocol and generate scan-code sequences that can be received via GPIO or via I2C, depending on the firmware content. The datasheet of those chips are useless, since the behaviour of the device is programmed inside their ROM/EEPROM [1]. So, even being the same chip, you could have two K007 devices with different firmwares, listening on different i2c addresses and eventually generating different scan-codes for the same IR. On the other hand, for USB devices and for bttv, saa7134 and cx88, there are some easy ways to monitor what i2c messages or GPIO pins are involved with IR. In general, the IR received messages generated by the firmware are some header, a scan code, a repeat key bit and a trailer. So, it is not hard to generate a get-key routine to get the scan code and the repeat bit from the protocol. That's why the modern ir-kbd-i2c approach is to select the proper IR parameters after binding the module, at the bridge driver. The bridge driver is the one who knows what's the IR scan code of the original IR (to set it as the default), and the proper get-key function. With the new i2c behaviour, the bridge driver can also specify the proper i2c address for each device. Cheers, Mauro [1] It doesn't seem to be practical for me to get their internal software.In general, such micro-controllers block EEPROM/ROM read of the software inside. If this is the case of this chip, the only remaining option to get the internal software would be to cut the plastic and try to see the state of each eeprom bit with the help of a good microscope. Anyway, assuming that there are some way to read the ROM content, in order to see the device behavior, one should remove the chip from the board, get the ROM/EEPROM content, write a disassembler for this processor, disassemble the code and analyse the results. This would be a real hard work, would take a lot of time, and I doubt that this would help to improve the driver, since we already know how to read scan codes from those devices. Thanks for the detailed response Mauro. I've actually been wondering about whether the specific KS00x designation/label might refer to the embedded firmware or to a dataline, so that thought is certainly consistent with your description. Consistent with that, as from some first seen ever, the KS007 chip remotes seem to have always more keys than the KS003 ones. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Mon, 06 Apr 2009 23:10:36 +0200, hermann pitton wrote: Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare: Anyone out there with a MSI t...@nywhere Plus that could help with testing? Here is a link to one of the initial reports by Henry, others are close to it. http://marc.info/?l=linux-videom=113324147429459w=2 There are two different variants of that MSI card, but that undocumented KS003 chip is the same on them. Great, thanks for the pointer. If I understand correctly, the KS003 has a state machine flow which causes the chip to stop answering when an invalid address is used on the bus and start answering again when a valid address other than his own is used. As the old i2c model relied a lot on probing, I am not surprised that this was a problem in the past. But with the new model, probes should become infrequent, so I suspect that the workaround may no longer be needed... except when i2c_scan=1 is used. I'd rather keep the workaround in place for the time being, and only once the ir-kbd-i2c changes have settled, try to remove it if someone really cares. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Jean Delvare wrote: On Mon, 06 Apr 2009 23:10:36 +0200, hermann pitton wrote: Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare: Anyone out there with a MSI t...@nywhere Plus that could help with testing? Here is a link to one of the initial reports by Henry, others are close to it. http://marc.info/?l=linux-videom=113324147429459w=2 There are two different variants of that MSI card, but that undocumented KS003 chip is the same on them. Great, thanks for the pointer. If I understand correctly, the KS003 has a state machine flow which causes the chip to stop answering when an invalid address is used on the bus and start answering again when a valid address other than his own is used. As the old i2c model relied a lot on probing, I am not surprised that this was a problem in the past. But with the new model, probes should become infrequent, so I suspect that the workaround may no longer be needed... except when i2c_scan=1 is used. I'd rather keep the workaround in place for the time being, and only once the ir-kbd-i2c changes have settled, try to remove it if someone really cares. Regarding the KS003 ( KS007; the other mystery chip): Upon further investigation of some info from a post from last year (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html), it appears that these (assuming that they are the same IC across the various MSI, Leadtek KWorld cards; and I believe that to be true) are the AT8PS54/S56 chip from Feeling Technology ... the datasheet for that part is available through a google search probing further (as I had never heard of FT before and so I looked them up), it looks like FT renamed and/or upgraded the chip to the FM8PS54/S56 ... the near identical datasheet for that second version is also available: http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05Category=100018 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 05 Apr 2009 23:22:03 +0200, drunk and tired hermann pitton wrote: Hmm, I'm still happy with the broken DVB-T for saa7134 on 2.6.29, tasting some Chianti vine now and need to sleep soon, but I'm also not that confident that your saa7134 MSI t...@nywhere Plus i2c remote does work addressing it directly, since previous reports always said it becomes only visible at all after other devices are probed previously. Unfortunately I can't test it, but will try to reach some with such hardware and ask for testing, likely not on the list currently. Thanks for the heads up. I was curious about this as well. The original comment said that the MSI t...@nywhere Plus IR receiver would not respond to _probes_ before another device on the I2C bus was accessed. I didn't know for sure if this only applied to the probe sequence or to any attempt to access the IR receiver. As we no longer need to probe for the device, I thought it may be OK to remove the extra code. But probably the removal of the extra code should be delayed until we find one tester to confirm the exact behavior. Here, done. Anyone out there with a MSI t...@nywhere Plus that could help with testing? -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Andy,
On Sun, 05 Apr 2009 15:35:52 -0400, Andy Walls wrote:
--- v4l-dvb.orig/linux/drivers/media/video/ivtv/ivtv-i2c.c2009-04-04
10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-04-04
10:58:36.0 +0200
[snip]
-
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
[snip]
I just noticed you're missing address 0x71 for ivtv. At least some
PVR-150 boards have a Zilog chip at that address.
Thanks for reporting. The list above is taken directly from the
original ir-kbd-i2c driver (minus address 0x4b which Hans Verkuil told
me was useless for the ivtv and cx18 adapters). I'm all for adding
support for more boards, however I'd rather do this _after_ the i2c
model conversion is done, so that we have a proper changelog entry
saying that we added support for the PVR-150, and that it gets proper
testing. Hiding support addition in a larger patch would probably do
as much harm as good.
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009 22:35:25 -0700 (PDT)
Uri Shkolnik uri...@yahoo.com wrote:
--- On Mon, 4/6/09, Mauro Carvalho Chehab mche...@infradead.org wrote:
From: Mauro Carvalho Chehab mche...@infradead.org
Subject: Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding
model
To: Andy Walls awa...@radix.net
Cc: hermann pitton hermann-pit...@arcor.de, Jean Delvare
kh...@linux-fr.org, Janne Grunau j...@jannau.net, Hans Verkuil
hverk...@xs4all.nl, Mike Isely is...@pobox.com, is...@isely.net,
LMML linux-media@vger.kernel.org, Jarod Wilson ja...@redhat.com
Date: Monday, April 6, 2009, 4:51 AM
On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls awa...@radix.net
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.
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.
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! */
}
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe
linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
ir-kbd-i2c is a confusing name and wrong architecture if all are truly
combined together.
Why to combine interface driver (I2C) with logical implementation (RC5
samples to input device codes)?
There are many IR hardware devices which are not I2C based. Lately I added a
patch (http://patchwork.kernel.org/patch/16406/) which uses such IR device.
There should be a complete separation between I2C interface driver with RC5
(and/or RCMM) data output, to the ir-kbd (RC5/kbd, RCMM/kbd) module, which
should only convert RC5 sample to system events (either input
device/keyboard, or IOCTL events sent through the DVB characters devices to
user space).
If the code will stay combined (ir-kbd-i2c) than for other than I2C interface
drivers, we'll have to add a duplicated (redundant) logical layer to handle
the RC5 to system events layer (which already exist at the ir-kbd-i2c).
This module is just for i2c devices. Non-i2c devices are handled together with
bridge drivers. Common routines like RC5 and pulse distande decoding are at
ir-functions.c, as part of ir-common.
There's no RC5 decoding functions there. What it has is some get_key routines
that gets the data from the i2c packet and properly fills the event fields.
It should be noticed that ir-kbd-i2c is that people never cared to create one
ir-i2c-foo module for each
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Mon, 2009-04-06 at 11:04 +0200, Jean Delvare wrote: Hi Andy, I'm all for adding support for more boards, however I'd rather do this _after_ the i2c model conversion is done, so that we have a proper changelog entry saying that we added support for the PVR-150, and that it gets proper testing. Hiding support addition in a larger patch would probably do as much harm as good. Makes sens to me. Especially when I just simply, blindly added 0x71 in my initial testing, I got a kernel Oops. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009 13:48:02 -0500 (CDT) Mike Isely is...@isely.net wrote: My impression (at least for pvrusb2-driven devices) is that the later IR receivers require a completely different driver to work properly; one can't just bolt additional features into ir-kbd-i2c for this. This is the old approach: adding more stuff into ir-kbd-i2c. The new approach is to let ir-kbd-i2c to prepare for IR, but filling the protocol decoding routines and IR names after having it bound on i2c bus. So, the IR routines will be properly filled by the bridge driver (pvrusb2, in this case). In lirc's case, a different driver is in fact used. But you know this already. I haven't looked at ir-kbd-i2c in a while, but one other thing I seriously did not like about it was that the mapping of IR codes to key events was effectively hardcoded in the driver. That makes it difficult to make the same driver work with different kinds of remotes. Even if the bridge driver (e.g. pvrusb2) were to supply such a map, that's still wrong because it's within the realm of possibility that the user might actually want to use a different remote transmitter (provided it is compatible enough to work with the receiver hardware). The hardcoded keytables are just the default ones for that keyboard. As I've shown already in this thread, it can be easily replaced on userspace, and we have already an userspace tool on v4l2-apps that replaces those tables. The lirc architecture solves this easily via a conf file in userspace. In fact, lirc can map multiple mappings to a single receiver, permitting it to work concurrently with more than one remote. But is such a thing even possible with ir-kbd-i2c? I know this is one reason people tend to choose lirc. Multiple mappings based on what userspace app you're using can't be done internally. However, you can keep using lirc with event driver for those cases where you want to have multiple mappings, and this works fine. The only drawback i saw when I used lirc the last time (a long time ago) is that, when you remove an usb device, it used to flood the logs with errors (several errors by second, warning that event interface disappeared). Probably they already solved this issue. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009 21:52:31 -0500 (CDT)
Mike Isely is...@isely.net wrote:
On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls awa...@radix.net 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.
Yes, this should be considered by the same driver, but perhaps not using the
same userspace API. I'm not sure if event interface allows such usage.
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...
Removing kernel functionality breaks compatibility with legacy applications.
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?
Setting up lirc to work it is a way more complex that just plugging a
device and having IR working. For all my usages here, I prefer to just load a
different IR table than having to deal with lirc configuration stuff.
It should be users option to use lirc or just rely on the existing IR support.
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.
I agree that we should help with this. IMO, the proper way for lirc drivers for
media devices is that they should include linux-media oh the discussions about
the inclusion of those drivers, in a way that just one driver would be used,
and that the event interface will keep working by default, as currently.
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?
This is the legacy model, kept there only due to the fact that we don't really
know with 100% sure what boards were using those functions. For the new model,
you should take a look on a bridge driver, like, for example, on em28xx-cards:
void em28xx_set_ir(struct em28xx *dev, struct IR_i2c *ir)
{
if (disable_ir) {
ir-get_key = NULL;
return ;
}
/* detect configure */
switch (dev-model) {
case (EM2800_BOARD_UNKNOWN):
break;
case (EM2820_BOARD_UNKNOWN):
break;
case (EM2800_BOARD_TERRATEC_CINERGY_200):
case (EM2820_BOARD_TERRATEC_CINERGY_250):
ir-ir_codes = ir_codes_em_terratec;
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 05 Apr 2009 08:44:15 -0400 Andy Walls awa...@radix.net wrote: The scope of a complete kernel IR infrastructure goes a bit beyond I2C bus devices that are only input devices. What's the scope of what you want to tackle here? I certainly don't want to reinvent something that's going to look just like the LIRC driver model: http://www.lirc.org/html/technical.html Which already has an infrastructure for IR driver module writers: http://www.lirc.org/html/technical.html#lirc_dev As other out-of-tree drivers that have a long trip, I suspect that lirc did some assumptions, while event and v4l did different ones. Due to kernel rules to keep API's forever, we should take some care to avoid breaking the existing API in favor to another one. So, this probably means some lirc redesign, in order to get his way to kernel, on a similar path that ivtv driver did. The part of lirc that I'm concerned with are the ones that work with GPIO and I2C devices and the API. Do we just convert lirc_dev, lirc_i2c, and lirc_zilog to a cleaned up set of in kernel modules? We should cover also the lirc gpio module(s). lirc_i2c can certainly be broken up into several modules: 1 per supported device. I don't think that breaking it into one per device is the better approach. IMO, we need a common i2c glue (like what ir-kbd-i2c provides, if we remove the legacy stuff) that it is IR independent. the IR dependent parts can be part of ir-common module or eventually we can split it into sub-modules. Should these create an input device as well to maintain compatability with apps expecting an ir-kbd-i2c like function? For sure. The event interface is the kernel way for input devices. There are also other IR devices (like IR mouses and keyboards) already handled via input/event interface. On a first glance, I don't see the need to exporting raw data to userspace, although I understand why lirc needs this currently. Or do we split up ir-kbd-i2c into per device modules and in addition to the input event interface, have it register with the lirc_dev module? Do we leverage LIRC's lirc_dev infrastructure module at all? (I think it would be a waste of time not to do so.) IMO, the proper workflow would be to discuss lirc as a hole with Lirc people, linux-media and input/event people. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009 07:46:47 +0200 Hans Verkuil hverk...@xs4all.nl wrote: On Sunday 05 April 2009 01:05:39 Jean Delvare wrote: Hi Mike, On Sat, 4 Apr 2009 10:51:01 -0500 (CDT), Mike Isely wrote: Nacked-by: Mike Isely is...@pobox.com This will interfere with the alternative use of LIRC drivers (which work in more cases that ir-kbd). Why then is ir-kbd in the kernel tree and not LIRC drivers? It will thus break some peoples' use of the driver. Do you think it will, or did you test and it actually does? If it indeed breaks, please explain why, so that a solution can be found. Also we have better information on what i2c addresses needed to be probed based on the model of the device This is excellent news. As I said in the header comment of the patch, avoiding probing when we know what the IR receiver is and at which address it sits is the way to go. Please send me all the information you have and I'll be happy to add a patch to the series, that skips probing whenever possible. Or write that patch yourself if you prefer. - and some devices supported by this device are not from Hauppauge so you are making a too-strong assumption that IR should be probed this way in all cases. I didn't make any assumption, sorry. I simply copied the code from ir-kbd-i2c. If my code does the wrong thing for some devices, that was already the case before. And this will certainly be easier to fix after my changes than before. On top of that, the Hauppauge trick is really only the order in which the addresses are probed. Just because a specific order is better for Hauppauge boards, doesn't mean it won't work for non-Hauppauge boards. Also, unless ir-kbd has suddenly improved, this will not work at all for HVR-1950 class devices nor MCE type PVR-24xxx devices (different incompatible IR receiver). I'm sorry but you can't blame me for ir-kbd-i2c not supporting some devices. I updated the driver to make use of the new binding model, but that's about all I did. This is why the pvrusb2 driver has never directly attempted to load ir-kbd. The pvrusb2 driver however abuses the bttv driver's I2C adapter ID (I2C_HW_B_BT848) and was thus affected when ir-kbd-i2c is loaded. This is the only reason why my patch touches the pvrusb2 driver. If you tell me you want the ir-kbd-i2c driver to leave pvrusb2 alone, I can drop all the related changes from my patch, that's very easy. Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. The new mechanism is the right way to do it: the adapter driver has all the information if, where and what IR is used and so should be the one to tell the kernel what to do. Attempting to autodetect and magically figure out what IR might be there is awkward and probably impossible to get right 100%. Hell, it's wrong already: if you have another board that already loads ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c whether you like it or not, because ir-kbd-i2c will connect to your i2c adapter like a leech. So with the addition of a module option you at least give back control of this to the user. When this initial conversion is done I'm pretty sure we can improve ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. So we don't need those horrible adapter ID tests and other magic that's going on in that driver. But that's phase two. IMO, doing all those tricks to support an out-of-tree driver is the wrong approach. This is just postponing a more serious discussion about what should be done in kernel, in order to better support IR's. In the case of lirc, the userspace part has already an event interface. If the drivers are doing the right thing with their IR part, lirc can just use the event interface for all drivers. This seems to be the proper approach. From what I got from Andy and Mike's comments is that the real issue is that the IR kernel code is incomplete, broken or bad designed. So, several users and userspace apps don't rely on the kernel code but, instead, use lirc as an alternative. That's said, I propose a different approach: 1) Add some entry at feature-removal-schedule.txt posting a date to end support for out-of-tree I2C IR modules; 2) Start discussing with lirc people (and input/event maintainers if needed) about what is needed to properly support the required functionalities for a better lirc usage; 3) Propose a few API additions in order to support those functionalities; 4) apply IR patches on kernel to support the
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 06:14 -0300, Mauro Carvalho Chehab wrote: IMO, doing all those tricks to support an out-of-tree driver is the wrong approach. This is just postponing a more serious discussion about what should be done in kernel, in order to better support IR's. The tricks were to not break the current user experience by saddling them with a kernel module that they may not want. (If the tricks are needed at all - I'm will test later today.) I agree that better in kernel infrastructure needs to be in place for IR. LIRC's kernel space infrastructure module, lirc_dev, probably isn't a bad model for support of IR devices. The individual LIRC modules for supporting specific sets of devices are the ones that have problems to varying degrees. In the case of lirc, the userspace part has already an event interface. If the drivers are doing the right thing with their IR part, lirc can just use the event interface for all drivers. This seems to be the proper approach. Input event interfaces alone neglect IR blasters. From what I got from Andy and Mike's comments is that the real issue is that the IR kernel code is incomplete, broken or bad designed. So, several users and userspace apps don't rely on the kernel code but, instead, use lirc as an alternative. There is at least one other motivation: LIRC also handles a number of other hardware interfaces that are not I2C: serial ports (/dev/ttySX), parallel port, USB, etc. I happen to use the lirc_mceusb2 module for my Phillips Home IR receiver/blaster (I'm not sure if the blaster works under linux.) That's said, I propose a different approach: 1) Add some entry at feature-removal-schedule.txt posting a date to end support for out-of-tree I2C IR modules; 2) Start discussing with lirc people (and input/event maintainers if needed) about what is needed to properly support the required functionalities for a better lirc usage; 3) Propose a few API additions in order to support those functionalities; 4) apply IR patches on kernel to support the missing functionalities; The scope of a complete kernel IR infrastructure goes a bit beyond I2C bus devices that are only input devices. What's the scope of what you want to tackle here? I certainly don't want to reinvent something that's going to look just like the LIRC driver model: http://www.lirc.org/html/technical.html Which already has an infrastructure for IR driver module writers: http://www.lirc.org/html/technical.html#lirc_dev Do we just convert lirc_dev, lirc_i2c, and lirc_zilog to a cleaned up set of in kernel modules? lirc_i2c can certainly be broken up into several modules: 1 per supported device. Should these create an input device as well to maintain compatability with apps expecting an ir-kbd-i2c like function? Or do we split up ir-kbd-i2c into per device modules and in addition to the input event interface, have it register with the lirc_dev module? Do we leverage LIRC's lirc_dev infrastructure module at all? (I think it would be a waste of time not to do so.) Regards, Andy 5) remove the support for out-of-tree i2c IR modules. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Andy, On Sat, 04 Apr 2009 21:50:08 -0400, Andy Walls wrote: On Sun, 2009-04-05 at 00:51 +0200, Jean Delvare wrote: On Sat, 04 Apr 2009 09:42:09 -0400, Andy Walls wrote: I think this is way out of date for cx18 based boards. The only IR chip I know of so far is the Zilog Z8F0811 sitting at 7 bit addresses 0x70-0x74. I guess 0x71 is the proper address for Rx. I'll let you know when I test. This address list comes from the ir-kbd-i2c driver. The cx18 driver happens to use the same I2C adapter ID as the ivtv driver (I2C_HW_B_CX2341X) and this is what the ir-kbd-i2c driver used to decide which addresses to probe. As I don't know anything about the hardware, I had to keep the new code compatible with the old one and keep probing the same addresses. This is the i2cdetect output from my HVR-1600 - the only cx18 based card known or reported to have an IR chip: [r...@morgan ~]# i2cdetect -l i2c-0 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter i2c-1 i2c ivtv i2c driver #0 I2C adapter i2c-2 i2c cx18 i2c driver #0-0I2C adapter i2c-3 i2c cx18 i2c driver #0-1I2C adapter [r...@morgan ~]# i2cdetect 2 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-2. I will probe address range 0x03-0x77. Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- 19 -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- -- 70: 70 71 72 73 -- -- -- -- [r...@morgan ~]# i2cdetect 3 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-3. I will probe address range 0x03-0x77. Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- The Zilog is at 0x70-0x73. The standard IR Tx and RX addresses are 0x70 and 0x71 Now, if you tell me that this list doesn't make sense for cx18 boards, we can change it. I owe you the right address to probe. I think it is 0x71, but I want to double check. Well, it doesn't really matter to me at this point. All I care about is that ir-kbd-i2c didn't support cx18 adapters before, so my patch can just ignore them. Support can be added later. More interestingly, if only one board needs to be supported for now and you have all the information about the IR receiver, then we simply don't need auto-detection of IR devices on cx18 at all. We can directly take the clean route of device declaration. As far as I know the cx18 does that very well for all other chips (tuner, decoder etc.) much like the ivtv driver does, so adding support for IR should be easy. As addresses 0x70-0x74 were not probed so far on cx18 boards, I guess that IR support never worked for cx18 (at least not with ir-kbd-i2c)? No, the lirc_i2c, lirc_pvr150, and lirc_zilog come in via the i2c subsystem. Does ir-kbd-i2c support the Zilog Z8F0811 at all? If IR on the cx18 is not supported (by the ir-kbd-i2c driver) then I can simplify my patch set and omit the cx18 entirely. Which I just did... The HVR-1600 could have been supported by ir-kbd-i2c. It's submission was redirected slightly here: http://lkml.org/lkml/2009/2/3/118 And deferred here: http://www.spinics.net/lists/linux-media/msg03883.html until your changes were done. OK. Then let's indeed get my changes merged first, and then we can see the best way to add support for the HVR-1600 IR. I have an I2C related question. If the cx18 or ivtv driver autoloads ir-kbd-i2c and registers an I2C client on the bus, does that preclude lirc_i2c, lirc_pvr150 or lirc_zilog from using the device? LIRC users may notice, if it does. I don't know anything about lirc_i2c, lirc_pvr150 or lirc_zilog. I tend to ignore all the code that is neither in the Linux kernel tree nor in the v4l-dvb tree. lirc_pvr150 has always been out of kernel and likely always will be. Any valid reason? Out-of-free drivers are a pain for users :( lirc_i2c and lirc_zilog, the stripped down version of lirc_pvr150, was submitted by Janne and Jarrod: http://lkml.org/lkml/2008/9/9/19 I do not
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Hans, On Sun, 5 Apr 2009 07:46:47 +0200, Hans Verkuil wrote: Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). I'd rather name the parameter disable_ir, to make it consistent with what other bridge drivers already use, and also because what the parameter really does is preventing I2C devices from being instantiated, _not_ preventing the ir-kbd-i2c module from loading. I have a patch doing that already, it's pretty simple, I'll post it in a minute. It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. lirc_i2c will break, it still uses the legacy binding model. That's what you get for living outside the kernel tree... Upgrading it shouldn't be too hard, given that the difficult part is to update the bridge drivers and I've already taken care of this part (although lirc_i2c might need to probe more addresses than ir-kbd-i2c does). The new mechanism is the right way to do it: the adapter driver has all the information if, where and what IR is used and so should be the one to tell the kernel what to do. Attempting to autodetect and magically figure out what IR might be there is awkward and probably impossible to get right 100%. I wholeheartedly agree. Hell, it's wrong already: if you have another board that already loads ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c whether you like it or not, because ir-kbd-i2c will connect to your i2c adapter like a leech. So with the addition of a module option you at least give back control of this to the user. Totally correct. The current mess^Wmodel vaguely works when a single TV card is present, but mixing different TV cards in the same system would certainly break. Admittedly this is probably not a very common case, I guess the vast majority of users have a single TV card. When this initial conversion is done I'm pretty sure we can improve ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. So we don't need those horrible adapter ID tests and other magic that's going on in that driver. But that's phase two. Please note that my conversion _already_ no longer makes any use of adapter IDs. What it still does is probing, except for a few selected cards (AVerMedia Cardbus and MSI t...@nywhere Plus). The idea is clearly to turn probing into a fallback and use per-card data for IR device instantiation the first choice for as many cards as possible in the future. Updated patch set is available at: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ Changes since previous version: * Dropped cx18 changes on request by Andy Walls. * Added disable_ir module parameter to all bridge drivers which didn't have it. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Mike, Selected answers, as most points have already been discussed elsewhere meanwhile... On Sat, 4 Apr 2009 18:29:35 -0500 (CDT), Mike Isely wrote: On Sun, 5 Apr 2009, Jean Delvare wrote: This is excellent news. As I said in the header comment of the patch, avoiding probing when we know what the IR receiver is and at which address it sits is the way to go. Please send me all the information you have and I'll be happy to add a patch to the series, that skips probing whenever possible. Or write that patch yourself if you prefer. I have samples of most of the devices in question and can code proper I2C addresses for each of those for each resident I2C client. The pvrusb2 driver's device attribute structure already has allowance for specification of the correct I2C addresses to use for chips specific to each device (part of the v4l2-subdev rework I recently did). Right now the driver has built in defaults, and if a particular model needs something else, it can be overridden as part of the device's profile in pvrusb2-devattr.c. Good. Declaring the right IR receiver device based on board information is clearly the way to go. I didn't make any assumption, sorry. I simply copied the code from ir-kbd-i2c. If my code does the wrong thing for some devices, that was already the case before. And this will certainly be easier to fix after my changes than before. No, I think the point you are missing is that by moving that logic from ir-kbd-i2c into each driver (e.g. pvrusb2) you are moving logic that *might* be executed into a spot where it *will* be executed. Yes, you are right. Remember that the pvrusb2 driver did not autoload ir-kbd-i2c before this patch. Before this change, a user could elect not to use ir-i2c-kbd simply by not loading it. Which was pretty fragile because another bridge driver could still have loaded it. The pvrusb2 driver didn't request it, because the intent all along there is that the user makes the choice by loading the desired driver. Which simply underlines how weird the current situation is... Forcing the choice on the user is pretty bad from a usability perspective. Now with this change, the pvrusb2 driver is going to attempt to load ir-kbd-i2c where asked for or not. Not exactly, only the device will be the instantiated, the drivers won't be loaded, but the result is indeed the same: it's getting in lirc_i2c's way if that's what the user wants to use. And if not, the resulting binding will prevent lirc_i2c from later on loading. If the user had been loading lirc_i2c previously, this will cause his/her usage of IR to break. No, it's not perfect, but it worked. I'm all for improving things, but not by removing an ability that people are using. I have just added a disable_ir module parameter to work around this issue. Set it to 1 and no ir-kbd device will be instantiated, letting lirc_i2c do whatever it wants with the IR receiver device. You might argue that this is still a regression because the user now has to pass an extra parameter to get the same result as before, but OTOH lirc_i2c will need changes pretty soon anyway, its behavior will have to be changed and the users will notice. There's no way we can go from the current weird situation to a sane situation without changing the (unfortunate) user habits. (...) I really don't want to throw rocks here; it's always better to work out the solution than simply block any changes at all. I realize that something has to be done here in order to keep ir-kbd-i2c viable as a choice for users of the pvrusb2 driver. To that end, how about this strategy: 1. Just drop the part of the patch for the pvrusb2 driver and get the rest merged. Yes, I realize that this will break use of ir-kbd-i2c in cooperation with the pvrusb2 driver. As Mauro already said: not acceptable. Breaking an in-tree driver (ir-kbd-i2c) is worse than breaking an out-of-tree driver (lirc_i2c) regardless of the respective number of users or usefulness of these drivers. 2. Once ir-kbd-i2c has been updated, I will push another set of changes into the pvrusb2 driver that will make it usable there. Basically what I have in mind is similar to what you tried but I'm going to integrate it with the device profiles so that it can be appropriately loaded based on device model, with the correct I2C address in each case. And most importantly, I will add a module option to enable/disable loading or ir-kbd-i2c. This will fix my main objection, since then it will still allow lirc to be usable, for now... This sounds like a good idea. 3. I'd like to fix the abuse you mention regarding I2C_HW_B_BT848. I'm unclear on what the cleanest solution is there, but if you like to (a) point at some documentation, (b) describe what I should do, or (c) suggest a patch, I will work to deal with the problem. Ideally these adapter IDs will no longer be needed within a
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote: Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. I would guess that it won't work. There is an effort to merge lirc. It's currently stalled though. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git Jared Wilson and I were working on it (mainly last september). Since the IR on the HD PVR is also driven by the same zilog chip as on other hauppauge devices I'll take of lirc_zilog. Help converting the i2c drivers to the new i2c model is welcome. General cleanup of lirc to make it ready for mainline is of course wellcome too. Janne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Janne, On Sun, 5 Apr 2009 16:37:49 +0200, Janne Grunau wrote: On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote: Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. I would guess that it won't work. There is an effort to merge lirc. It's currently stalled though. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git I tried to clone this but it failed: git.wilsonet.com[0: 72.93.233.4]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Jared Wilson and I were working on it (mainly last september). Since the IR on the HD PVR is also driven by the same zilog chip as on other hauppauge devices I'll take of lirc_zilog. Help converting the i2c drivers to the new i2c model is welcome. General cleanup of lirc to make it ready for mainline is of course wellcome too. I will happily help you with the i2c side of things. Without an access to your git tree however, I don't know the latest state of your code. And I can't see any lirc_zilog module in the CVS repository of lirc either. But if you show me the i2c code you're worried about, I'll let you know what I think about it. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, Apr 05, 2009 at 06:37:43PM +0200, Jean Delvare wrote: Hi Janne, On Sun, 5 Apr 2009 16:37:49 +0200, Janne Grunau wrote: On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote: Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. I would guess that it won't work. There is an effort to merge lirc. It's currently stalled though. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git I tried to clone this but it failed: git.wilsonet.com[0: 72.93.233.4]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) hmm, getting that here too. I'll send Jarod a mail. You can use my clone instead: git://git.jannau.net/linux-2.6-lirc.git I will happily help you with the i2c side of things. Without an access to your git tree however, I don't know the latest state of your code. And I can't see any lirc_zilog module in the CVS repository of lirc either. But if you show me the i2c code you're worried about, I'll let you know what I think about it. lirc_zilog or lirc_pvr is not in lirc's cvs since it requires a 'firmware' for mapping keys to sequences for the ir blaster. Janne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 15:08 +0200, Jean Delvare wrote: Hi Andy, If IR on the cx18 is not supported (by the ir-kbd-i2c driver) then I can simplify my patch set and omit the cx18 entirely. Which I just did... The HVR-1600 could have been supported by ir-kbd-i2c. It's submission was redirected slightly here: http://lkml.org/lkml/2009/2/3/118 And deferred here: http://www.spinics.net/lists/linux-media/msg03883.html until your changes were done. OK. Then let's indeed get my changes merged first, and then we can see the best way to add support for the HVR-1600 IR. OK. I'll test your change anyway if I can. lirc_pvr150 has always been out of kernel and likely always will be. Any valid reason? Out-of-free drivers are a pain for users :( Well, like many of the lirc modules, it's a little kludged. The main problem is this: 1. lirc_pvr150, in the past, needed to make a direct call into the ivtv module to reset the IR chip, if it detected that the chip was hung up. That's why it tries to load the ivtv module, to make sure that symbol is in the kernel. This could cause problems, if it was a Z8 chip that was supported by some other bridge driver. I wrote a patch for lirc_pvr150 for cx18 devices for users who needed it. lirc_zilog is the cut down version of lirc_pvr150 module that was submitted in the patchset to the LKML, and no longer has the reset logic. The reset logic is not needed anymore as far as I can tell, and thus the cx18 specific patch is probably irrelevant for lirc_zilog. Other weird things include: 2. In lirc_pvr150 and lirc_zilog, both the IR Rx and IR Tx support are in one module, which is a break from the normal LIRC driver modules that keep those functions separate. This was done for the sake of detecting if the chip had hung up and to call the reset logic, AFAICT. 3. lirc_pvr150 and lirc_zilog have an IR blaster firmware image that is really an encoding of a bunch of captured sequences between the Windows driver and the Z8F0811 chip. It allows the lirc_zilog or lirc_pvr150 driver to do IR blasting by essentially performing a replay attack on the Z8F0811. Since the Zilog EULA that comes with the Hauppauge Windows IR driver for the Z8F0811 is pretty draconian, replaying captured snoops is probably the best that can be done legally to stimulate the microcontroller IR Tx code in the Z8 as delivered. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, Apr 05, 2009 at 01:39:33PM -0400, Andy Walls wrote: On Sun, 2009-04-05 at 16:37 +0200, Janne Grunau wrote: I would guess that it won't work. There is an effort to merge lirc. It's currently stalled though. Perhaps you and Jarrod and Christopher have already discussed this, but... Instead of trying to push all of the LIRC kernel components through in one big patch set, perhaps it would be easier to just get the lirc_dev and any other needed infrastructure components in first. If one focuses on satisfying the LKML comments to lirc_dev and the Makefile to get that kernel module in the kernel, then, at least for video card hosted IR devices, there is an infrastructure to which to hook new or rewritten i2c IR driver modules. I guess lkml would NAK patches adding infrastructure only bits but we will probably for the next patchset concentrate on a few lirc drivers. Christopher doesn't participate in the merge attempt. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git Jared Wilson and I were working on it (mainly last september). Since the IR on the HD PVR is also driven by the same zilog chip as on other hauppauge devices I'll take of lirc_zilog. Help converting the i2c drivers to the new i2c model is welcome. General cleanup of lirc to make it ready for mainline is of course wellcome too. I can help with this. I'm mainly concerned with lirc_dev, lirc_i2c (for Rx only use of the zilog at 0x71), lirc_zilog, and lirc_mceusb2. That's because, of course, I have devices that use those modules. :) I have devices for lirc_zilog (which should probably be merged with lirc_i2c) and lirc serial. Jarod has at least mce usb and imon devices. That are probably the devices we'll concentrate on the next submission. lirc_dev and the API header would be my first priority, if you need help. Did anyone consolidate all the comments from the LKML on Jarrod's patch submission? no and I lost track which comments were already handled. Janne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009, Hans Verkuil wrote: [...] Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). Yes, and I will do the same for pvrusb2. Simple is good. It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. It's probably going to break, and that will wake them up. There's no choice otherwise. The new mechanism is the right way to do it: the adapter driver has all the information if, where and what IR is used and so should be the one to tell the kernel what to do. Attempting to autodetect and magically figure out what IR might be there is awkward and probably impossible to get right 100%. Hell, it's wrong already: if you have another board that already loads ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c whether you like it or not, because ir-kbd-i2c will connect to your i2c adapter like a leech. So with the addition of a module option you at least give back control of this to the user. Yes, I know this is a possibility. It sucks and long term the new mechanism is the solution. I don't want anyone to think I am against the new mechanism. I'm for it. But I'd like to minimize the damage potential on the way there. When this initial conversion is done I'm pretty sure we can improve ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. So we don't need those horrible adapter ID tests and other magic that's going on in that driver. But that's phase two. My impression (at least for pvrusb2-driven devices) is that the later IR receivers require a completely different driver to work properly; one can't just bolt additional features into ir-kbd-i2c for this. In lirc's case, a different driver is in fact used. But you know this already. I haven't looked at ir-kbd-i2c in a while, but one other thing I seriously did not like about it was that the mapping of IR codes to key events was effectively hardcoded in the driver. That makes it difficult to make the same driver work with different kinds of remotes. Even if the bridge driver (e.g. pvrusb2) were to supply such a map, that's still wrong because it's within the realm of possibility that the user might actually want to use a different remote transmitter (provided it is compatible enough to work with the receiver hardware). The lirc architecture solves this easily via a conf file in userspace. In fact, lirc can map multiple mappings to a single receiver, permitting it to work concurrently with more than one remote. But is such a thing even possible with ir-kbd-i2c? I know this is one reason people tend to choose lirc. -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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote: On Sun, Apr 05, 2009 at 01:39:33PM -0400, Andy Walls wrote: If one focuses on satisfying the LKML comments to lirc_dev and the Makefile to get that kernel module in the kernel, then, at least for video card hosted IR devices, there is an infrastructure to which to hook new or rewritten i2c IR driver modules. I guess lkml would NAK patches adding infrastructure only bits but we will probably for the next patchset concentrate on a few lirc drivers. Christopher doesn't participate in the merge attempt. Oh, OK. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git Jared Wilson and I were working on it (mainly last september). Since the IR on the HD PVR is also driven by the same zilog chip as on other hauppauge devices I'll take of lirc_zilog. Help converting the i2c drivers to the new i2c model is welcome. General cleanup of lirc to make it ready for mainline is of course wellcome too. I can help with this. I'm mainly concerned with lirc_dev, lirc_i2c (for Rx only use of the zilog at 0x71), lirc_zilog, and lirc_mceusb2. That's because, of course, I have devices that use those modules. :) I have devices for lirc_zilog (which should probably be merged with lirc_i2c) Hmmm. Following Jean's reasoning, that may be the wrong way to go, if you want to avoid probing. A module to handle each specific type of I2C IR chip, splitting up lirc_i2c and leaving lirc_zilog as is, may be better in the long run. I'd personally leave lirc_zilog separate since it handles Tx and RX for one specific chip, and lirc_i2c is Rx only for a number of chips. Perhaps dropping Rx support for the Zilog Z8 in lirc_i2c and then modifying lirc_zilog to still do Rx, even if the firmware wasn't available for Tx, is a better way to go. and lirc serial. Jarod has at least mce usb and imon devices. That are probably the devices we'll concentrate on the next submission. OK. lirc_dev and the API header would be my first priority, if you need help. Did anyone consolidate all the comments from the LKML on Jarrod's patch submission? no and I lost track which comments were already handled. Hmm. Well good luck. Let me know if I can help. I have 2 cards with the Zilog and a USB unit that is supported by lirc_mceusb2. Regards, Andy Janne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 16:05 +0200, Jean Delvare wrote:
Hi Hans,
Hi Jean,
Updated patch set is available at:
http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/
--- v4l-dvb.orig/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-04-04
10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-04-04
10:58:36.0 +0200
[snip]
-
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
[snip]
I just noticed you're missing address 0x71 for ivtv. At least some
PVR-150 boards have a Zilog chip at that address.
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 13:33 -0500, Mike Isely wrote: Also, lirc makes it possible to userspace map the underlying IR codes to keybindings and associate multiple different remotes - all of that is apparently hardcoded in ir-kbd-i2c. Yes. My first remote for my PC was an HP OEM'ed and customized unit. LIRC's text configuration files made support for the remote's non-standard keys a task for 'vi' and not 'make'. Key mappings belong in configuration files - not hard coded in the kernel. Wierd or not, your change makes it hard(er) on those who legitimately wish to use lirc. Here's an interesting summary: If fact, the only pvrusb2-driven hardware from Hauppauge that is known to work with ir-kbd-i2c are the old 29xxx and 24xxx model series (not the MCE series). Those devices are out of production, AFAIK. The current devices being sold by Hauppauge don't work at all with ir-kbd-i2c and probably never will. Perhaps one can conclude that there hasn't been a lot of pressure (that I know about) to deal with updating / enhancing / replacing ir-kbd-i2c because lirc happens to be filling the niche better in many cases. Here is where LIRC may be its own worst enemy. LIRC has filled some shortcomings in the kernel for support of IR device functions for so long (LWN says LIRC is 10 years old), that large numbers of users have come to depend on its operation, while at the same time apparently removing impetus for doing much to update the in kernel IR device support. Some of the discussion on the LKML about why an input layer device is sufficient for handling most, but not all cases is interesting: http://lkml.org/lkml/2008/9/11/63 Gerd also enlightens us on why we have ir-kdb-i2c in kernel in that post. It appears that ir-kbd-i2c was written to avoid using LIRC for TV card I2C IR devices for the most common use cases. As such, it's a 90% (80%, 70% ?) solution: no blasting, no raw IR parsing for unknown protocols, only the most common remotes supported, and, of course, no support for non-I2C devices. My needs don't fit that unfortunately. I need IR blasting, an uncommon remote supported, and both USB and I2C IR device support. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote: On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote: I have devices for lirc_zilog (which should probably be merged with lirc_i2c) Hmmm. Following Jean's reasoning, that may be the wrong way to go, if you want to avoid probing. A module to handle each specific type of I2C IR chip, splitting up lirc_i2c and leaving lirc_zilog as is, may be better in the long run. This really doesn't matter. With the new binding model, probing is under control. You can do probing on some cards and not others, and you can probe some addresses and not others. And one i2c drivers can cleanly support more than one device type. What should be considered to decide whether two devices should be supported by the same driver or not, is how much their supporting code has in common. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare: On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote: On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote: I have devices for lirc_zilog (which should probably be merged with lirc_i2c) Hmmm. Following Jean's reasoning, that may be the wrong way to go, if you want to avoid probing. A module to handle each specific type of I2C IR chip, splitting up lirc_i2c and leaving lirc_zilog as is, may be better in the long run. This really doesn't matter. With the new binding model, probing is under control. You can do probing on some cards and not others, and you can probe some addresses and not others. And one i2c drivers can cleanly support more than one device type. Hmm, I'm still happy with the broken DVB-T for saa7134 on 2.6.29, tasting some Chianti vine now and need to sleep soon, but I'm also not that confident that your saa7134 MSI t...@nywhere Plus i2c remote does work addressing it directly, since previous reports always said it becomes only visible at all after other devices are probed previously. Unfortunately I can't test it, but will try to reach some with such hardware and ask for testing, likely not on the list currently. What should be considered to decide whether two devices should be supported by the same driver or not, is how much their supporting code has in common. What can not be translated to the input system I would like to know. Andy seems to have closer looked into that. To have it was a need after 2.5.x turned into 2.6.x. It was not even in sight if and when lirc would be ever usable on it again. You have it from Gerd. I also think we currently have lots of users with all sorts of TV cards. Triple cards are still quite expensive and can have only one DVB and one analog stream at once, Quad cards depend on special PCI slots and PCIe multi capable cards are not yet supported. Because of that, there are lots of mythtv and similar machines stuffed with all sort of cards in every free PCI slot I think. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
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. 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. 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. In effect there are actually two devices the ir-kbd-i2c input driver is supporting in various combinations: an IR receiver and an IR remote. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls awa...@radix.net 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.
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.
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! */
}
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Andy, Am Sonntag, den 05.04.2009, 18:00 -0400 schrieb Andy Walls: 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. 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. 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. In effect there are actually two devices the ir-kbd-i2c input driver is supporting in various combinations: an IR receiver and an IR remote. Regards, Andy you always end up with something transmitting series of 0s and 1s. It does not matter if the medium is infrared, infradead ;), wireless or whats or ever. If it spares a chip for the remote and you have to get it from IRQs triggered, you have to do that. It could also be some voltage change, a ultrasound beeper or what ever. The first place for such is the input layer and nothing out of the kernel. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls awa...@radix.net 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?!?
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009, Andy Walls wrote: Here is where LIRC may be its own worst enemy. LIRC has filled some shortcomings in the kernel for support of IR device functions for so long (LWN says LIRC is 10 years old), that large numbers of users have come to depend on its operation, while at the same time apparently removing impetus for doing much to update the in kernel IR device support. More than that. In 1997 I bought a serial port remote off ebay and tried to get it to work with linux. I found an abandoned project from the Metzler brothers called LIRC, though it didn't work. I wrote a new protocol for the serial port driver, which was the only one at the time, rewrote the remote pulse decoding code and came up a new socket based the client/server protocol and wrote the x-event client. At that point remotes were defined in header files so make was still needed to add a new one. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pvrusb2 IR changes coming [was: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model]
Jean: Here's a description of what I've got on the front burner right now: 1. The pvrusb2 driver now can unambiguously know if it is dealing with a device that is known to have ir-kbd-i2c compatible IR capabilities. 2. There is a new module option, disable_autoload_ir_kbd, which if present and set to 1 will indicate that ir-kbd should not be loaded. 2. Based upon (1) and (2), the driver will optionally attempt to load ir-kbd using the code from your patch. 3. In the pvrusb2 case, the only i2c address that currently matters is 0x18 (though I have some suspicions about another case but that can be dealt with later), so I trimmed the probe list in the register function you had added. Since calling i2c_new_probed_device() for a non-existent target driver doesn't cause any harm, then merging the above now should not result in any kind of regression. So it can go in even before the rest of your changes. That I believe also removes the objection Mauro had - this way there's no issues / dependencies. I've tested this enough to know that it at least doesn't do any further harm. I will put this up in a changeset shortly. With all that said, we should not ignore lirc and instead do whatever is reasonable to help ensure it continues to work. Though admittedly there's been plenty of opportunity to update and this whole transition has been going on for a long time. The stuff I describe above should at least keep the pvrusb2 driver out of the fray for now. -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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Let card drivers probe for IR receiver devices and instantiate them if
found. Ultimately it would be better if we could stop probing
completely, but I suspect this won't be possible for all card types.
There's certainly room for cleanups. For example, some drivers are
sharing I2C adapter IDs, so they also had to share the list of I2C
addresses being probed for an IR receiver. Now that each driver
explicitly says which addresses should be probed, maybe some addresses
can be dropped from some drivers.
Also, the special cases in saa7134-i2c should probably be handled on a
per-board basis. This would be more efficient and less risky than always
probing extra addresses on all boards. I'll give it a try later.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
Cc: Mike Isely is...@pobox.com
---
linux/drivers/media/video/bt8xx/bttv-i2c.c | 21 +
linux/drivers/media/video/cx18/cx18-i2c.c| 30 ++
linux/drivers/media/video/cx231xx/cx231xx-cards.c|5
linux/drivers/media/video/cx23885/cx23885-i2c.c | 12 +
linux/drivers/media/video/cx88/cx88-i2c.c| 13 +
linux/drivers/media/video/em28xx/em28xx-cards.c | 20 +
linux/drivers/media/video/em28xx/em28xx-i2c.c|3
linux/drivers/media/video/em28xx/em28xx-input.c |6
linux/drivers/media/video/em28xx/em28xx.h|1
linux/drivers/media/video/ir-kbd-i2c.c | 198 ++
linux/drivers/media/video/ivtv/ivtv-i2c.c| 31 ++
linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c | 24 ++
linux/drivers/media/video/saa7134/saa7134-i2c.c |3
linux/drivers/media/video/saa7134/saa7134-input.c| 86 ++-
linux/drivers/media/video/saa7134/saa7134.h |1
linux/drivers/media/video/usbvision/usbvision-i2c.c | 24 ++
linux/include/media/ir-kbd-i2c.h |2
17 files changed, 284 insertions(+), 196 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-04-04
10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-04-04
10:58:36.0 +0200
@@ -405,6 +405,27 @@ int __devinit init_bttv_i2c(struct bttv
}
if (0 == btv-i2c_rc i2c_scan)
do_i2c_scan(btv-c.v4l2_dev.name, btv-i2c_client);
+
+ /* Instantiate the IR receiver device, if present */
+ if (0 == btv-i2c_rc) {
+ struct i2c_board_info info;
+ /* The external IR receiver is at i2c address 0x34 (0x35 for
+ reads). Future Hauppauge cards will have an internal
+ receiver at 0x30 (0x31 for reads). In theory, both can be
+ fitted, and Hauppauge suggest an external overrides an
+ internal.
+
+ That's why we probe 0x1a (~0x34) first. CB
+ */
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x4b, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, ir-kbd, I2C_NAME_SIZE);
+ i2c_new_probed_device(btv-c.i2c_adap, info, addr_list);
+ }
return btv-i2c_rc;
}
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-04
10:53:15.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-04
10:58:36.0 +0200
@@ -211,7 +211,32 @@ static struct i2c_algo_bit_data cx18_i2c
.timeout= CX18_ALGO_BIT_TIMEOUT*HZ /* jiffies */
};
-/* init + register i2c algo-bit adapter */
+static void init_cx18_i2c_ir(struct cx18 *cx)
+{
+ struct i2c_board_info info;
+ /* The external IR receiver is at i2c address 0x34 (0x35 for
+ reads). Future Hauppauge cards will have an internal
+ receiver at 0x30 (0x31 for reads). In theory, both can be
+ fitted, and Hauppauge suggest an external overrides an
+ internal.
+
+ That's why we probe 0x1a (~0x34) first. CB
+ */
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, ir-kbd, I2C_NAME_SIZE);
+
+ /* The IR receiver device can be on either I2C bus */
+ if (i2c_new_probed_device(cx-i2c_adap[0], info, addr_list))
+ return;
+ i2c_new_probed_device(cx-i2c_adap[1], info, addr_list);
+}
+
+/* init + register i2c adapters + instantiate IR receiver */
int init_cx18_i2c(struct cx18 *cx)
{
int i, err;
@@ -279,6 +304,9 @@ int init_cx18_i2c(struct cx18 *cx)
err = i2c_bit_add_bus(cx-i2c_adap[1]);
if (err)
goto err_del_bus_0;
+
+ /* Instantiate the IR receiver device, if
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sat, 2009-04-04 at 14:28 +0200, Jean Delvare wrote:
Let card drivers probe for IR receiver devices and instantiate them if
found. Ultimately it would be better if we could stop probing
completely, but I suspect this won't be possible for all card types.
There's certainly room for cleanups. For example, some drivers are
sharing I2C adapter IDs, so they also had to share the list of I2C
addresses being probed for an IR receiver. Now that each driver
explicitly says which addresses should be probed, maybe some addresses
can be dropped from some drivers.
Also, the special cases in saa7134-i2c should probably be handled on a
per-board basis. This would be more efficient and less risky than always
probing extra addresses on all boards. I'll give it a try later.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
Cc: Mike Isely is...@pobox.com
---
linux/drivers/media/video/cx18/cx18-i2c.c| 30 ++
linux/drivers/media/video/ivtv/ivtv-i2c.c| 31 ++
linux/include/media/ir-kbd-i2c.h |2
17 files changed, 284 insertions(+), 196 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c2009-04-04
10:53:15.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-04
10:58:36.0 +0200
@@ -211,7 +211,32 @@ static struct i2c_algo_bit_data cx18_i2c
.timeout= CX18_ALGO_BIT_TIMEOUT*HZ /* jiffies */
};
-/* init + register i2c algo-bit adapter */
+static void init_cx18_i2c_ir(struct cx18 *cx)
+{
+ struct i2c_board_info info;
+ /* The external IR receiver is at i2c address 0x34 (0x35 for
+reads). Future Hauppauge cards will have an internal
+receiver at 0x30 (0x31 for reads). In theory, both can be
+fitted, and Hauppauge suggest an external overrides an
+internal.
+
+That's why we probe 0x1a (~0x34) first. CB
+ */
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
I think this is way out of date for cx18 based boards. The only IR chip
I know of so far is the Zilog Z8F0811 sitting at 7 bit addresses
0x70-0x74. I guess 0x71 is the proper address for Rx. I'll let you
know when I test.
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, ir-kbd, I2C_NAME_SIZE);
+
+ /* The IR receiver device can be on either I2C bus */
+ if (i2c_new_probed_device(cx-i2c_adap[0], info, addr_list))
+ return;
+ i2c_new_probed_device(cx-i2c_adap[1], info, addr_list);
+}
+
+/* init + register i2c adapters + instantiate IR receiver */
int init_cx18_i2c(struct cx18 *cx)
{
int i, err;
@@ -279,6 +304,9 @@ int init_cx18_i2c(struct cx18 *cx)
err = i2c_bit_add_bus(cx-i2c_adap[1]);
if (err)
goto err_del_bus_0;
+
+ /* Instantiate the IR receiver device, if present */
+ init_cx18_i2c_ir(cx);
return 0;
I have an I2C related question. If the cx18 or ivtv driver autoloads
ir-kbd-i2c and registers an I2C client on the bus, does that preclude
lirc_i2c, lirc_pvr150 or lirc_zilog from using the device? LIRC users
may notice, if it does.
If that is the case, then we probably shouldn't autoload the ir-kbd
module after the CX23418 i2c adapters are initialized.
I'm not sure what's the best solution:
1. A module option to the cx18 driver to tell it to call
init_cx18_i2c_ir() from cx18_probe() or not? (Easiest solution)
2. Some involved programmatic way for IR device modules to query bridge
drivers about what IR devices they may have, and on which I2C bus, and
at what addresses to probe, and whether a driver/module has already
claimed that device? (Gold plated solution)
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Nacked-by: Mike Isely is...@pobox.com
This will interfere with the alternative use of LIRC drivers (which work
in more cases that ir-kbd). It will thus break some peoples' use of the
driver. Also we have better information on what i2c addresses needed to
be probed based on the model of the device - and some devices supported
by this device are not from Hauppauge so you are making a too-strong
assumption that IR should be probed this way in all cases. Also, unless
ir-kbd has suddenly improved, this will not work at all for HVR-1950
class devices nor MCE type PVR-24xxx devices (different incompatible IR
receiver).
This is why the pvrusb2 driver has never directly attempted to load
ir-kbd.
-Mike
On Sat, 4 Apr 2009, Jean Delvare wrote:
--- v4l-dvb.orig/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-04-04 10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-04-04 10:58:36.0 +0200
@@ -649,6 +649,27 @@ static void do_i2c_scan(struct pvr2_hdw
printk(KERN_INFO %s: i2c scan done.\n, hdw-name);
}
+static void pvr2_i2c_register_ir(struct i2c_adapter *i2c_adap)
+{
+ struct i2c_board_info info;
+ /* The external IR receiver is at i2c address 0x34 (0x35 for
+reads). Future Hauppauge cards will have an internal
+receiver at 0x30 (0x31 for reads). In theory, both can be
+fitted, and Hauppauge suggest an external overrides an
+internal.
+
+That's why we probe 0x1a (~0x34) first. CB
+ */
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x4b, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, ir-kbd, I2C_NAME_SIZE);
+ i2c_new_probed_device(i2c_adap, info, addr_list);
+}
+
void pvr2_i2c_core_init(struct pvr2_hdw *hdw)
{
unsigned int idx;
@@ -696,6 +717,9 @@ void pvr2_i2c_core_init(struct pvr2_hdw
}
}
if (i2c_scan) do_i2c_scan(hdw);
+
+ /* Instantiate the IR receiver device, if present */
+ pvr2_i2c_register_ir(hdw-i2c_adap);
}
void pvr2_i2c_core_done(struct pvr2_hdw *hdw)
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sat, 4 Apr 2009, Andy Walls wrote: [...] I have an I2C related question. If the cx18 or ivtv driver autoloads ir-kbd-i2c and registers an I2C client on the bus, does that preclude lirc_i2c, lirc_pvr150 or lirc_zilog from using the device? LIRC users may notice, if it does. If that is the case, then we probably shouldn't autoload the ir-kbd module after the CX23418 i2c adapters are initialized. I'm not sure what's the best solution: 1. A module option to the cx18 driver to tell it to call init_cx18_i2c_ir() from cx18_probe() or not? (Easiest solution) 2. Some involved programmatic way for IR device modules to query bridge drivers about what IR devices they may have, and on which I2C bus, and at what addresses to probe, and whether a driver/module has already claimed that device? (Gold plated solution) Regards, Andy Ah, glad to see I'm not the only one concerned about this. I suppose I could instead add a module option to the pvrusb2 driver to control autoloading of ir-kbd (option 1). It also should probably be a per-device attribute, since AFAIK, ir-kbd only even works when using older Hauppauge IR receivers (i.e. lirc_i2c - cases that would otherwise use lirc_pvr150 or lirc_zilog I believe do not work with ir-kbd). Some devices handled by the pvrusb2 driver are not from Hauppauge. Too bad if this is the case, it was easier to let the user decide just by choosing which actual module to load. -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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sat, 2009-04-04 at 11:05 -0500, Mike Isely wrote:
On Sat, 4 Apr 2009, Andy Walls wrote:
[...]
I have an I2C related question. If the cx18 or ivtv driver autoloads
ir-kbd-i2c and registers an I2C client on the bus, does that preclude
lirc_i2c, lirc_pvr150 or lirc_zilog from using the device? LIRC users
may notice, if it does.
If that is the case, then we probably shouldn't autoload the ir-kbd
module after the CX23418 i2c adapters are initialized.
I'm not sure what's the best solution:
1. A module option to the cx18 driver to tell it to call
init_cx18_i2c_ir() from cx18_probe() or not? (Easiest solution)
2. Some involved programmatic way for IR device modules to query bridge
drivers about what IR devices they may have, and on which I2C bus, and
at what addresses to probe, and whether a driver/module has already
claimed that device? (Gold plated solution)
I was thinking about this while mowing the lawn today
The objectives seem to be:
1. Avoid auto probing
2. Leverage the bridge driver's knowledge of what should be available
3. Allow the user to dictate which kernel IR driver module be used with
the subordinate device.
So my rough outline of an idea (which probably runs slightly afoul of
Hans' media_controller device, but we don't have it yet):
1. Add a function to the v4l2 framework to iterate over all the
v4l2_device's that are registered (if there isn't one already).
2. Add a method to the v4l2_device class to return the IR subdevice for
a given v4l2_device:
v4l2_subdev *v4l2_device_get_ir_subdev(v4l2_device *dev);
and if it returns NULL, that device has no IR chip.
3. To the v4l2_subdev framework add:
struct v4l2_subdev_ir_ops {
(*enumerate) (v4l2_subdev *sd, /* bus_type, bus #, addr for Rx,
addr for Tx */);
(*claim) (v4l2_subdev *sd, /* claiming driver name string,
going-away callback function pointer */);
(*release) (v4l2_subdev *sd, /* handle */);
bool (*is_claimed) (v4l2_subdev *sd, /* output string of the
owner */);
/* Or maybe just */
(*send) (v4l2_subdev *sd, /* data buffer */);
(*receive) (v4l2_subdev *sd, /* data buffer */);
}
and have the bridge driver support these. (I also had some in mind for
the IR micro-controller debug/programming port, but the above will fit
the task at hand I think.)
OK so that's all a bit rough around the edges. The idea is a uniform
call in for ir-kdb-i2c or lirc_foo or ir_foo to get at an IR chip behind
a bridge device, that the bridge device driver itself cares about very
little. *Except* ir driver modules would be coordinated by the bridge
driver in what they can and cannot do to get at the IR device. This
coordination prevents bad things on the bridge chip's I2C bus(es) or
from having modules racing to get the IR device. That way whatever
module the user loads will get first shot at claiming the IR chip. This
also provides a discovery mechanism four use by ir driver modules that
is informed by the bridge chip driver. I think lirc_foo can also still
use it's current way of doing business too.
It really just looks like a small subset of what Hans intended for the
media controller, so maybe this would be a good chance to get some
lessons learned.
Regards,
Andy
Regards,
Andy
Ah, glad to see I'm not the only one concerned about this.
I suppose I could instead add a module option to the pvrusb2 driver to
control autoloading of ir-kbd (option 1). It also should probably be a
per-device attribute, since AFAIK, ir-kbd only even works when using
older Hauppauge IR receivers (i.e. lirc_i2c - cases that would otherwise
use lirc_pvr150 or lirc_zilog I believe do not work with ir-kbd). Some
devices handled by the pvrusb2 driver are not from Hauppauge. Too bad
if this is the case, it was easier to let the user decide just by
choosing which actual module to load.
I think we can get there and still have the random probing reduced.
Regards,
Andy
-Mike
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 00:51 +0200, Jean Delvare wrote:
Hi Andy,
On Sat, 04 Apr 2009 09:42:09 -0400, Andy Walls wrote:
On Sat, 2009-04-04 at 14:28 +0200, Jean Delvare wrote:
Let card drivers probe for IR receiver devices and instantiate them if
found. Ultimately it would be better if we could stop probing
completely, but I suspect this won't be possible for all card types.
There's certainly room for cleanups. For example, some drivers are
sharing I2C adapter IDs, so they also had to share the list of I2C
addresses being probed for an IR receiver. Now that each driver
explicitly says which addresses should be probed, maybe some addresses
can be dropped from some drivers.
Also, the special cases in saa7134-i2c should probably be handled on a
per-board basis. This would be more efficient and less risky than always
probing extra addresses on all boards. I'll give it a try later.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
Cc: Mike Isely is...@pobox.com
---
linux/drivers/media/video/cx18/cx18-i2c.c| 30 ++
linux/drivers/media/video/ivtv/ivtv-i2c.c| 31 ++
linux/include/media/ir-kbd-i2c.h |2
17 files changed, 284 insertions(+), 196 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c
2009-04-04 10:53:15.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-04
10:58:36.0 +0200
@@ -211,7 +211,32 @@ static struct i2c_algo_bit_data cx18_i2c
.timeout= CX18_ALGO_BIT_TIMEOUT*HZ /* jiffies */
};
-/* init + register i2c algo-bit adapter */
+static void init_cx18_i2c_ir(struct cx18 *cx)
+{
+ struct i2c_board_info info;
+ /* The external IR receiver is at i2c address 0x34 (0x35 for
+reads). Future Hauppauge cards will have an internal
+receiver at 0x30 (0x31 for reads). In theory, both can be
+fitted, and Hauppauge suggest an external overrides an
+internal.
+
+That's why we probe 0x1a (~0x34) first. CB
+ */
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
I think this is way out of date for cx18 based boards. The only IR chip
I know of so far is the Zilog Z8F0811 sitting at 7 bit addresses
0x70-0x74. I guess 0x71 is the proper address for Rx. I'll let you
know when I test.
This address list comes from the ir-kbd-i2c driver. The cx18 driver
happens to use the same I2C adapter ID as the ivtv driver
(I2C_HW_B_CX2341X) and this is what the ir-kbd-i2c driver used to
decide which addresses to probe. As I don't know anything about the
hardware, I had to keep the new code compatible with the old one and
keep probing the same addresses.
This is the i2cdetect output from my HVR-1600 - the only cx18 based card
known or reported to have an IR chip:
[r...@morgan ~]# i2cdetect -l
i2c-0 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter
i2c-1 i2c ivtv i2c driver #0 I2C adapter
i2c-2 i2c cx18 i2c driver #0-0I2C adapter
i2c-3 i2c cx18 i2c driver #0-1I2C adapter
[r...@morgan ~]# i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- 19 -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- --
70: 70 71 72 73 -- -- -- --
[r...@morgan ~]# i2cdetect 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
The Zilog is at 0x70-0x73. The standard IR Tx and RX addresses are 0x70
and 0x71
Now, if you tell me that this list doesn't make sense for cx18 boards,
we can change it.
I owe you the right address to probe. I think it is 0x71, but I want to
