BUG: bttv does not load module ir-kbd-i2c for Hauppauge model 37284, rev B421
While we are at it ;) :
[ 15.280772] bttv: Bt8xx card found (0) [ 15.281349] bttv: 0: Bt878 (rev 17) at 0000:01:08.0, irq: 18, latency: 32, mmio: 0xfdfff000 [ 15.281386] bttv: 0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb [ 15.281391] bttv: 0: using: Hauppauge (bt878) [card=10,insmod option] [ 15.283964] bttv: 0: Hauppauge/Voodoo msp34xx: reset line init [5] [ 15.316043] tveeprom 4-0050: Hauppauge model 37284, rev B421, serial# 5111944 [ 15.316049] tveeprom 4-0050: tuner model is Philips FM1216 (idx 21, type 5) [ 15.316054] tveeprom 4-0050: TV standards PAL(B/G) (eeprom 0x04) [ 15.316059] tveeprom 4-0050: audio processor is MSP3410D (idx 5) [ 15.316063] tveeprom 4-0050: has radio [ 15.316066] bttv: 0: Hauppauge eeprom indicates model#37284 [ 15.316071] bttv: 0: tuner type=5 [ 16.178816] bttv: 0: registered device video0 [ 16.179071] bttv: 0: registered device vbi0 [ 16.180587] bttv: 0: registered device radio0
When I load module ir-kbd-i2c manually:
Registered IR keymap rc-hauppauge
input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input6
rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0
ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-4/4-0018/ir0 [bt878 #0 [sw]]
Remote control works fine then.
Regards,
rank
Em Sat, 05 Jan 2013 15:00:18 +0100
Frank Schäfer <[email protected]> escreveu:
Quoted 22 lines
While we are at it ;) :
[ 15.280772] bttv: Bt8xx card found (0) [ 15.281349] bttv: 0: Bt878 (rev 17) at 0000:01:08.0, irq: 18, latency: 32, mmio: 0xfdfff000 [ 15.281386] bttv: 0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb [ 15.281391] bttv: 0: using: Hauppauge (bt878) [card=10,insmod option] [ 15.283964] bttv: 0: Hauppauge/Voodoo msp34xx: reset line init [5] [ 15.316043] tveeprom 4-0050: Hauppauge model 37284, rev B421, serial# 5111944 [ 15.316049] tveeprom 4-0050: tuner model is Philips FM1216 (idx 21, type 5) [ 15.316054] tveeprom 4-0050: TV standards PAL(B/G) (eeprom 0x04) [ 15.316059] tveeprom 4-0050: audio processor is MSP3410D (idx 5) [ 15.316063] tveeprom 4-0050: has radio [ 15.316066] bttv: 0: Hauppauge eeprom indicates model#37284 [ 15.316071] bttv: 0: tuner type=5 [ 16.178816] bttv: 0: registered device video0 [ 16.179071] bttv: 0: registered device vbi0 [ 16.180587] bttv: 0: registered device radio0
Quoted 8 lines
When I load module ir-kbd-i2c manually:
Registered IR keymap rc-hauppauge
input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input6
rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0
ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-4/4-0018/ir0 [bt878 #0 [sw]]Remote control works fine then.
Yeah, this is a known misfeature of bttv, and very likely documented on several wiki pages like those:
http://linuxtv.org/wiki/index.php/Remote_controllers-V4L
(btw, this wiki page is very likely outdated)
http://www.mythtv.org/wiki/Ir-kbd-i2c http://www.linuxtv.org/wiki/index.php/Prolink_Pixelview_PlayTV_Pro
I can't remember if this were always this way, or if this was caused by the I2C core redesign (2006?). I think it was always like that, and, as I2C comes with a cost (polling can affect video processing with old machines), so, we decided to not do the auto-load on the older drivers that weren't doing it already.
Btw, the fact that there's no clear indication about what bttv boards require I2C made hard to remove the get_key codes from ir-kbd-i2c.
It probably makes sense to add a "has_ir_i2c" field at bttv, add a flag there at modprobe to prevent the autoload, and start tagging the boards with I2C IR with such tag.
If you care enough, feel free to send us such patch.
Cheers,
Mauro
Am 05.01.2013 16:57, schrieb Mauro Carvalho Chehab:
Quoted 37 lines
Em Sat, 05 Jan 2013 15:00:18 +0100
Frank Schäfer <[email protected]> escreveu:Quoted 22 lines
While we are at it ;) :
[ 15.280772] bttv: Bt8xx card found (0) [ 15.281349] bttv: 0: Bt878 (rev 17) at 0000:01:08.0, irq: 18, latency: 32, mmio: 0xfdfff000 [ 15.281386] bttv: 0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb [ 15.281391] bttv: 0: using: Hauppauge (bt878) [card=10,insmod option] [ 15.283964] bttv: 0: Hauppauge/Voodoo msp34xx: reset line init [5] [ 15.316043] tveeprom 4-0050: Hauppauge model 37284, rev B421, serial# 5111944 [ 15.316049] tveeprom 4-0050: tuner model is Philips FM1216 (idx 21, type 5) [ 15.316054] tveeprom 4-0050: TV standards PAL(B/G) (eeprom 0x04) [ 15.316059] tveeprom 4-0050: audio processor is MSP3410D (idx 5) [ 15.316063] tveeprom 4-0050: has radio [ 15.316066] bttv: 0: Hauppauge eeprom indicates model#37284 [ 15.316071] bttv: 0: tuner type=5 [ 16.178816] bttv: 0: registered device video0 [ 16.179071] bttv: 0: registered device vbi0 [ 16.180587] bttv: 0: registered device radio0Quoted 8 lines
When I load module ir-kbd-i2c manually:
Registered IR keymap rc-hauppauge
input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input6
rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0
ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-4/4-0018/ir0 [bt878 #0 [sw]]Remote control works fine then.
Yeah, this is a known misfeature of bttv, and very likely documented on several wiki pages like those:
http://linuxtv.org/wiki/index.php/Remote_controllers-V4L
(btw, this wiki page is very likely outdated)
Quoted 8 lines
http://www.mythtv.org/wiki/Ir-kbd-i2c http://www.linuxtv.org/wiki/index.php/Prolink_Pixelview_PlayTV_ProI can't remember if this were always this way, or if this was caused by the I2C core redesign (2006?). I think it was always like that, and, as I2C comes with a cost (polling can affect video processing with old machines), so, we decided to not do the auto-load on the older drivers that weren't doing it already.
I'm not sure I understand you. Is it a misfeature or intentional ? Does polling 3 bytes every 100ms really affect the performance of video processing in a perceptable manner ?
Quoted 2 lines
Btw, the fact that there's no clear indication about what bttv boards require I2C made hard to remove the
get_keycodes from ir-kbd-i2c.
See my previous post, I thought the intention is to do the opposite.
Quoted 3 lines
It probably makes sense to add a "
has_ir_i2c" field at bttv, add a flag there at modprobe to prevent the autoload, and start tagging the boards with I2C IR with such tag.
Without having looked into the code, it seems that the driver detects the i2c rc already without a board flag.
Otherwise it wouldn't register the i2c device. Unfortunately, it doesn't display a message.
Quoted 1 line
If you care enough, feel free to send us such patch.
I care enough, but it has a low priority for me at the moment.
Regards,
Frank
Quoted 2 lines
Cheers,
Mauro
Em Sun, 06 Jan 2013 21:36:45 +0100
Frank Schäfer <[email protected]> escreveu:
Quoted 41 lines
Am 05.01.2013 16:57, schrieb Mauro Carvalho Chehab:
Quoted 40 lines
Em Sat, 05 Jan 2013 15:00:18 +0100
Frank Schäfer <[email protected]> escreveu:Quoted 22 lines
While we are at it ;) :
[ 15.280772] bttv: Bt8xx card found (0) [ 15.281349] bttv: 0: Bt878 (rev 17) at 0000:01:08.0, irq: 18, latency: 32, mmio: 0xfdfff000 [ 15.281386] bttv: 0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb [ 15.281391] bttv: 0: using: Hauppauge (bt878) [card=10,insmod option] [ 15.283964] bttv: 0: Hauppauge/Voodoo msp34xx: reset line init [5] [ 15.316043] tveeprom 4-0050: Hauppauge model 37284, rev B421, serial# 5111944 [ 15.316049] tveeprom 4-0050: tuner model is Philips FM1216 (idx 21, type 5) [ 15.316054] tveeprom 4-0050: TV standards PAL(B/G) (eeprom 0x04) [ 15.316059] tveeprom 4-0050: audio processor is MSP3410D (idx 5) [ 15.316063] tveeprom 4-0050: has radio [ 15.316066] bttv: 0: Hauppauge eeprom indicates model#37284 [ 15.316071] bttv: 0: tuner type=5 [ 16.178816] bttv: 0: registered device video0 [ 16.179071] bttv: 0: registered device vbi0 [ 16.180587] bttv: 0: registered device radio0Quoted 8 lines
When I load module ir-kbd-i2c manually:
Registered IR keymap rc-hauppauge
input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input6
rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0
ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-4/4-0018/ir0 [bt878 #0 [sw]]Remote control works fine then.
Yeah, this is a known misfeature of bttv, and very likely documented on several wiki pages like those:
http://linuxtv.org/wiki/index.php/Remote_controllers-V4L
(btw, this wiki page is very likely outdated)http://www.mythtv.org/wiki/Ir-kbd-i2c http://www.linuxtv.org/wiki/index.php/Prolink_Pixelview_PlayTV_Pro
Quoted 7 lines
Quoted 5 lines
I can't remember if this were always this way, or if this was caused by the I2C core redesign (2006?). I think it was always like that, and, as I2C comes with a cost (polling can affect video processing with old machines), so, we decided to not do the auto-load on the older drivers that weren't doing it already.
I'm not sure I understand you. Is it a misfeature or intentional ?
I think it was intentional, but I can't remember for sure. If it wasn't intentional, its behavior changed when the I2C 'application type' flags got removed (~5-6 years ago).
Quoted 2 lines
Does polling 3 bytes every 100ms really affect the performance of video processing in a perceptable manner ?
On that time, yes. The big kernel lock were removed only on recent versions. Also, CPUs/GPUs weren't that fast 7 years ago.
Quoted 4 lines
Quoted 2 lines
Btw, the fact that there's no clear indication about what bttv boards require I2C made hard to remove the
get_keycodes from ir-kbd-i2c.See my previous post, I thought the intention is to do the opposite.
No. We tried hard to identify what board were using what get_key code, and moved the drivers specifics code to the driver.
Quoted 8 lines
Quoted 3 lines
It probably makes sense to add a "
has_ir_i2c" field at bttv, add a flag there at modprobe to prevent the autoload, and start tagging the boards with I2C IR with such tag.Without having looked into the code, it seems that the driver detects the i2c rc already without a board flag.
Otherwise it wouldn't register the i2c device. Unfortunately, it doesn't display a message.
No. In the past (kernel 2.4 and upper), I2C bus used to work with 0-len reads to scan the used I2C addresses. The I2C drivers like tuners, demods, IR's etc used to register to the I2C core saying that they were to be used on TV boards. The I2C logic binds them to the I2C bus driver when they were detected, during the scanning process.
That's why it is so hard to know what boards are using I2C remotes, on those older drivers.
We spent a lot of time seeking at the git logs to identify, before being able to move the code away from ir-i2c-kbd.
Quoted 10 lines
Quoted 1 line
If you care enough, feel free to send us such patch.
I care enough, but it has a low priority for me at the moment.
Regards,
FrankQuoted 2 lines
Cheers,
Mauro
Signature · 2 lines
Cheers, Mauro
<snip>
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
It probably makes sense to add a "
has_ir_i2c" field at bttv, add a flag there at modprobe to prevent the autoload, and start tagging the boards with I2C IR with such tag.Without having looked into the code, it seems that the driver detects the i2c rc already without a board flag.
Otherwise it wouldn't register the i2c device. Unfortunately, it doesn't display a message.
Quoted 8 lines
No. In the past (kernel 2.4 and upper), I2C bus used to work with 0-len reads to scan the used I2C addresses. The I2C drivers like tuners, demods, IR's etc used to register to the I2C core saying that they were to be used on TV boards. The I2C logic binds them to the I2C bus driver when they were detected, during the scanning process.
That's why it is so hard to know what boards are using I2C remotes, on those older drivers.
Hmmm... so the I2C subystem probes a list of addresses and just registers all devices it finds, but the driver itself doesn't know if one of them is a RC device ?
Sounds odd. Will have to check the code to understand what's going on...
Regards,
Frank