em28xx: msi Digivox ATSC board id [0db0:8810]

em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

Hi,

I recently acquired a msi Digivox ATSC tuner. I believe this card has an 
em28xx chip (the windows driver included is em28xx). Looking at the 
em28xx wiki page and digging around in the code it does not seem like 
the em28xx driver has support for this card. Based on my limit 
(extremely) amount of knowledge, it doesn't look like it would be 
terribly difficult to add support for this card.

I am a complete hardware newbie (looking and willing to learn) and I 
hoping someone will be willing to help me out.

Following the bus snooping guide I was able to snoop the usb tuner 
(using usbsnoop 2.0) and collect some data from this card (Windows XP, 
using the ArcSoft TotalMedia software the card shipped with).

$ php parse-usbsnoop.php UsbSnoop.log > parsed-usbsnoop.txt
http://pyther.net/a/digivox_atsc/parsed-usbsnoop.txt

$ perl contrib_em28xx_parse_em28xx.pl parsed-usbsnoop.txt > parse_em28xx.txt
http://pyther.net/a/digivox_atsc/parse_em28xx.txt

$ lsusb -vvv (snippet)
http://pyther.net/a/digivox_atsc/lsusb.txt

Note: If necessary I can provide the entire UsbSnoop.log (however its 
~350MB)

At this point I'm not really sure how to use the above information to 
add support for my tuner. For starters I have non-existent C skills. 
 From what I've looked at, I figure I have to add the vendor id and 
product id and it looks like I need to create a struct defining the 
input devices on the tuner (just astc/dvb on this card). It also looks 
like I need to find out the reset codes?

Any help would be greatly appreciated.

Model: msi Digivox ATSC
Vendor / Product Id: [0db0:8810]
URL: http://www.msi.com/product/mm/DIGIVOX-ATSC.html

Thanks

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Hi Matthew,

thank you for reporting this device and your investigations !

Am 28.11.2012 03:31, schrieb Matthew Gyurgyik:
> Hi,
>
> I recently acquired a msi Digivox ATSC tuner. I believe this card has
> an em28xx chip (the windows driver included is em28xx). Looking at the
> em28xx wiki page and digging around in the code it does not seem like
> the em28xx driver has support for this card. Based on my limit
> (extremely) amount of knowledge, it doesn't look like it would be
> terribly difficult to add support for this card.
>
> I am a complete hardware newbie (looking and willing to learn) and I
> hoping someone will be willing to help me out.
>
> Following the bus snooping guide I was able to snoop the usb tuner
> (using usbsnoop 2.0) and collect some data from this card (Windows XP,
> using the ArcSoft TotalMedia software the card shipped with).
>
> $ php parse-usbsnoop.php UsbSnoop.log > parsed-usbsnoop.txt
> http://pyther.net/a/digivox_atsc/parsed-usbsnoop.txt
>
> $ perl contrib_em28xx_parse_em28xx.pl parsed-usbsnoop.txt >
> parse_em28xx.txt
> http://pyther.net/a/digivox_atsc/parse_em28xx.txt
>
> $ lsusb -vvv (snippet)
> http://pyther.net/a/digivox_atsc/lsusb.txt
>
> Note: If necessary I can provide the entire UsbSnoop.log (however its
> ~350MB)
>
> At this point I'm not really sure how to use the above information to
> add support for my tuner. For starters I have non-existent C skills.
> From what I've looked at, I figure I have to add the vendor id and
> product id and it looks like I need to create a struct defining the
> input devices on the tuner (just astc/dvb on this card). It also looks
> like I need to find out the reset codes?

Your device seems to use a EM2874 bridge.
Any chance to open the device and find out which demodulator it uses ?
Are you able to compile a kernel on your own to test patches ? It's not
that hard... ;)

Regards,
Frank


>
> Any help would be greatly appreciated.
>
> Model: msi Digivox ATSC
> Vendor / Product Id: [0db0:8810]
> URL: http://www.msi.com/product/mm/DIGIVOX-ATSC.html
>
> Thanks
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 11/28/2012 03:47 PM, Frank Schäfer wrote:
> Your device seems to use a EM2874 bridge.
That is what appears on the chip.
> Any chance to open the device and find out which demodulator it uses ?
To my surprise it was easier to open than expected.

I think this is the demodulator:

7th Generation
VS8/QAM Receiver
LG
LGDT3305
1211
PGU419.00A

I took some pictures (of the entire card): 
http://pyther.net/a/digivox_atsc/ (SideA_1.jpg, SideA_2.jpg, 
SideB_1.jpg, SideB_2.jpg)
> Are you able to compile a kernel on your own to test patches ? It's not
> that hard... ;)
I sure can! I've done some kernel bisects in the past.

Thanks

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 11/29/2012 12:29 AM, Matthew Gyurgyik wrote:
> On 11/28/2012 03:47 PM, Frank Schäfer wrote:
>> Your device seems to use a EM2874 bridge.
> That is what appears on the chip.
>> Any chance to open the device and find out which demodulator it uses ?
> To my surprise it was easier to open than expected.
>
> I think this is the demodulator:
>
> 7th Generation
> VS8/QAM Receiver
> LG
> LGDT3305
> 1211
> PGU419.00A
>
> I took some pictures (of the entire card):
> http://pyther.net/a/digivox_atsc/ (SideA_1.jpg, SideA_2.jpg,
> SideB_1.jpg, SideB_2.jpg)
>> Are you able to compile a kernel on your own to test patches ? It's not
>> that hard... ;)
> I sure can! I've done some kernel bisects in the past.

Very, very, good pics and sniffs!!


 From the sniff you could see I2C addresses
50 (a0 >> 1) eeprom
0e (1c >> 1) demod
60 (c0 >> 1) tuner


EM2874, USB-bridge, clocked at 12MHz, crystal on other side of PCB. 
There is also 32k serial eeprom for EM2874. This large serial eeprom 
means (very likely) it uses custom firmware which is downloaded from the 
eeprom.

LGDT3305, demodulator, clocked at 25MHz. Serial TS used between EM2874 
and LGDT3305.

TDA18271HDC2 is tuner, clocked at 16MHz. Traditional IF used between 
tuner and demod.

IR receiver is near antenna, which is a little bit long wires to connect 
to the EM2874, looks weird but no harm.


Main GPIO sequence is that one:
000255: 000006 ms 000990 ms c0 00 00 00 80 00 01 00 <<<  ff
000256: 000004 ms 000994 ms 40 00 00 00 80 00 01 00 >>>  fe
000257: 000006 ms 001000 ms c0 00 00 00 80 00 01 00 <<<  fe
000258: 000004 ms 001004 ms 40 00 00 00 80 00 01 00 >>>  be
000259: 000139 ms 001143 ms c0 00 00 00 80 00 01 00 <<<  be
000260: 000005 ms 001148 ms 40 00 00 00 80 00 01 00 >>>  fe

There is some more GPIOs later, just test with trial and error to find 
out all GPIOs.

Making that device working should be quite easy! There is a little 
change for proprietary firmware for EM2874 which does some nasty things, 
but that is very very unlikely.

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 11/28/2012 05:55 PM, Antti Palosaari wrote:
>
> Very, very, good pics and sniffs!!
>
>
> From the sniff you could see I2C addresses
> 50 (a0 >> 1) eeprom
> 0e (1c >> 1) demod
> 60 (c0 >> 1) tuner
>
>
> EM2874, USB-bridge, clocked at 12MHz, crystal on other side of PCB. 
> There is also 32k serial eeprom for EM2874. This large serial eeprom 
> means (very likely) it uses custom firmware which is downloaded from 
> the eeprom.
>
> LGDT3305, demodulator, clocked at 25MHz. Serial TS used between EM2874 
> and LGDT3305.
>
> TDA18271HDC2 is tuner, clocked at 16MHz. Traditional IF used between 
> tuner and demod.
>
> IR receiver is near antenna, which is a little bit long wires to 
> connect to the EM2874, looks weird but no harm.
>
>
> Main GPIO sequence is that one:
> 000255: 000006 ms 000990 ms c0 00 00 00 80 00 01 00 <<< ff
> 000256: 000004 ms 000994 ms 40 00 00 00 80 00 01 00 >>> fe
> 000257: 000006 ms 001000 ms c0 00 00 00 80 00 01 00 <<< fe
> 000258: 000004 ms 001004 ms 40 00 00 00 80 00 01 00 >>> be
> 000259: 000139 ms 001143 ms c0 00 00 00 80 00 01 00 <<< be
> 000260: 000005 ms 001148 ms 40 00 00 00 80 00 01 00 >>> fe
>
> There is some more GPIOs later, just test with trial and error to find 
> out all GPIOs.
>
> Making that device working should be quite easy! There is a little 
> change for proprietary firmware for EM2874 which does some nasty 
> things, but that is very very unlikely.
>
> regards
> Antti

Thanks for the information. That is way over my head. Is there same 
basic reading someone could recommend so I can start to understand the 
basics of all this?

In the mean time, I'm willing to do any testing necessary.

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 11/29/2012 04:05 AM, Matthew Gyurgyik wrote:
> On 11/28/2012 05:55 PM, Antti Palosaari wrote:
>>
>> Very, very, good pics and sniffs!!
>>
>>
>> From the sniff you could see I2C addresses
>> 50 (a0 >> 1) eeprom
>> 0e (1c >> 1) demod
>> 60 (c0 >> 1) tuner
>>
>>
>> EM2874, USB-bridge, clocked at 12MHz, crystal on other side of PCB.
>> There is also 32k serial eeprom for EM2874. This large serial eeprom
>> means (very likely) it uses custom firmware which is downloaded from
>> the eeprom.
>>
>> LGDT3305, demodulator, clocked at 25MHz. Serial TS used between EM2874
>> and LGDT3305.
>>
>> TDA18271HDC2 is tuner, clocked at 16MHz. Traditional IF used between
>> tuner and demod.
>>
>> IR receiver is near antenna, which is a little bit long wires to
>> connect to the EM2874, looks weird but no harm.
>>
>>
>> Main GPIO sequence is that one:
>> 000255: 000006 ms 000990 ms c0 00 00 00 80 00 01 00 <<< ff
>> 000256: 000004 ms 000994 ms 40 00 00 00 80 00 01 00 >>> fe
>> 000257: 000006 ms 001000 ms c0 00 00 00 80 00 01 00 <<< fe
>> 000258: 000004 ms 001004 ms 40 00 00 00 80 00 01 00 >>> be
>> 000259: 000139 ms 001143 ms c0 00 00 00 80 00 01 00 <<< be
>> 000260: 000005 ms 001148 ms 40 00 00 00 80 00 01 00 >>> fe
>>
>> There is some more GPIOs later, just test with trial and error to find
>> out all GPIOs.
>>
>> Making that device working should be quite easy! There is a little
>> change for proprietary firmware for EM2874 which does some nasty
>> things, but that is very very unlikely.
>>
>> regards
>> Antti
>
> Thanks for the information. That is way over my head. Is there same
> basic reading someone could recommend so I can start to understand the
> basics of all this?
>
> In the mean time, I'm willing to do any testing necessary.
>

Maybe I could give hour or two for that if you could make tests I ask?

If someone else would like to hack with it, I am very happy too. Frank?

regards
Antti


-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 29.11.2012 03:15, schrieb Antti Palosaari:
> On 11/29/2012 04:05 AM, Matthew Gyurgyik wrote:
>> On 11/28/2012 05:55 PM, Antti Palosaari wrote:
>>>
>>> Very, very, good pics and sniffs!!
>>>
>>>
>>> From the sniff you could see I2C addresses
>>> 50 (a0 >> 1) eeprom
>>> 0e (1c >> 1) demod
>>> 60 (c0 >> 1) tuner
>>>
>>>
>>> EM2874, USB-bridge, clocked at 12MHz, crystal on other side of PCB.
>>> There is also 32k serial eeprom for EM2874. This large serial eeprom
>>> means (very likely) it uses custom firmware which is downloaded from
>>> the eeprom.
>>>
>>> LGDT3305, demodulator, clocked at 25MHz. Serial TS used between EM2874
>>> and LGDT3305.
>>>
>>> TDA18271HDC2 is tuner, clocked at 16MHz. Traditional IF used between
>>> tuner and demod.
>>>
>>> IR receiver is near antenna, which is a little bit long wires to
>>> connect to the EM2874, looks weird but no harm.
>>>
>>>
>>> Main GPIO sequence is that one:
>>> 000255: 000006 ms 000990 ms c0 00 00 00 80 00 01 00 <<< ff
>>> 000256: 000004 ms 000994 ms 40 00 00 00 80 00 01 00 >>> fe
>>> 000257: 000006 ms 001000 ms c0 00 00 00 80 00 01 00 <<< fe
>>> 000258: 000004 ms 001004 ms 40 00 00 00 80 00 01 00 >>> be
>>> 000259: 000139 ms 001143 ms c0 00 00 00 80 00 01 00 <<< be
>>> 000260: 000005 ms 001148 ms 40 00 00 00 80 00 01 00 >>> fe
>>>
>>> There is some more GPIOs later, just test with trial and error to find
>>> out all GPIOs.
>>>
>>> Making that device working should be quite easy! There is a little
>>> change for proprietary firmware for EM2874 which does some nasty
>>> things, but that is very very unlikely.

Do we know any devices with a "real" proprietary firmware ??
I'm not talking about custom USB ID, endpoint configuration and minor
stuff like this...

>>>
>>> regards
>>> Antti
>>
>> Thanks for the information. That is way over my head. Is there same
>> basic reading someone could recommend so I can start to understand the
>> basics of all this?
>>
>> In the mean time, I'm willing to do any testing necessary.
>>
>
> Maybe I could give hour or two for that if you could make tests I ask?
>
> If someone else would like to hack with it, I am very happy too. Frank?
>

Seems like we have all we need, right ? A TDA18271 driver seems to be in
place, what about the LGDT3305 demodulator ?
I can try to put the puzzle together, but not before weekend.
Matthew, stay tuned but be patient. ;)

Regards,
Frank


> regards
> Antti
>

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 11/29/2012 09:28 PM, Frank Schäfer wrote:
> Am 29.11.2012 03:15, schrieb Antti Palosaari:
>> On 11/29/2012 04:05 AM, Matthew Gyurgyik wrote:
>>> On 11/28/2012 05:55 PM, Antti Palosaari wrote:
>>>>
>>>> Very, very, good pics and sniffs!!
>>>>
>>>>
>>>>  From the sniff you could see I2C addresses
>>>> 50 (a0 >> 1) eeprom
>>>> 0e (1c >> 1) demod
>>>> 60 (c0 >> 1) tuner
>>>>
>>>>
>>>> EM2874, USB-bridge, clocked at 12MHz, crystal on other side of PCB.
>>>> There is also 32k serial eeprom for EM2874. This large serial eeprom
>>>> means (very likely) it uses custom firmware which is downloaded from
>>>> the eeprom.
>>>>
>>>> LGDT3305, demodulator, clocked at 25MHz. Serial TS used between EM2874
>>>> and LGDT3305.
>>>>
>>>> TDA18271HDC2 is tuner, clocked at 16MHz. Traditional IF used between
>>>> tuner and demod.
>>>>
>>>> IR receiver is near antenna, which is a little bit long wires to
>>>> connect to the EM2874, looks weird but no harm.
>>>>
>>>>
>>>> Main GPIO sequence is that one:
>>>> 000255: 000006 ms 000990 ms c0 00 00 00 80 00 01 00 <<< ff
>>>> 000256: 000004 ms 000994 ms 40 00 00 00 80 00 01 00 >>> fe
>>>> 000257: 000006 ms 001000 ms c0 00 00 00 80 00 01 00 <<< fe
>>>> 000258: 000004 ms 001004 ms 40 00 00 00 80 00 01 00 >>> be
>>>> 000259: 000139 ms 001143 ms c0 00 00 00 80 00 01 00 <<< be
>>>> 000260: 000005 ms 001148 ms 40 00 00 00 80 00 01 00 >>> fe
>>>>
>>>> There is some more GPIOs later, just test with trial and error to find
>>>> out all GPIOs.
>>>>
>>>> Making that device working should be quite easy! There is a little
>>>> change for proprietary firmware for EM2874 which does some nasty
>>>> things, but that is very very unlikely.
>
> Do we know any devices with a "real" proprietary firmware ??
> I'm not talking about custom USB ID, endpoint configuration and minor
> stuff like this...

I am not aware any such em28xx device. Default firmware seems to be just 
enough for most cases. Normally there is 2k eeprom which is used to 
store some basic configuration information, USB IDs and some other 
properties.

I don't know how much expensive 32k eeprom is than 2k eeprom, but one 
possibility is also it is just used because they have had a lot of 
spare 32k eeproms to waste...

>
>>>>
>>>> regards
>>>> Antti
>>>
>>> Thanks for the information. That is way over my head. Is there same
>>> basic reading someone could recommend so I can start to understand the
>>> basics of all this?
>>>
>>> In the mean time, I'm willing to do any testing necessary.
>>>
>>
>> Maybe I could give hour or two for that if you could make tests I ask?
>>
>> If someone else would like to hack with it, I am very happy too. Frank?
>>
>
> Seems like we have all we need, right ? A TDA18271 driver seems to be in
> place, what about the LGDT3305 demodulator ?
> I can try to put the puzzle together, but not before weekend.
> Matthew, stay tuned but be patient. ;)

Good!

Yes, there is existing drivers for all the used chips. Just make correct 
device profile (and hope there is no any nasty custom fw things).


regards
Antti


-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 11/29/2012 02:28 PM, Frank Schäfer wrote:
> Matthew, stay tuned but be patient. ;) Regards, Frank

Sure thing, just let me know what you need me to do!

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

Am 30.11.2012 02:45, schrieb Matthew Gyurgyik:
> On 11/29/2012 02:28 PM, Frank Schäfer wrote:
>> Matthew, stay tuned but be patient. ;) Regards, Frank
>
> Sure thing, just let me know what you need me to do!
>

Ok, please test the attached experimental patch and post the dmesg output.

Open questions:
- setting of EM2874 register 0x0f (XCLK): the Windows doesn't touch this
register, so the default value seems to be used.
  The patch adds 2 debugging lines to find out the default which default
value the em2874 uses.
  For now, I've set this to 12MHz, because the picture shows a 12MHz
oszillator.
- meaning of the gpio sequence / gpio lines assignment (see comments in
the patch).
- remote control support: looking at the product picture on the MSI website,
  the remote control could be the same as sues by the Digivox III. But
that's just a guess.
- LGDT3305 configuration: a few parameters can not be taken form the USB
log. Will ask the author of the driver for help.

But let's do things step by step and see what happens with the patch.

Regards,
Frank

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Experimental-patch-for-the-MSI-DIGIVOX-ATSC-V1.patch --]
[-- Type: text/x-patch; name="0001-Experimental-patch-for-the-MSI-DIGIVOX-ATSC-V1.patch", Size: 4984 bytes --]

>From 77012eb1462912f3ddc38b609bc826b37e55bf1d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Frank=20Sch=C3=A4fer?= <fschaefer.oss@googlemail.com>
Date: Sun, 2 Dec 2012 11:19:20 +0100
Subject: [PATCH] Experimental patch for the 'MSI DIGIVOX ATSC' V1

---
 drivers/media/usb/em28xx/em28xx-cards.c |   33 +++++++++++++++++++++++++++++++
 drivers/media/usb/em28xx/em28xx-dvb.c   |   30 ++++++++++++++++++++++++++++
 drivers/media/usb/em28xx/em28xx.h       |    1 +
 3 Dateien geändert, 64 Zeilen hinzugefügt(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
index 619bffb..aea04d7 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -393,6 +393,21 @@ static struct em28xx_reg_seq pctv_520e[] = {
 	{             -1,   -1,   -1,  -1},
 };
 
+/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+ * GPIO_0 - ??? (related to eeprom reading ?)
+ * GPIO_6 - ??? (TDA18271C2 or/and LGDT3305 reset ?)
+ * GPIO_7 - ??? (wakeup or stream enable ?)
+ */
+static struct em28xx_reg_seq msi_digivox_atsc[] = {
+	{EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
+	{0x0d,            0xff, 0xff,   0},
+	{EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
+	{EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
+	{EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
+	{EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
+	{             -1,   -1,   -1,  -1},
+};
+
 /*
  *  Board definitions
  */
@@ -1988,6 +2003,19 @@ struct em28xx_board em28xx_boards[] = {
 				EM28XX_I2C_CLK_WAIT_ENABLE |
 				EM28XX_I2C_FREQ_400_KHZ,
 	},
+	/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+	 * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
+	[EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
+		.name         = "MSI DIGIVOX ATSC",
+		.dvb_gpio     = msi_digivox_atsc,
+		.has_dvb      = 1,
+		.tuner_type   = TUNER_ABSENT,
+		.ir_codes     = RC_MAP_MSI_DIGIVOX_III,		/* just a guess from looking at the picture */
+		.xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,	/* TODO */
+		.i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
+				EM28XX_I2C_CLK_WAIT_ENABLE |
+				EM28XX_I2C_FREQ_100_KHZ,
+	},
 };
 const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
 
@@ -2145,6 +2173,8 @@ struct usb_device_id em28xx_id_table[] = {
 			.driver_info = EM2884_BOARD_PCTV_510E },
 	{ USB_DEVICE(0x2013, 0x0251),
 			.driver_info = EM2884_BOARD_PCTV_520E },
+	{ USB_DEVICE(0x0db0, 0x8810),
+			.driver_info = EM2874_BOARD_MSI_DIGIVOX_ATSC },
 	{ },
 };
 MODULE_DEVICE_TABLE(usb, em28xx_id_table);
@@ -2963,6 +2993,9 @@ static int em28xx_init_dev(struct em28xx *dev, struct usb_device *udev,
 	dev->em28xx_read_reg_req = em28xx_read_reg_req;
 	dev->board.is_em2800 = em28xx_boards[dev->model].is_em2800;
 
+int regval = em28xx_read_reg(dev, EM28XX_R0F_XCLK);
+pr_err("EM28XX DEBUG: default value of reg 0x0F (EM28XX_R0F_XCLK): 0x%02x\n", regval);
+
 	em28xx_set_model(dev);
 
 	/* Set the default GPO/GPIO for legacy devices */
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c
index 63f2e70..240740b 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -263,6 +263,19 @@ static struct lgdt3305_config em2870_lgdt3304_dev = {
 	.qam_if_khz         = 4000,
 };
 
+static struct lgdt3305_config em2874_lgdt3305_dev = {
+	.i2c_addr           = 0x1c,
+	.demod_chip         = LGDT3305,
+/*	.deny_i2c_rptr      = 1,			*/	/* should we deny access to i2c gate ctrl ??? */
+	.spectral_inversion = 1,
+	.rf_agc_loop        = 0,
+	.mpeg_mode          = LGDT3305_MPEG_SERIAL,
+	.tpclk_edge         = LGDT3305_TPCLK_RISING_EDGE,
+	.tpvalid_polarity   = LGDT3305_TP_VALID_HIGH,
+/*	.vsb_if_khz         = 3250,			*/	/* nothing in the log, needed ? */
+/*	.qam_if_khz         = 4000,			*/	/* confirmed, needed ? */
+};
+
 static struct s921_config sharp_isdbt = {
 	.demod_address = 0x30 >> 1
 };
@@ -1235,6 +1248,23 @@ static int em28xx_dvb_init(struct em28xx *dev)
 			goto out_free;
 		}
 		break;
+	case EM2874_BOARD_MSI_DIGIVOX_ATSC:
+		dvb->fe[0] = dvb_attach(lgdt3305_attach,
+					   &em2874_lgdt3305_dev,
+					   &dev->i2c_adap);
+		if (dvb->fe[0]) {
+			/* FE 0 attach tuner */
+			if (!dvb_attach(tda18271c2dd_attach,
+					dvb->fe[0],
+					&dev->i2c_adap,
+					0xc0)) {
+
+				dvb_frontend_detach(dvb->fe[0]);
+				result = -EINVAL;
+				goto out_free;
+			}
+		}
+		break;
 	default:
 		em28xx_errdev("/2: The frontend of your DVB/ATSC card"
 				" isn't supported yet\n");
diff --git a/drivers/media/usb/em28xx/em28xx.h b/drivers/media/usb/em28xx/em28xx.h
index 86e90d8..3102ff3 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -129,6 +129,7 @@
 #define EM2884_BOARD_PCTV_510E                    85
 #define EM2884_BOARD_PCTV_520E                    86
 #define EM2884_BOARD_TERRATEC_HTC_USB_XS	  87
+#define EM2874_BOARD_MSI_DIGIVOX_ATSC		  88
 
 /* Limits minimum and default number of buffers */
 #define EM28XX_MIN_BUF 4
-- 
1.7.10.4

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/02/2012 01:44 PM, Frank Schäfer wrote:
> Am 30.11.2012 02:45, schrieb Matthew Gyurgyik:
>> On 11/29/2012 02:28 PM, Frank Schäfer wrote:
>>> Matthew, stay tuned but be patient. ;) Regards, Frank
>>
>> Sure thing, just let me know what you need me to do!
>>
>
> Ok, please test the attached experimental patch and post the dmesg output.
>
> Open questions:
> - setting of EM2874 register 0x0f (XCLK): the Windows doesn't touch this
> register, so the default value seems to be used.
>    The patch adds 2 debugging lines to find out the default which default
> value the em2874 uses.
>    For now, I've set this to 12MHz, because the picture shows a 12MHz
> oszillator.
> - meaning of the gpio sequence / gpio lines assignment (see comments in
> the patch).
> - remote control support: looking at the product picture on the MSI website,
>    the remote control could be the same as sues by the Digivox III. But
> that's just a guess.
> - LGDT3305 configuration: a few parameters can not be taken form the USB
> log. Will ask the author of the driver for help.
>
> But let's do things step by step and see what happens with the patch.
>
> Regards,
> Frank
>

Hello
I looked the patch quickly and here are the findings:
I2C addresses are in "8-bit" format. Will not work. Example for tuner, 
0xc0 should be 0x60. Same for the demod. Due to that, no worth to test 
patch. I2C addresses are normally 7-bit, but "unofficial" 8-bit notation 
is also used widely. em28xx uses official notation as almost all other 
media drivers.

You are using tda18271c2dd tuner driver. I recommended to change to the 
other driver named tda18271. tda18271c2dd is very bad choice in that 
case as it discards all the I2C error without any error logging and just 
silently ignores. I remember case when I used that tuner driver for one 
em28xx + drx-k combination and wasted very many hours trying to get it 
working due to missing error logging :/

Don't care XCLK register, it most likely will just as it is. There is 
many EM2874 boards already supported.

12MHz clock is correct and it is seen from the hardware. Generally 12MHz 
xtal is used very often for USB (device to device) as it is suitable 
reference clock.

According to comments, GPIO7 is used when streaming is started / 
stopped. It is about 99% sure LOCK LED :)

When you look sniffs and see some GPIO is changed for example just 
before and after tuner communication you could make assumption it does 
have something to do with tuner (example tuner hw reset / standby).

You should look used intermediate frequencies from the tuner driver and 
configure demod according to that. OK, 3-4 MHz sounds very reasonable 
low-IF values used with tda18271. tda18271 driver supports also get IF 
callback, but demod driver not. That callback allows automatically 
configure correct IF according to what tuner uses. Anyhow, in that case 
you must ensure those manually from tuner driver as demod driver does 
not support get IF. IF is *critical*, if it is wrong then nothing works 
(because demodulator does not get signal from tuner).


regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 02.12.2012 15:23, schrieb Antti Palosaari:
> On 12/02/2012 01:44 PM, Frank Schäfer wrote:
>> Am 30.11.2012 02:45, schrieb Matthew Gyurgyik:
>>> On 11/29/2012 02:28 PM, Frank Schäfer wrote:
>>>> Matthew, stay tuned but be patient. ;) Regards, Frank
>>>
>>> Sure thing, just let me know what you need me to do!
>>>
>>
>> Ok, please test the attached experimental patch and post the dmesg
>> output.
>>
>> Open questions:
>> - setting of EM2874 register 0x0f (XCLK): the Windows doesn't touch this
>> register, so the default value seems to be used.
>>    The patch adds 2 debugging lines to find out the default which
>> default
>> value the em2874 uses.
>>    For now, I've set this to 12MHz, because the picture shows a 12MHz
>> oszillator.
>> - meaning of the gpio sequence / gpio lines assignment (see comments in
>> the patch).
>> - remote control support: looking at the product picture on the MSI
>> website,
>>    the remote control could be the same as sues by the Digivox III. But
>> that's just a guess.
>> - LGDT3305 configuration: a few parameters can not be taken form the USB
>> log. Will ask the author of the driver for help.
>>
>> But let's do things step by step and see what happens with the patch.
>>
>> Regards,
>> Frank
>>
>
> Hello
> I looked the patch quickly and here are the findings:
> I2C addresses are in "8-bit" format. Will not work. Example for tuner,
> 0xc0 should be 0x60. Same for the demod. Due to that, no worth to test
> patch. I2C addresses are normally 7-bit, but "unofficial" 8-bit
> notation is also used widely. em28xx uses official notation as almost
> all other media drivers.

Argh, yeah, I didn't check that. The mixed usage of 7 and 8 bit
notations is a mess.

>
> You are using tda18271c2dd tuner driver. I recommended to change to
> the other driver named tda18271. tda18271c2dd is very bad choice in
> that case as it discards all the I2C error without any error logging
> and just silently ignores. I remember case when I used that tuner
> driver for one em28xx + drx-k combination and wasted very many hours
> trying to get it working due to missing error logging :/

Ok, thanks. So we have two drivers for the same chip and tda18271c2dd is
deprecated ? Can both drivers handle both chip models ?
I thought tda18271c2dd is for the c2 model of the chip and tda18271 for
the "normal" model...
I also wonder why tda18271 is in media/tuners while tda18271c2dd is in
media/dvb-frontends ?

>
> Don't care XCLK register, it most likely will just as it is. There is
> many EM2874 boards already supported.
>
> 12MHz clock is correct and it is seen from the hardware. Generally
> 12MHz xtal is used very often for USB (device to device) as it is
> suitable reference clock.

Likely. But XCLK register also controls a few other things (e.g. remote
control settings) and the em28xx driver overwrites the default register
content in any case.
So let's see what dmesg tells us.

>
> According to comments, GPIO7 is used when streaming is started /
> stopped. It is about 99% sure LOCK LED :)
>
> When you look sniffs and see some GPIO is changed for example just
> before and after tuner communication you could make assumption it does
> have something to do with tuner (example tuner hw reset / standby).

That's possible, but on the other hand, there is a delay of 20ms after
GPIO_7. That shouldn't be necessary for a LED.
Any idea what GPIO_0 is ? it is to set to high (50ms delay afterwards)
when the first chunk of data is read from the eeprom and set back to low
afterwards.

>
> You should look used intermediate frequencies from the tuner driver
> and configure demod according to that. OK, 3-4 MHz sounds very
> reasonable low-IF values used with tda18271. tda18271 driver supports
> also get IF callback, but demod driver not. That callback allows
> automatically configure correct IF according to what tuner uses.
> Anyhow, in that case you must ensure those manually from tuner driver
> as demod driver does not support get IF. IF is *critical*, if it is
> wrong then nothing works (because demodulator does not get signal from
> tuner).

Ok, that means the 'qam_if_khz' and 'vsb_if_khz' in struct
lgdt3305_config are mandatory values and must be set manually.
Looking into the tda18271 driver, vsb_if_khz should be set to 3250.
That's what the other em28xx board uses, too.

I will send an updated version of the patch soon. Thanks for your comments.

Regards,
Frank

>
>
> regards
> Antti
>

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

[-- Attachment #1: Type: text/plain, Size: 5690 bytes --]

Am 02.12.2012 18:18, schrieb Frank Schäfer:
> Am 02.12.2012 15:23, schrieb Antti Palosaari:
>> On 12/02/2012 01:44 PM, Frank Schäfer wrote:
>>> Am 30.11.2012 02:45, schrieb Matthew Gyurgyik:
>>>> On 11/29/2012 02:28 PM, Frank Schäfer wrote:
>>>>> Matthew, stay tuned but be patient. ;) Regards, Frank
>>>> Sure thing, just let me know what you need me to do!
>>>>
>>> Ok, please test the attached experimental patch and post the dmesg
>>> output.
>>>
>>> Open questions:
>>> - setting of EM2874 register 0x0f (XCLK): the Windows doesn't touch this
>>> register, so the default value seems to be used.
>>>    The patch adds 2 debugging lines to find out the default which
>>> default
>>> value the em2874 uses.
>>>    For now, I've set this to 12MHz, because the picture shows a 12MHz
>>> oszillator.
>>> - meaning of the gpio sequence / gpio lines assignment (see comments in
>>> the patch).
>>> - remote control support: looking at the product picture on the MSI
>>> website,
>>>    the remote control could be the same as sues by the Digivox III. But
>>> that's just a guess.
>>> - LGDT3305 configuration: a few parameters can not be taken form the USB
>>> log. Will ask the author of the driver for help.
>>>
>>> But let's do things step by step and see what happens with the patch.
>>>
>>> Regards,
>>> Frank
>>>
>> Hello
>> I looked the patch quickly and here are the findings:
>> I2C addresses are in "8-bit" format. Will not work. Example for tuner,
>> 0xc0 should be 0x60. Same for the demod. Due to that, no worth to test
>> patch. I2C addresses are normally 7-bit, but "unofficial" 8-bit
>> notation is also used widely. em28xx uses official notation as almost
>> all other media drivers.
> Argh, yeah, I didn't check that. The mixed usage of 7 and 8 bit
> notations is a mess.
>
>> You are using tda18271c2dd tuner driver. I recommended to change to
>> the other driver named tda18271. tda18271c2dd is very bad choice in
>> that case as it discards all the I2C error without any error logging
>> and just silently ignores. I remember case when I used that tuner
>> driver for one em28xx + drx-k combination and wasted very many hours
>> trying to get it working due to missing error logging :/
> Ok, thanks. So we have two drivers for the same chip and tda18271c2dd is
> deprecated ? Can both drivers handle both chip models ?
> I thought tda18271c2dd is for the c2 model of the chip and tda18271 for
> the "normal" model...
> I also wonder why tda18271 is in media/tuners while tda18271c2dd is in
> media/dvb-frontends ?
>
>> Don't care XCLK register, it most likely will just as it is. There is
>> many EM2874 boards already supported.
>>
>> 12MHz clock is correct and it is seen from the hardware. Generally
>> 12MHz xtal is used very often for USB (device to device) as it is
>> suitable reference clock.
> Likely. But XCLK register also controls a few other things (e.g. remote
> control settings) and the em28xx driver overwrites the default register
> content in any case.
> So let's see what dmesg tells us.
>
>> According to comments, GPIO7 is used when streaming is started /
>> stopped. It is about 99% sure LOCK LED :)
>>
>> When you look sniffs and see some GPIO is changed for example just
>> before and after tuner communication you could make assumption it does
>> have something to do with tuner (example tuner hw reset / standby).
> That's possible, but on the other hand, there is a delay of 20ms after
> GPIO_7. That shouldn't be necessary for a LED.
> Any idea what GPIO_0 is ? it is to set to high (50ms delay afterwards)
> when the first chunk of data is read from the eeprom and set back to low
> afterwards.
>
>> You should look used intermediate frequencies from the tuner driver
>> and configure demod according to that. OK, 3-4 MHz sounds very
>> reasonable low-IF values used with tda18271. tda18271 driver supports
>> also get IF callback, but demod driver not. That callback allows
>> automatically configure correct IF according to what tuner uses.
>> Anyhow, in that case you must ensure those manually from tuner driver
>> as demod driver does not support get IF. IF is *critical*, if it is
>> wrong then nothing works (because demodulator does not get signal from
>> tuner).
> Ok, that means the 'qam_if_khz' and 'vsb_if_khz' in struct
> lgdt3305_config are mandatory values and must be set manually.
> Looking into the tda18271 driver, vsb_if_khz should be set to 3250.
> That's what the other em28xx board uses, too.
>
> I will send an updated version of the patch soon. Thanks for your comments.

Here is v2 of the patch (attached).

Antti, could you please take a look at the std_map for the tuner ?
I'm not sure what the correct and complete map is.

For a first test, I've selected the same std_map as used with the KWorld
A340 (LGDT3304 + TDA18271 C1/C2):

static struct tda18271_std_map kworld_a340_std_map = {
    .atsc_6   = { .if_freq = 3250, .agc_mode = 3, .std = 0,
              .if_lvl = 1, .rfagc_top = 0x37, },
    .qam_6    = { .if_freq = 4000, .agc_mode = 3, .std = 1,
              .if_lvl = 1, .rfagc_top = 0x37, },
};


These are the relevant tda18271 register values the taken from Matthews
USB-log:

EP3 (0x05): 0x1d
EP4 (0x06): 0x60
EB22 (0x25): 0x37

The LGDT3305 is configured for QAM and IF=4000kHz, which leads to a
tda18271_std_map_item with

{
 .if_freq = 4000,
 .agc_mode = 3,
 .std = 5,
 .fm_rfn = 0,
 .if_lvl = 0,
 .rfagc_top = 0x37,
 }

According to the datasheet and tda18271-maps.c, this should be qam_6,
qam_7 or qam_8.

Do we need further USB-logs from the Windows driver ?
And if yes, do you have any advice for Matthew how to create them ?

Regards,
Frank


> Regards,
> Frank
>
>> regards
>> Antti
>>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Experimental-patch-for-the-MSI-DIGIVOX-ATSC-V2.patch --]
[-- Type: text/x-patch; name="0001-Experimental-patch-for-the-MSI-DIGIVOX-ATSC-V2.patch", Size: 5637 bytes --]

>From f685b93b20544afd700943aa7622d59da18fba1b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Frank=20Sch=C3=A4fer?= <fschaefer.oss@googlemail.com>
Date: Mon, 3 Dec 2012 18:28:50 +0100
Subject: [PATCH] Experimental patch for the 'MSI DIGIVOX ATSC' V2

---
 drivers/media/usb/em28xx/em28xx-cards.c |   37 ++++++++++++++++++++++++++++++
 drivers/media/usb/em28xx/em28xx-dvb.c   |   38 +++++++++++++++++++++++++++++++
 drivers/media/usb/em28xx/em28xx.h       |    1 +
 3 Dateien geändert, 76 Zeilen hinzugefügt(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
index 619bffb..c626aac 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -393,6 +393,21 @@ static struct em28xx_reg_seq pctv_520e[] = {
 	{             -1,   -1,   -1,  -1},
 };
 
+/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+ * GPIO_0 - ??? (related to eeprom reading ?)
+ * GPIO_6 - ??? (TDA18271C2 or/and LGDT3305 reset ?)
+ * GPIO_7 - ??? (wakeup or stream enable ?)
+ */
+static struct em28xx_reg_seq msi_digivox_atsc[] = {
+	{EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
+	{0x0d,            0xff, 0xff,   0},
+	{EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
+	{EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
+	{EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
+	{EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
+	{             -1,   -1,   -1,  -1},
+};
+
 /*
  *  Board definitions
  */
@@ -1988,6 +2003,19 @@ struct em28xx_board em28xx_boards[] = {
 				EM28XX_I2C_CLK_WAIT_ENABLE |
 				EM28XX_I2C_FREQ_400_KHZ,
 	},
+	/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+	 * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
+	[EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
+		.name         = "MSI DIGIVOX ATSC",
+		.dvb_gpio     = msi_digivox_atsc,
+		.has_dvb      = 1,
+		.tuner_type   = TUNER_ABSENT,
+		.ir_codes     = RC_MAP_MSI_DIGIVOX_III,		/* just a guess from looking at the picture */
+		.xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,	/* TODO */
+		.i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
+				EM28XX_I2C_CLK_WAIT_ENABLE |
+				EM28XX_I2C_FREQ_100_KHZ,
+	},
 };
 const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
 
@@ -2145,6 +2173,8 @@ struct usb_device_id em28xx_id_table[] = {
 			.driver_info = EM2884_BOARD_PCTV_510E },
 	{ USB_DEVICE(0x2013, 0x0251),
 			.driver_info = EM2884_BOARD_PCTV_520E },
+	{ USB_DEVICE(0x0db0, 0x8810),
+			.driver_info = EM2874_BOARD_MSI_DIGIVOX_ATSC },
 	{ },
 };
 MODULE_DEVICE_TABLE(usb, em28xx_id_table);
@@ -2963,6 +2993,13 @@ static int em28xx_init_dev(struct em28xx *dev, struct usb_device *udev,
 	dev->em28xx_read_reg_req = em28xx_read_reg_req;
 	dev->board.is_em2800 = em28xx_boards[dev->model].is_em2800;
 
+int regval = em28xx_read_reg(dev, 0x0b);
+pr_err("EM28XX DEBUG: reg 0x0B (UNKNOWN): 0x%02x\n", regval);
+regval = em28xx_read_reg(dev, 0x0d);
+pr_err("EM28XX DEBUG: reg 0x0D (UNKNOWN): 0x%02x\n", regval);
+regval = em28xx_read_reg(dev, EM28XX_R0F_XCLK);
+pr_err("EM28XX DEBUG: reg 0x0F (EM28XX_R0F_XCLK): 0x%02x\n", regval);
+
 	em28xx_set_model(dev);
 
 	/* Set the default GPO/GPIO for legacy devices */
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c
index 63f2e70..8e00a30 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -263,6 +263,18 @@ static struct lgdt3305_config em2870_lgdt3304_dev = {
 	.qam_if_khz         = 4000,
 };
 
+static struct lgdt3305_config em2874_lgdt3305_dev = {
+	.i2c_addr           = 0x0e,
+	.demod_chip         = LGDT3305,
+	.spectral_inversion = 1,
+	.rf_agc_loop        = 0,
+	.mpeg_mode          = LGDT3305_MPEG_SERIAL,
+	.tpclk_edge         = LGDT3305_TPCLK_RISING_EDGE,
+	.tpvalid_polarity   = LGDT3305_TP_VALID_HIGH,
+	.vsb_if_khz         = 3250,		/* not confirmed with a USB log */
+	.qam_if_khz         = 4000,
+};
+
 static struct s921_config sharp_isdbt = {
 	.demod_address = 0x30 >> 1
 };
@@ -713,6 +725,14 @@ static struct tda18271_config em28xx_cxd2820r_tda18271_config = {
 	.gate = TDA18271_GATE_DIGITAL,
 };
 
+static struct tda18271_config em28xx_lgdt3305_tda18271_config = {
+	.std_map = &kworld_a340_std_map,		/* TODO / EXPERIMENTAL */
+	.gate = TDA18271_GATE_DIGITAL,
+	.output_opt = TDA18271_OUTPUT_LT_OFF,
+/*	.rf_cal_on_startup = 1,		*/	/* needed ??? */
+/*	.delay_cal = 1,			*/	/* needed ??? */
+};
+
 static const struct tda10071_config em28xx_tda10071_config = {
 	.i2c_address = 0x55, /* (0xaa >> 1) */
 	.i2c_wr_max = 64,
@@ -1235,6 +1255,24 @@ static int em28xx_dvb_init(struct em28xx *dev)
 			goto out_free;
 		}
 		break;
+	case EM2874_BOARD_MSI_DIGIVOX_ATSC:
+		dvb->fe[0] = dvb_attach(lgdt3305_attach,
+					   &em2874_lgdt3305_dev,
+					   &dev->i2c_adap);
+		if (dvb->fe[0]) {
+			/* FE 0 attach tuner */
+			if (!dvb_attach(tda18271_attach,
+					dvb->fe[0],
+					0x60,
+					&dev->i2c_adap,
+					&em28xx_lgdt3305_tda18271_config)) {
+
+				dvb_frontend_detach(dvb->fe[0]);
+				result = -EINVAL;
+				goto out_free;
+			}
+		}
+		break;
 	default:
 		em28xx_errdev("/2: The frontend of your DVB/ATSC card"
 				" isn't supported yet\n");
diff --git a/drivers/media/usb/em28xx/em28xx.h b/drivers/media/usb/em28xx/em28xx.h
index 86e90d8..3102ff3 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -129,6 +129,7 @@
 #define EM2884_BOARD_PCTV_510E                    85
 #define EM2884_BOARD_PCTV_520E                    86
 #define EM2884_BOARD_TERRATEC_HTC_USB_XS	  87
+#define EM2874_BOARD_MSI_DIGIVOX_ATSC		  88
 
 /* Limits minimum and default number of buffers */
 #define EM28XX_MIN_BUF 4
-- 
1.7.10.4

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/03/2012 01:16 PM, Frank Schäfer wrote:
>
> Here is v2 of the patch (attached).
>
> Antti, could you please take a look at the std_map for the tuner ?
> I'm not sure what the correct and complete map is.
>
> For a first test, I've selected the same std_map as used with the KWorld
> A340 (LGDT3304 + TDA18271 C1/C2):
>
> static struct tda18271_std_map kworld_a340_std_map = {
>      .atsc_6   = { .if_freq = 3250, .agc_mode = 3, .std = 0,
>                .if_lvl = 1, .rfagc_top = 0x37, },
>      .qam_6    = { .if_freq = 4000, .agc_mode = 3, .std = 1,
>                .if_lvl = 1, .rfagc_top = 0x37, },
> };
>
>
> These are the relevant tda18271 register values the taken from Matthews
> USB-log:
>
> EP3 (0x05): 0x1d
> EP4 (0x06): 0x60
> EB22 (0x25): 0x37
>
> The LGDT3305 is configured for QAM and IF=4000kHz, which leads to a
> tda18271_std_map_item with
>
> {
>   .if_freq = 4000,
>   .agc_mode = 3,
>   .std = 5,
>   .fm_rfn = 0,
>   .if_lvl = 0,
>   .rfagc_top = 0x37,
>   }
>
> According to the datasheet and tda18271-maps.c, this should be qam_6,
> qam_7 or qam_8.
>
> Do we need further USB-logs from the Windows driver ?
> And if yes, do you have any advice for Matthew how to create them ?
>
> Regards,
> Frank
>
>
>

What git branch are you writing the patch against?

I had to manually apply the patch by editing each file specified in the 
patch. The patch failed to apply against master (I'm assuming)

I used these commands to check out the code (patched against this code 
base after completing the steps below):
>   git clone git://github.com/torvalds/linux.git v4l-dvb
>   cd v4l-dvb
>   git remote add linuxtv git://linuxtv.org/media_tree.git
>   git remote update

At first I got this error:
> [  709.649264] DVB: Unable to find symbol lgdt3305_attach()
http://pyther.net/a/digivox_atsc/patch2/dmesg_before_lgdt3305.txt

I had to go back into the kernel config uncheck "Autoselect tuners and 
i2c modules to build" and then it included all device drivers under 
"Customise DVB Frontend"

Now the kernel detects the card however, I was unable to successfully 
capture a mpeg2 stream.

> $ dmesg
http://pyther.net/a/digivox_atsc/patch2/dmesg.txt

I attempted to tune to a channel using azap. The channels.conf was 
generated using my pci based tuner card that I have in another system.

> [root@tux ~]# azap -r -c /home/pyther/channels.conf "WATE-DT"
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 525000000 Hz
> video pid 0x07c0, audio pid 0x07c1
> status 00 | signal 4b11 | snr 0066 | ber 00000000 | unc 0000ffff |
> status 1f | signal ffff | snr 01d8 | ber 00000000 | unc 0000ffff | FE_HAS_LOCK

http://pyther.net/a/digivox_atsc/patch2/azap_wate-dt.txt
http://pyther.net/a/digivox_atsc/patch2/azap_ionlife.txt

Although, it looked like tuning was semi-successful, I tried the following

   * cat /dev/dvb/adapter0/dvr0 (no output)
   * mplayer /dev/dvb/adapter0/dvr0 (no output)
   * cat /dev/dvb/adapter0/dvr0 > test.mpg (test.mpg was 0 bytes)

I then attempted to do a tv channel scan:
> [root@tux ~]# scan -A 2 -t 1 
> /usr/share/dvb/atsc/us-Cable-Standard-center-frequencies-QAM256 > 
> ~/channels.conf
It got through a few channels before it crashed with this error
> start_filter:1752: ERROR: ioctl DMX_SET_FILTER failed: 71 Protocol error
http://pyther.net/a/digivox_atsc/patch2/dmesg_after_scan.txt
http://pyther.net/a/digivox_atsc/patch2/lspci_after_scan.txt

While tuned into a channel using azap I ran dvbtraffic:
http://pyther.net/a/digivox_atsc/patch2/dvbtraffic.txt

Just let me know what you need me to do next. I really appreciate the 
work and help!

Regards,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Devin Heitmueller]

On Mon, Dec 3, 2012 at 9:15 PM, Matthew Gyurgyik <matthew@pyther.net> wrote:
> Although, it looked like tuning was semi-successful, I tried the following
>
>   * cat /dev/dvb/adapter0/dvr0 (no output)
>   * mplayer /dev/dvb/adapter0/dvr0 (no output)
>   * cat /dev/dvb/adapter0/dvr0 > test.mpg (test.mpg was 0 bytes)

I would try running "lsusb -v" and send the output.  Make sure that
it's not expecting to use bulk mode for DVB (which would require
driver changes to support).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/03/2012 09:29 PM, Devin Heitmueller wrote:
> On Mon, Dec 3, 2012 at 9:15 PM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>> Although, it looked like tuning was semi-successful, I tried the following
>>
>>    * cat /dev/dvb/adapter0/dvr0 (no output)
>>    * mplayer /dev/dvb/adapter0/dvr0 (no output)
>>    * cat /dev/dvb/adapter0/dvr0 > test.mpg (test.mpg was 0 bytes)
> I would try running "lsusb -v" and send the output.  Make sure that
> it's not expecting to use bulk mode for DVB (which would require
> driver changes to support).
>
> Devin
>
Here is the output of lsusb -v
http://pyther.net/a/digivox_atsc/patch2/lsusb.txt

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Devin Heitmueller]

On Mon, Dec 3, 2012 at 9:42 PM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>> I would try running "lsusb -v" and send the output.  Make sure that
>> it's not expecting to use bulk mode for DVB (which would require
>> driver changes to support).
>>
>> Devin
>>
> Here is the output of lsusb -v
> http://pyther.net/a/digivox_atsc/patch2/lsusb.txt

Hmmm, it's isoc, so that should be ok.  Maybe the 3305 TS
configuration is mismatched (serial vs. parallel).  I don't recall off
the top of my head, but I think em2875 is pretty much always in serial
mode, so check the lgdt3305 config block passed in the dvb_attach()
call and see if it's the same.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

Am 04.12.2012 03:58, schrieb Devin Heitmueller:
> On Mon, Dec 3, 2012 at 9:42 PM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>>> I would try running "lsusb -v" and send the output.  Make sure that
>>> it's not expecting to use bulk mode for DVB (which would require
>>> driver changes to support).
>>>
>>> Devin
>>>
>> Here is the output of lsusb -v
>> http://pyther.net/a/digivox_atsc/patch2/lsusb.txt
> Hmmm, it's isoc, so that should be ok.  Maybe the 3305 TS
> configuration is mismatched (serial vs. parallel).  I don't recall off
> the top of my head, but I think em2875 is pretty much always in serial
> mode, so check the lgdt3305 config block passed in the dvb_attach()
> call and see if it's the same.

I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
but LGDT3305_TPCLK_FALLING_EDGE is used instead of
LGDT3305_TPCLK_RISING_EDGE.
OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...

Matthew, could you please test V3 of the patch ? It is written against
the media_tree staging/for_v3.8 (see http://git.linuxtv.org/media_tree.git).
You could also already test the remote control key map (e.g. with evtest)

Regards,
Frank

>
> Devin
>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Experimental-patch-for-the-MSI-DIGIVOX-ATSC-V3.patch --]
[-- Type: text/x-patch; name="0001-Experimental-patch-for-the-MSI-DIGIVOX-ATSC-V3.patch", Size: 5017 bytes --]

>From 7f7aa989a339f9510db53662042c39551b40b0df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Frank=20Sch=C3=A4fer?= <fschaefer.oss@googlemail.com>
Date: Tue, 4 Dec 2012 22:03:47 +0100
Subject: [PATCH] Experimental patch for the 'MSI DIGIVOX ATSC' V3

---
 drivers/media/usb/em28xx/em28xx-cards.c |   30 ++++++++++++++++++++++++
 drivers/media/usb/em28xx/em28xx-dvb.c   |   38 +++++++++++++++++++++++++++++++
 drivers/media/usb/em28xx/em28xx.h       |    1 +
 3 Dateien geändert, 69 Zeilen hinzugefügt(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
index 619bffb..ec3b29b 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -393,6 +393,21 @@ static struct em28xx_reg_seq pctv_520e[] = {
 	{             -1,   -1,   -1,  -1},
 };
 
+/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+ * GPIO_0 - ??? (related to eeprom reading ?)
+ * GPIO_6 - ??? (TDA18271C2 or/and LGDT3305 reset ?)
+ * GPIO_7 - ??? (wakeup or stream enable ?)
+ */
+static struct em28xx_reg_seq msi_digivox_atsc[] = {
+	{EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
+	{0x0d,            0xff, 0xff,   0},
+	{EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
+	{EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
+	{EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
+	{EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
+	{             -1,   -1,   -1,  -1},
+};
+
 /*
  *  Board definitions
  */
@@ -1988,6 +2003,19 @@ struct em28xx_board em28xx_boards[] = {
 				EM28XX_I2C_CLK_WAIT_ENABLE |
 				EM28XX_I2C_FREQ_400_KHZ,
 	},
+	/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+	 * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
+	[EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
+		.name         = "MSI DIGIVOX ATSC",
+		.dvb_gpio     = msi_digivox_atsc,
+		.has_dvb      = 1,
+		.tuner_type   = TUNER_ABSENT,
+		.ir_codes     = RC_MAP_MSI_DIGIVOX_III,		/* just a guess from looking at the picture */
+		.xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,	/* TODO */
+		.i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
+				EM28XX_I2C_CLK_WAIT_ENABLE |
+				EM28XX_I2C_FREQ_100_KHZ,
+	},
 };
 const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
 
@@ -2145,6 +2173,8 @@ struct usb_device_id em28xx_id_table[] = {
 			.driver_info = EM2884_BOARD_PCTV_510E },
 	{ USB_DEVICE(0x2013, 0x0251),
 			.driver_info = EM2884_BOARD_PCTV_520E },
+	{ USB_DEVICE(0x0db0, 0x8810),
+			.driver_info = EM2874_BOARD_MSI_DIGIVOX_ATSC },
 	{ },
 };
 MODULE_DEVICE_TABLE(usb, em28xx_id_table);
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c
index 63f2e70..b4855c8 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -263,6 +263,18 @@ static struct lgdt3305_config em2870_lgdt3304_dev = {
 	.qam_if_khz         = 4000,
 };
 
+static struct lgdt3305_config em2874_lgdt3305_dev = {
+	.i2c_addr           = 0x0e,
+	.demod_chip         = LGDT3305,
+	.spectral_inversion = 1,
+	.rf_agc_loop        = 0,
+	.mpeg_mode          = LGDT3305_MPEG_PARALLEL,
+	.tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
+	.tpvalid_polarity   = LGDT3305_TP_VALID_HIGH,
+	.vsb_if_khz         = 3250,		/* not confirmed with a USB log */
+	.qam_if_khz         = 4000,
+};
+
 static struct s921_config sharp_isdbt = {
 	.demod_address = 0x30 >> 1
 };
@@ -713,6 +725,14 @@ static struct tda18271_config em28xx_cxd2820r_tda18271_config = {
 	.gate = TDA18271_GATE_DIGITAL,
 };
 
+static struct tda18271_config em28xx_lgdt3305_tda18271_config = {
+	.std_map = &kworld_a340_std_map,		/* TODO / EXPERIMENTAL */
+	.gate = TDA18271_GATE_DIGITAL,
+	.output_opt = TDA18271_OUTPUT_LT_OFF,
+/*	.rf_cal_on_startup = 1,		*/	/* needed ??? */
+/*	.delay_cal = 1,			*/	/* needed ??? */
+};
+
 static const struct tda10071_config em28xx_tda10071_config = {
 	.i2c_address = 0x55, /* (0xaa >> 1) */
 	.i2c_wr_max = 64,
@@ -1235,6 +1255,24 @@ static int em28xx_dvb_init(struct em28xx *dev)
 			goto out_free;
 		}
 		break;
+	case EM2874_BOARD_MSI_DIGIVOX_ATSC:
+		dvb->fe[0] = dvb_attach(lgdt3305_attach,
+					   &em2874_lgdt3305_dev,
+					   &dev->i2c_adap);
+		if (dvb->fe[0]) {
+			/* FE 0 attach tuner */
+			if (!dvb_attach(tda18271_attach,
+					dvb->fe[0],
+					0x60,
+					&dev->i2c_adap,
+					&em28xx_lgdt3305_tda18271_config)) {
+
+				dvb_frontend_detach(dvb->fe[0]);
+				result = -EINVAL;
+				goto out_free;
+			}
+		}
+		break;
 	default:
 		em28xx_errdev("/2: The frontend of your DVB/ATSC card"
 				" isn't supported yet\n");
diff --git a/drivers/media/usb/em28xx/em28xx.h b/drivers/media/usb/em28xx/em28xx.h
index 86e90d8..3102ff3 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -129,6 +129,7 @@
 #define EM2884_BOARD_PCTV_510E                    85
 #define EM2884_BOARD_PCTV_520E                    86
 #define EM2884_BOARD_TERRATEC_HTC_USB_XS	  87
+#define EM2874_BOARD_MSI_DIGIVOX_ATSC		  88
 
 /* Limits minimum and default number of buffers */
 #define EM28XX_MIN_BUF 4
-- 
1.7.10.4

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/04/2012 04:06 PM, Frank Schäfer wrote:
> I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
> but LGDT3305_TPCLK_FALLING_EDGE is used instead of
> LGDT3305_TPCLK_RISING_EDGE.
> OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
>
> Matthew, could you please test V3 of the patch ? It is written against
> the media_tree staging/for_v3.8 (see http://git.linuxtv.org/media_tree.git).
> You could also already test the remote control key map (e.g. with evtest)
>
> Regards,
> Frank
Version 3 has the same behavior has v2. It seems I can tune a channel, 
but trying to watch it fails. There is no data being set to 
/dev/dvb/adapter0/dvr0

Tune channel
> [root@tux ~]# azap -r -c /home/pyther/channels.conf "ION LIF"

> [root@tux ~]# dvbdate
> dvbdate: Unable to get time from multiplex.

I got further on a channel scan but then encountered some errors (no 
channels detected):

http://pyther.net/a/digivox_atsc/patch3/scan.txt
http://pyther.net/a/digivox_atsc/patch3/dmesg_after_scan.txt

dmesg: http://pyther.net/a/digivox_atsc/patch3/dmesg.txt
azap: http://pyther.net/a/digivox_atsc/patch3/azap.txt
dvbtraffic: http://pyther.net/a/digivox_atsc/patch3/dvbtraffic.txt

Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/05/2012 05:41 AM, Matthew Gyurgyik wrote:
> On 12/04/2012 04:06 PM, Frank Schäfer wrote:
>> I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
>> but LGDT3305_TPCLK_FALLING_EDGE is used instead of
>> LGDT3305_TPCLK_RISING_EDGE.
>> OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
>>
>> Matthew, could you please test V3 of the patch ? It is written against
>> the media_tree staging/for_v3.8 (see
>> http://git.linuxtv.org/media_tree.git).
>> You could also already test the remote control key map (e.g. with evtest)
>>
>> Regards,
>> Frank
> Version 3 has the same behavior has v2. It seems I can tune a channel,
> but trying to watch it fails. There is no data being set to
> /dev/dvb/adapter0/dvr0
>
> Tune channel
>> [root@tux ~]# azap -r -c /home/pyther/channels.conf "ION LIF"
>
>> [root@tux ~]# dvbdate
>> dvbdate: Unable to get time from multiplex.
>
> I got further on a channel scan but then encountered some errors (no
> channels detected):
>
> http://pyther.net/a/digivox_atsc/patch3/scan.txt
> http://pyther.net/a/digivox_atsc/patch3/dmesg_after_scan.txt
>
> dmesg: http://pyther.net/a/digivox_atsc/patch3/dmesg.txt
> azap: http://pyther.net/a/digivox_atsc/patch3/azap.txt
> dvbtraffic: http://pyther.net/a/digivox_atsc/patch3/dvbtraffic.txt
>
> Matthew

There is something really wrong.

I am not at US expert but why the hell 
us-Cable-Standard-center-frequencies-QAM256 scans up to 999MHz whilst 
demodulator max is set 858? Either one is wrong.

Also, demod seems to be HAS_LOCK about all the time. As that basic LOCK 
flag is simply false you cannot even thing if there is correct 
configuration on TS interface. If you start zapping that known channel 
and then unplug & plug antenna cable did you see still all the time 
HAS_LOCK? (it should disappear when antenna cable is unplugged).

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/05/2012 07:35 AM, Antti Palosaari wrote:
>
> There is something really wrong.
>
> I am not at US expert but why the hell 
> us-Cable-Standard-center-frequencies-QAM256 scans up to 999MHz whilst 
> demodulator max is set 858? Either one is wrong.
>
> Also, demod seems to be HAS_LOCK about all the time. As that basic 
> LOCK flag is simply false you cannot even thing if there is correct 
> configuration on TS interface. If you start zapping that known channel 
> and then unplug & plug antenna cable did you see still all the time 
> HAS_LOCK? (it should disappear when antenna cable is unplugged).
>
> regards
> Antti
>
When I disconnected the coax cable, the lock went away. When I 
reconnected FE_HAS_LOCK came back.

http://pyther.net/a/digivox_atsc/patch3/azap_disconnect_coax.txt

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/05/2012 11:35 PM, Matthew Gyurgyik wrote:
> On 12/05/2012 07:35 AM, Antti Palosaari wrote:
>>
>> There is something really wrong.
>>
>> I am not at US expert but why the hell
>> us-Cable-Standard-center-frequencies-QAM256 scans up to 999MHz whilst
>> demodulator max is set 858? Either one is wrong.
>>
>> Also, demod seems to be HAS_LOCK about all the time. As that basic
>> LOCK flag is simply false you cannot even thing if there is correct
>> configuration on TS interface. If you start zapping that known channel
>> and then unplug & plug antenna cable did you see still all the time
>> HAS_LOCK? (it should disappear when antenna cable is unplugged).
>>
>> regards
>> Antti
>>
> When I disconnected the coax cable, the lock went away. When I
> reconnected FE_HAS_LOCK came back.
>
> http://pyther.net/a/digivox_atsc/patch3/azap_disconnect_coax.txt

OK, fine, I was then wrong. I have to say you have a lot of channels 
over there what I can see from scan result [1]. Those channels which 
says "tuning failed" are channels where is no transmission and those 
"filter timeout pid" means there is ta ransmission and demod locks. Here 
in Finland we have only ~4 MUX DVB-T and maybe other 4 for DVB-T2.

It is then actually working quite well from the developer point of view 
(as demod loses lock when antenna is unplugged). It means tuner and 
demodular are working but interface (transport stream interface, TS IF) 
between demod and USB-bridge is still broken.

I tried to look again your sniff if I can see what it does just before 
streaming starts, but unfortunately there is no any mention about those 
streaming packets (isoc packets where picture stream is going). Did you 
remove those yourself?


[1] http://pyther.net/a/digivox_atsc/patch3/scan.txt

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/05/2012 05:01 PM, Antti Palosaari wrote:
> OK, fine, I was then wrong. I have to say you have a lot of channels 
> over there what I can see from scan result [1]. Those channels which 
> says "tuning failed" are channels where is no transmission and those 
> "filter timeout pid" means there is ta ransmission and demod locks. 
> Here in Finland we have only ~4 MUX DVB-T and maybe other 4 for DVB-T2.
>
> It is then actually working quite well from the developer point of 
> view (as demod loses lock when antenna is unplugged). It means tuner 
> and demodular are working but interface (transport stream interface, 
> TS IF) between demod and USB-bridge is still broken.
>
> I tried to look again your sniff if I can see what it does just before 
> streaming starts, but unfortunately there is no any mention about 
> those streaming packets (isoc packets where picture stream is going). 
> Did you remove those yourself?
>
No I did not remove the the streaming packets. However I did use the 
parse-usbsnoop.php script to generate parsed-usbsnoop.txt. The original 
snooping log is 354M (I'm assuming it has stream data in it).

I have put the entire log on the server ~85MB bzipped: 
http://pyther.net/a/digivox_atsc/UsbSnoop.log.bz2

Let me know if you think I should do another snoop.

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/06/2012 12:33 AM, Matthew Gyurgyik wrote:
> On 12/05/2012 05:01 PM, Antti Palosaari wrote:
>> OK, fine, I was then wrong. I have to say you have a lot of channels
>> over there what I can see from scan result [1]. Those channels which
>> says "tuning failed" are channels where is no transmission and those
>> "filter timeout pid" means there is ta ransmission and demod locks.
>> Here in Finland we have only ~4 MUX DVB-T and maybe other 4 for DVB-T2.
>>
>> It is then actually working quite well from the developer point of
>> view (as demod loses lock when antenna is unplugged). It means tuner
>> and demodular are working but interface (transport stream interface,
>> TS IF) between demod and USB-bridge is still broken.
>>
>> I tried to look again your sniff if I can see what it does just before
>> streaming starts, but unfortunately there is no any mention about
>> those streaming packets (isoc packets where picture stream is going).
>> Did you remove those yourself?
>>
> No I did not remove the the streaming packets. However I did use the
> parse-usbsnoop.php script to generate parsed-usbsnoop.txt. The original
> snooping log is 354M (I'm assuming it has stream data in it).
>
> I have put the entire log on the server ~85MB bzipped:
> http://pyther.net/a/digivox_atsc/UsbSnoop.log.bz2
>
> Let me know if you think I should do another snoop.

It was good snoop. I didn't saw nothing very interesting. But, I think I 
found the reason. Just add that one line writing 0x42 to register 0x0d. 
IIRC I saw earlier it caused that kind of bug...

+static struct em28xx_reg_seq msi_digivox_atsc[] = {
+	{EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
+	{0x0d,            0xff, 0xff,   0},
+	{EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
	{0x0d,            0x42, 0xff,   0},
+	{EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
+	{EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
+	{EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
+	{             -1,   -1,   -1,  -1},
+};

regards
Antti


-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/05/2012 07:55 PM, Antti Palosaari wrote:
>
> It was good snoop. I didn't saw nothing very interesting. But, I think 
> I found the reason. Just add that one line writing 0x42 to register 
> 0x0d. IIRC I saw earlier it caused that kind of bug...
>
> +static struct em28xx_reg_seq msi_digivox_atsc[] = {
> +    {EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
> +    {0x0d,            0xff, 0xff,   0},
> +    {EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
>     {0x0d,            0x42, 0xff,   0},
> +    {EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
> +    {EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
> +    {EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
> +    {             -1,   -1,   -1,  -1},
> +};
>
> regards
> Antti
>
>
I added that line, recompiled, tried the new module. Unfortunately there 
was no improvement. I didn't see any differences in any of the output 
(dmesg, azap). Let me know if there is any info you want me to get.

Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
> On 12/05/2012 07:55 PM, Antti Palosaari wrote:
>>
>> It was good snoop. I didn't saw nothing very interesting. But, I
>> think I found the reason. Just add that one line writing 0x42 to
>> register 0x0d. IIRC I saw earlier it caused that kind of bug...
>>
>> +static struct em28xx_reg_seq msi_digivox_atsc[] = {
>> +    {EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
>> +    {0x0d,            0xff, 0xff,   0},
>> +    {EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
>>     {0x0d,            0x42, 0xff,   0},
>> +    {EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
>> +    {EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
>> +    {EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
>> +    {             -1,   -1,   -1,  -1},
>> +};
>>
>> regards
>> Antti
>>
>>
> I added that line, recompiled, tried the new module. Unfortunately
> there was no improvement. I didn't see any differences in any of the
> output (dmesg, azap). Let me know if there is any info you want me to
> get.
>
> Matthew

Did you switch back to

    .mpeg_mode      = LGDT3305_MPEG_SERIAL,
    .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,

in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
testing this ?

You could also play with the other gpio settings.

And the last idea (at the moment):

+    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
+    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
+        .name         = "MSI DIGIVOX ATSC",
+        .dvb_gpio     = msi_digivox_atsc,
+        .has_dvb      = 1,
+        .tuner_type   = TUNER_ABSENT,
+        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
from looking at the picture */
+        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
+        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
+                EM28XX_I2C_CLK_WAIT_ENABLE |
+                EM28XX_I2C_FREQ_100_KHZ,
+    },

=> change .xclk to 0x0f.
We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
the Windows drivers seems to use 0x0f instead and we don't what 0x0f
means...

Hope this helps,
Frank

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Devin Heitmueller]

On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
<fschaefer.oss@googlemail.com> wrote:
>
> Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
> > On 12/05/2012 07:55 PM, Antti Palosaari wrote:
> >>
> >> It was good snoop. I didn't saw nothing very interesting. But, I
> >> think I found the reason. Just add that one line writing 0x42 to
> >> register 0x0d. IIRC I saw earlier it caused that kind of bug...
> >>
> >> +static struct em28xx_reg_seq msi_digivox_atsc[] = {
> >> +    {EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
> >> +    {0x0d,            0xff, 0xff,   0},
> >> +    {EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
> >>     {0x0d,            0x42, 0xff,   0},
> >> +    {EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
> >> +    {EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
> >> +    {EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
> >> +    {             -1,   -1,   -1,  -1},
> >> +};
> >>
> >> regards
> >> Antti
> >>
> >>
> > I added that line, recompiled, tried the new module. Unfortunately
> > there was no improvement. I didn't see any differences in any of the
> > output (dmesg, azap). Let me know if there is any info you want me to
> > get.
> >
> > Matthew
>
> Did you switch back to
>
>     .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>     .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>
> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
> testing this ?
>
> You could also play with the other gpio settings.
>
> And the last idea (at the moment):
>
> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
> +        .name         = "MSI DIGIVOX ATSC",
> +        .dvb_gpio     = msi_digivox_atsc,
> +        .has_dvb      = 1,
> +        .tuner_type   = TUNER_ABSENT,
> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
> from looking at the picture */
> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
> +                EM28XX_I2C_CLK_WAIT_ENABLE |
> +                EM28XX_I2C_FREQ_100_KHZ,
> +    },
>
> => change .xclk to 0x0f.
> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
> means...
>
> Hope this helps,
> Frank

I'm pretty sure the XCLK register isn't used at all on the em2874
(it's probably being set in the Windows driver because of some shared
code with the older devices).

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 06.12.2012 22:57, schrieb Devin Heitmueller:
> On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
>>> On 12/05/2012 07:55 PM, Antti Palosaari wrote:
>>>> It was good snoop. I didn't saw nothing very interesting. But, I
>>>> think I found the reason. Just add that one line writing 0x42 to
>>>> register 0x0d. IIRC I saw earlier it caused that kind of bug...
>>>>
>>>> +static struct em28xx_reg_seq msi_digivox_atsc[] = {
>>>> +    {EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
>>>> +    {0x0d,            0xff, 0xff,   0},
>>>> +    {EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
>>>>     {0x0d,            0x42, 0xff,   0},
>>>> +    {EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
>>>> +    {EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
>>>> +    {EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
>>>> +    {             -1,   -1,   -1,  -1},
>>>> +};
>>>>
>>>> regards
>>>> Antti
>>>>
>>>>
>>> I added that line, recompiled, tried the new module. Unfortunately
>>> there was no improvement. I didn't see any differences in any of the
>>> output (dmesg, azap). Let me know if there is any info you want me to
>>> get.
>>>
>>> Matthew
>> Did you switch back to
>>
>>     .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>>     .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>>
>> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
>> testing this ?
>>
>> You could also play with the other gpio settings.
>>
>> And the last idea (at the moment):
>>
>> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
>> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
>> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
>> +        .name         = "MSI DIGIVOX ATSC",
>> +        .dvb_gpio     = msi_digivox_atsc,
>> +        .has_dvb      = 1,
>> +        .tuner_type   = TUNER_ABSENT,
>> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
>> from looking at the picture */
>> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
>> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
>> +                EM28XX_I2C_CLK_WAIT_ENABLE |
>> +                EM28XX_I2C_FREQ_100_KHZ,
>> +    },
>>
>> => change .xclk to 0x0f.
>> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
>> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
>> means...
>>
>> Hope this helps,
>> Frank
> I'm pretty sure the XCLK register isn't used at all on the em2874
> (it's probably being set in the Windows driver because of some shared
> code with the older devices).

That's possible, because Matthews log doesn't show any access to this
register.
If it is not used, the question is if writing 0x07 to this register can
cause any trouble...

Frank

> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Devin Heitmueller]

On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer
<fschaefer.oss@googlemail.com> wrote:
> That's possible, because Matthews log doesn't show any access to this
> register.
> If it is not used, the question is if writing 0x07 to this register can
> cause any trouble...

Historically speaking, on that family of devices registers that are no
longer used get treated as scratch registers (meaning writing to them
has no adverse effect).

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 06.12.2012 23:03, schrieb Devin Heitmueller:
> On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> That's possible, because Matthews log doesn't show any access to this
>> register.
>> If it is not used, the question is if writing 0x07 to this register can
>> cause any trouble...
> Historically speaking, on that family of devices registers that are no
> longer used get treated as scratch registers (meaning writing to them
> has no adverse effect).

Wow, seems like chip manufactures CAN make sane hardware design
decisions after all !  :D

>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/06/2012 04:49 PM, Frank Schäfer wrote:
>
> Did you switch back to
>
>      .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>      .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>
> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
> testing this ?
I did not, but switching back doesn't help.
> You could also play with the other gpio settings.
Can you give me some examples of what I might want to try. I don't 
really understand these gpio settings.
> And the last idea (at the moment):
>
> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
> +        .name         = "MSI DIGIVOX ATSC",
> +        .dvb_gpio     = msi_digivox_atsc,
> +        .has_dvb      = 1,
> +        .tuner_type   = TUNER_ABSENT,
> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
> from looking at the picture */
> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
> +                EM28XX_I2C_CLK_WAIT_ENABLE |
> +                EM28XX_I2C_FREQ_100_KHZ,
> +    },
>
> => change .xclk to 0x0f.
> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
> means...
Unfortunately, this didn't make a difference either.

Here is my current sent of changes against upstream: 
http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
> Hope this helps,
> Frank
>
>

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/06/2012 04:49 PM, Frank Schäfer wrote:
>
>
> Did you switch back to
>
>      .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>      .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>
> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
> testing this ?
>
> You could also play with the other gpio settings.
>
> And the last idea (at the moment):
>
> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
> +        .name         = "MSI DIGIVOX ATSC",
> +        .dvb_gpio     = msi_digivox_atsc,
> +        .has_dvb      = 1,
> +        .tuner_type   = TUNER_ABSENT,
> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
> from looking at the picture */
> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
> +                EM28XX_I2C_CLK_WAIT_ENABLE |
> +                EM28XX_I2C_FREQ_100_KHZ,
> +    },
>
> => change .xclk to 0x0f.
> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
> means...
>
> Hope this helps,
> Frank
>

I lied, it works! I must have forgotten to do run make modules_install 
or something! This patch accurately states my current code changes: 
http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch

I will do more testing and try more channels. Playing the stream with 
mplayer, the audio is clearly out-of-sync. But if I can the stream to a 
file, it doesn't seem out-of-sync but I will do more testing and report 
back.

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/06/2012 05:58 PM, Matthew Gyurgyik wrote:
> On 12/06/2012 04:49 PM, Frank Schäfer wrote:
>>
>>
>> Did you switch back to
>>
>>      .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>>      .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>>
>> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
>> testing this ?
>>
>> You could also play with the other gpio settings.
>>
>> And the last idea (at the moment):
>>
>> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
>> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
>> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
>> +        .name         = "MSI DIGIVOX ATSC",
>> +        .dvb_gpio     = msi_digivox_atsc,
>> +        .has_dvb      = 1,
>> +        .tuner_type   = TUNER_ABSENT,
>> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
>> from looking at the picture */
>> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
>> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
>> +                EM28XX_I2C_CLK_WAIT_ENABLE |
>> +                EM28XX_I2C_FREQ_100_KHZ,
>> +    },
>>
>> => change .xclk to 0x0f.
>> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
>> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
>> means...
>>
>> Hope this helps,
>> Frank
>>
>
> I lied, it works! I must have forgotten to do run make modules_install 
> or something! This patch accurately states my current code changes: 
> http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
>
> I will do more testing and try more channels. Playing the stream with 
> mplayer, the audio is clearly out-of-sync. But if I can the stream to 
> a file, it doesn't seem out-of-sync but I will do more testing and 
> report back.

I was able to do a bit of testing tonight and this is what I found.

A channel scan was unsuccessful:
http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg)

Changing channels by pressing "h" in "mplayer dvb://" caused mplayer to 
crash and this messages to be logged in dmesg
http://pyther.net/a/digivox_atsc/dec06/dmesg_mplayer_switch_channels.txt

Audio is out-of-sync in mplayer. Using cache helps, but over time the 
audio still goes out of sync.
http://pyther.net/a/digivox_atsc/dec06/mplayer_audio_out_of_sync.txt

Using azap to tune and using cat /dev/dvb/adapter0/dvr0 > test.mpg to 
generate a test.mpg

mplayer plays the file fine without audio-sync issues, but VLC and Xine 
refuse to play it. (is this normal?)
> tux:~ $ file test.mpg
> test.mpg: data

I have upload a ~30 second capture from the card: 
http://pyther.net/a/digivox_atsc/dec06/test.mpg (not sure if its helpful 
or not)

I really appreciate the help so far. Things are looking promising.

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Devin Heitmueller]

On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik <matthew@pyther.net> wrote:
> I was able to do a bit of testing tonight and this is what I found.
>
> A channel scan was unsuccessful:
> http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg)
>
> Changing channels by pressing "h" in "mplayer dvb://" caused mplayer to
> crash and this messages to be logged in dmesg
> http://pyther.net/a/digivox_atsc/dec06/dmesg_mplayer_switch_channels.txt

This looks like a combination of a misconfiguration of GPIOs and
mplayer not properly handling an exception condition.  You should
definitely bring this up with the mplayer developers since their app
shouldn't crash under this circumstance.

> Audio is out-of-sync in mplayer. Using cache helps, but over time the audio
> still goes out of sync.
> http://pyther.net/a/digivox_atsc/dec06/mplayer_audio_out_of_sync.txt

This has nothing to do with the tuner.  The tuner delivers the MPEG2
stream already compressed and synchronized.  If you're playback is
out-of-sync, it's probably your ALSA drivers, PulseAudio, or mplayer
that is the culprit.

> Using azap to tune and using cat /dev/dvb/adapter0/dvr0 > test.mpg to
> generate a test.mpg
>
> mplayer plays the file fine without audio-sync issues, but VLC and Xine
> refuse to play it. (is this normal?)

What errors are VLC or Xine showing?  Unless the stream is really
corrupt VLC and Xine should play it fine.  And if the stream were
corrupt it wouldn't play with mplayer either?  This sounds like bugs
in VLC and Xine.

There's definitely something going on in the tuner which is causing
the channel scan to fail (and probably the tuning failure in mplayer).
 But all the stuff with actual playback causing segfaults, A/V sync
issues, and failures to play back in certain applications are all
userland problems that you would need to raise with the developers for
those respective projects.

Cheers,

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/06/2012 10:21 PM, Devin Heitmueller wrote:
> On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>> I was able to do a bit of testing tonight and this is what I found.
>>
>> A channel scan was unsuccessful:
>> http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg)
>>
>> Changing channels by pressing "h" in "mplayer dvb://" caused mplayer to
>> crash and this messages to be logged in dmesg
>> http://pyther.net/a/digivox_atsc/dec06/dmesg_mplayer_switch_channels.txt
> This looks like a combination of a misconfiguration of GPIOs and
> mplayer not properly handling an exception condition.  You should
> definitely bring this up with the mplayer developers since their app
> shouldn't crash under this circumstance.

Sorry I misspoke. mplayer isn't crashing, however it can't read data 
from the tuner and thus closes.

for completeness, mplayer output: 
http://pyther.net/a/digivox_atsc/dec06/mplayer_channel_switch.txt

>
>> Audio is out-of-sync in mplayer. Using cache helps, but over time the audio
>> still goes out of sync.
>> http://pyther.net/a/digivox_atsc/dec06/mplayer_audio_out_of_sync.txt
> This has nothing to do with the tuner.  The tuner delivers the MPEG2
> stream already compressed and synchronized.  If you're playback is
> out-of-sync, it's probably your ALSA drivers, PulseAudio, or mplayer
> that is the culprit.
Ok that make sense, I'd bank it being on mplayer and how it reads the 
stream.

>
>> Using azap to tune and using cat /dev/dvb/adapter0/dvr0 > test.mpg to
>> generate a test.mpg
>>
>> mplayer plays the file fine without audio-sync issues, but VLC and Xine
>> refuse to play it. (is this normal?)
> What errors are VLC or Xine showing?  Unless the stream is really
> corrupt VLC and Xine should play it fine.  And if the stream were
> corrupt it wouldn't play with mplayer either?  This sounds like bugs
> in VLC and Xine.
I would agree with. I got the chance to test another mpeg from my other 
tuner (that I know works well) and had the same issue.

The vlc errors consist of similar messages such as those below:
> [0x7f0200c015a8] ts demux warning: lost synchro
> [0x7f0200c015a8] ts demux debug: skipping 187 bytes of garbage
I had thought I was able to play previous captures in VLC. I was unable 
to test my other card (that I know works well) last night. Now I see 
this is not the case, and it separate issue.

> There's definitely something going on in the tuner which is causing
> the channel scan to fail (and probably the tuning failure in mplayer).
>   But all the stuff with actual playback causing segfaults, A/V sync
> issues, and failures to play back in certain applications are all
> userland problems that you would need to raise with the developers for
> those respective projects.
>
> Cheers,
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 06.12.2012 23:58, schrieb Matthew Gyurgyik:
> On 12/06/2012 04:49 PM, Frank Schäfer wrote:
>>
>>
>> Did you switch back to
>>
>>      .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>>      .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>>
>> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
>> testing this ?
>>
>> You could also play with the other gpio settings.
>>
>> And the last idea (at the moment):
>>
>> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
>> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
>> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
>> +        .name         = "MSI DIGIVOX ATSC",
>> +        .dvb_gpio     = msi_digivox_atsc,
>> +        .has_dvb      = 1,
>> +        .tuner_type   = TUNER_ABSENT,
>> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
>> from looking at the picture */
>> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
>> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
>> +                EM28XX_I2C_CLK_WAIT_ENABLE |
>> +                EM28XX_I2C_FREQ_100_KHZ,
>> +    },
>>
>> => change .xclk to 0x0f.
>> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
>> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
>> means...
>>
>> Hope this helps,
>> Frank
>>
>
> I lied, it works! I must have forgotten to do run make modules_install
> or something! This patch accurately states my current code changes:
> http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch

Great, that's a big one step forward.

Based on this (your) patch, could you please verify that ist was really
the adding of

    {0x0d,            0x42, 0xff,   0},

to struct em28xx_reg_seq msi_digivox_atsc ? The tests before this change
were all made with a wrong combination of configuration values for the
LGDT3305...

Regards,
Frank

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/08/2012 08:52 AM, Frank Schäfer wrote:
>> I lied, it works! I must have forgotten to do run make modules_install
>> or something! This patch accurately states my current code changes:
>> http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
> Great, that's a big one step forward.
>
> Based on this (your) patch, could you please verify that ist was really
> the adding of
>
>      {0x0d,            0x42, 0xff,   0},
>
> to struct em28xx_reg_seq msi_digivox_atsc ? The tests before this change
> were all made with a wrong combination of configuration values for the
> LGDT3305...
I have commented that line out and from some basic testing, it doesn't 
appear to change anything. I can still tune and watch a channel, scan 
still fails.

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

Am 08.12.2012 15:10, schrieb Matthew Gyurgyik:
> On 12/08/2012 08:52 AM, Frank Schäfer wrote:
>>> I lied, it works! I must have forgotten to do run make modules_install
>>> or something! This patch accurately states my current code changes:
>>> http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
>> Great, that's a big one step forward.
>>
>> Based on this (your) patch, could you please verify that ist was really
>> the adding of
>>
>>      {0x0d,            0x42, 0xff,   0},
>>
>> to struct em28xx_reg_seq msi_digivox_atsc ? The tests before this change
>> were all made with a wrong combination of configuration values for the
>> LGDT3305...
> I have commented that line out and from some basic testing, it doesn't
> appear to change anything. I can still tune and watch a channel, scan
> still fails.

Ok, thanks. So the USB log was right and the bridge setup should be
complete, except that the remote control doesn't work yet...

Could you please test the patch in the attachment ?
Changes from V3:
- use the correct demodulator configuration
- changed the remote control map to RC_MAP_KWORLD_315U (same as DIGIVOX
III but without NEC extended address byte)
- switched from the KWorld std_map for the tuner to a custom one. For
QAM, I selected the values from the log and for atsc I took the standard
values from the tda18271 driver.

Regards,
Frank

>
> Thanks,
> Matthew


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Experimental-patch-for-the-MSI-DIGIVOX-ATSC-V4.patch --]
[-- Type: text/x-patch; name="0001-Experimental-patch-for-the-MSI-DIGIVOX-ATSC-V4.patch", Size: 5667 bytes --]

>From bbd130b18bedc2801f6c5a359779b1ad31654924 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Frank=20Sch=C3=A4fer?= <fschaefer.oss@googlemail.com>
Date: Sat, 8 Dec 2012 16:19:01 +0100
Subject: [PATCH] Experimental patch for the 'MSI DIGIVOX ATSC' V4

---
 drivers/media/usb/em28xx/em28xx-cards.c |   30 ++++++++++++++++++++
 drivers/media/usb/em28xx/em28xx-dvb.c   |   47 +++++++++++++++++++++++++++++++
 drivers/media/usb/em28xx/em28xx.h       |    1 +
 3 Dateien geändert, 78 Zeilen hinzugefügt(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
index 619bffb..8ec1e42 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -393,6 +393,21 @@ static struct em28xx_reg_seq pctv_520e[] = {
 	{             -1,   -1,   -1,  -1},
 };
 
+/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+ * GPIO_0 - ??? (related to eeprom reading ?)
+ * GPIO_6 - ??? (TDA18271C2 or/and LGDT3305 reset ?)
+ * GPIO_7 - ??? (wakeup or stream enable ?)
+ */
+static struct em28xx_reg_seq msi_digivox_atsc[] = {
+	{EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
+	{0x0d,            0xff, 0xff,   0},
+	{EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
+	{EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
+	{EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
+	{EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
+	{             -1,   -1,   -1,  -1},
+};
+
 /*
  *  Board definitions
  */
@@ -1988,6 +2003,19 @@ struct em28xx_board em28xx_boards[] = {
 				EM28XX_I2C_CLK_WAIT_ENABLE |
 				EM28XX_I2C_FREQ_400_KHZ,
 	},
+	/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+	 * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
+	[EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
+		.name         = "MSI DIGIVOX ATSC",
+		.dvb_gpio     = msi_digivox_atsc,
+		.has_dvb      = 1,
+		.tuner_type   = TUNER_ABSENT,
+		.ir_codes     = RC_MAP_KWORLD_315U,		/* just a guess from looking at the picture */
+		.xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,
+		.i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
+				EM28XX_I2C_CLK_WAIT_ENABLE |
+				EM28XX_I2C_FREQ_100_KHZ,
+	},
 };
 const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
 
@@ -2145,6 +2173,8 @@ struct usb_device_id em28xx_id_table[] = {
 			.driver_info = EM2884_BOARD_PCTV_510E },
 	{ USB_DEVICE(0x2013, 0x0251),
 			.driver_info = EM2884_BOARD_PCTV_520E },
+	{ USB_DEVICE(0x0db0, 0x8810),
+			.driver_info = EM2874_BOARD_MSI_DIGIVOX_ATSC },
 	{ },
 };
 MODULE_DEVICE_TABLE(usb, em28xx_id_table);
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c
index 63f2e70..603b344 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -263,6 +263,18 @@ static struct lgdt3305_config em2870_lgdt3304_dev = {
 	.qam_if_khz         = 4000,
 };
 
+static struct lgdt3305_config em2874_lgdt3305_dev = {
+	.i2c_addr           = 0x0e,
+	.demod_chip         = LGDT3305,
+	.spectral_inversion = 1,
+	.rf_agc_loop        = 0,
+	.mpeg_mode          = LGDT3305_MPEG_SERIAL,
+	.tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
+	.tpvalid_polarity   = LGDT3305_TP_VALID_HIGH,
+	.vsb_if_khz         = 3250,		/* not confirmed with a USB log */
+	.qam_if_khz         = 4000,
+};
+
 static struct s921_config sharp_isdbt = {
 	.demod_address = 0x30 >> 1
 };
@@ -290,6 +302,15 @@ static struct tda18271_std_map kworld_a340_std_map = {
 		      .if_lvl = 1, .rfagc_top = 0x37, },
 };
 
+static struct tda18271_std_map msi_digivox_atsc_std_map = {
+	/* TODO => taken from struct tda18271_std_map tda18271c2_std_map in tda18271-maps.c */
+	.atsc_6   = { .if_freq = 3250, .agc_mode = 3, .std = 4,
+		      .if_lvl = 1, .rfagc_top = 0x37, }, /* EP3[4:0] 0x1c */
+	/* TODO => values from the USB log, is this qam_6 ? */
+	.qam_6    = { .if_freq = 4000, .agc_mode = 3, .std = 5,
+		      .if_lvl = 0, .rfagc_top = 0x37, },
+};
+
 static struct tda18271_config kworld_a340_config = {
 	.std_map           = &kworld_a340_std_map,
 };
@@ -713,6 +734,14 @@ static struct tda18271_config em28xx_cxd2820r_tda18271_config = {
 	.gate = TDA18271_GATE_DIGITAL,
 };
 
+static struct tda18271_config em28xx_lgdt3305_tda18271_config = {
+	.std_map = &msi_digivox_atsc_std_map,		/* TODO / EXPERIMENTAL */
+	.gate = TDA18271_GATE_DIGITAL,
+	.output_opt = TDA18271_OUTPUT_LT_OFF,
+/*	.rf_cal_on_startup = 1,		*/	/* needed ??? */
+/*	.delay_cal = 1,			*/	/* needed ??? */
+};
+
 static const struct tda10071_config em28xx_tda10071_config = {
 	.i2c_address = 0x55, /* (0xaa >> 1) */
 	.i2c_wr_max = 64,
@@ -1235,6 +1264,24 @@ static int em28xx_dvb_init(struct em28xx *dev)
 			goto out_free;
 		}
 		break;
+	case EM2874_BOARD_MSI_DIGIVOX_ATSC:
+		dvb->fe[0] = dvb_attach(lgdt3305_attach,
+					   &em2874_lgdt3305_dev,
+					   &dev->i2c_adap);
+		if (dvb->fe[0]) {
+			/* FE 0 attach tuner */
+			if (!dvb_attach(tda18271_attach,
+					dvb->fe[0],
+					0x60,
+					&dev->i2c_adap,
+					&em28xx_lgdt3305_tda18271_config)) {
+
+				dvb_frontend_detach(dvb->fe[0]);
+				result = -EINVAL;
+				goto out_free;
+			}
+		}
+		break;
 	default:
 		em28xx_errdev("/2: The frontend of your DVB/ATSC card"
 				" isn't supported yet\n");
diff --git a/drivers/media/usb/em28xx/em28xx.h b/drivers/media/usb/em28xx/em28xx.h
index 86e90d8..3102ff3 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -129,6 +129,7 @@
 #define EM2884_BOARD_PCTV_510E                    85
 #define EM2884_BOARD_PCTV_520E                    86
 #define EM2884_BOARD_TERRATEC_HTC_USB_XS	  87
+#define EM2874_BOARD_MSI_DIGIVOX_ATSC		  88
 
 /* Limits minimum and default number of buffers */
 #define EM28XX_MIN_BUF 4
-- 
1.7.10.4

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/08/2012 10:20 AM, Frank Schäfer wrote:
> Am 08.12.2012 15:10, schrieb Matthew Gyurgyik:
>
> Ok, thanks. So the USB log was right and the bridge setup should be
> complete, except that the remote control doesn't work yet...
>
> Could you please test the patch in the attachment ?
> Changes from V3:
> - use the correct demodulator configuration
> - changed the remote control map to RC_MAP_KWORLD_315U (same as DIGIVOX
> III but without NEC extended address byte)
> - switched from the KWorld std_map for the tuner to a custom one. For
> QAM, I selected the values from the log and for atsc I took the standard
> values from the tda18271 driver.
>
> Regards,
> Frank
>

I tested the patch and this is what I found

The remote still doesn't work, would it be helpful to do a usb snoop 
while using the remote in windows (not sure I can make the win7 driver 
work in xp)?

http://pyther.net/a/digivox_atsc/patch4/evtest.txt

A channel scan still fails with the following error:
 > start_filter:1752: ERROR: ioctl DMX_SET_FILTER failed: 71 Protocol error

However there are no messages in dmesg that indicate any errors / warnings.
http://pyther.net/a/digivox_atsc/patch4/scan.txt

When using mplayer dvb://

It seems that switching channels work a bit better, I can switch more 
channels before I get errors and mplayer closes.

http://pyther.net/a/digivox_atsc/patch4/mplayer.txt

Dmesg: http://pyther.net/a/digivox_atsc/patch4/dmesg.txt

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
> On 12/08/2012 10:20 AM, Frank Schäfer wrote:
>> Am 08.12.2012 15:10, schrieb Matthew Gyurgyik:
>>
>> Ok, thanks. So the USB log was right and the bridge setup should be
>> complete, except that the remote control doesn't work yet...
>>
>> Could you please test the patch in the attachment ?
>> Changes from V3:
>> - use the correct demodulator configuration
>> - changed the remote control map to RC_MAP_KWORLD_315U (same as DIGIVOX
>> III but without NEC extended address byte)
>> - switched from the KWorld std_map for the tuner to a custom one. For
>> QAM, I selected the values from the log and for atsc I took the standard
>> values from the tda18271 driver.
>>
>> Regards,
>> Frank
>>
>
> I tested the patch and this is what I found
>
> The remote still doesn't work, would it be helpful to do a usb snoop
> while using the remote in windows (not sure I can make the win7 driver
> work in xp)?

That shouldn't be necessary. I just noticed that there is a module
parameter 'ir_debug'. ;)
With ir_debug enabled, you should see messages

        em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ

everytime you press a button. Once we know the key codes, we can set up
a key map (if it doesn't exist yet).

>
> http://pyther.net/a/digivox_atsc/patch4/evtest.txt
>
> A channel scan still fails with the following error:
> > start_filter:1752: ERROR: ioctl DMX_SET_FILTER failed: 71 Protocol
> error
>
> However there are no messages in dmesg that indicate any errors /
> warnings.
> http://pyther.net/a/digivox_atsc/patch4/scan.txt
>
> When using mplayer dvb://
>
> It seems that switching channels work a bit better, I can switch more
> channels before I get errors and mplayer closes.
>
> http://pyther.net/a/digivox_atsc/patch4/mplayer.txt
>
> Dmesg: http://pyther.net/a/digivox_atsc/patch4/dmesg.txt

Ok. Hopefully the tuner experts have some ideas... Antti, Devin ?

Regards,
Frank

>
> Thanks,
> Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/08/2012 12:49 PM, Frank Schäfer wrote:
> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>
> That shouldn't be necessary. I just noticed that there is a module
> parameter 'ir_debug'. ;)
> With ir_debug enabled, you should see messages
>
>          em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>
> everytime you press a button. Once we know the key codes, we can set up
> a key map (if it doesn't exist yet).
>

Maybe I'm doing something wrong but didn't have any luck :(

> [root@tux ~]# sudo rmmod em28xx_rc
> [root@tux ~]# sudo rmmod em28xx_dvb
> [root@tux ~]# sudo rmmod em28xx
> [root@tux ~]# modprobe em28xx_rc ir_debug=1

I don't see any additional messages in dmesg.

I verified the remote still works in windows (a stupidity check on my part)

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
> On 12/08/2012 12:49 PM, Frank Schäfer wrote:
>> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>>
>> That shouldn't be necessary. I just noticed that there is a module
>> parameter 'ir_debug'. ;)
>> With ir_debug enabled, you should see messages
>>
>>          em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>>
>> everytime you press a button. Once we know the key codes, we can set up
>> a key map (if it doesn't exist yet).
>>
>
> Maybe I'm doing something wrong but didn't have any luck :(
>
>> [root@tux ~]# sudo rmmod em28xx_rc
>> [root@tux ~]# sudo rmmod em28xx_dvb
>> [root@tux ~]# sudo rmmod em28xx
>> [root@tux ~]# modprobe em28xx_rc ir_debug=1
>
> I don't see any additional messages in dmesg.
>
> I verified the remote still works in windows (a stupidity check on my part)

Maybe Kernel debugs are not enabled? em28xx driver is a little bit 
legacy in logging too as it uses own logging whilst nowadays dynamic 
logging is recommended.

replace KERN_DEBUG as KERN_INFO inside em28xx-input.c and test. It will 
change driver to use Kernel normal log writings instead of current debug 
ones.

regards
Antti


-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/08/2012 04:47 PM, Antti Palosaari wrote:
> On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
>> On 12/08/2012 12:49 PM, Frank Schäfer wrote:
>>> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>>>
>>> That shouldn't be necessary. I just noticed that there is a module
>>> parameter 'ir_debug'. ;)
>>> With ir_debug enabled, you should see messages
>>>
>>>          em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>>>
>>> everytime you press a button. Once we know the key codes, we can set up
>>> a key map (if it doesn't exist yet).
>>>
>>
>> Maybe I'm doing something wrong but didn't have any luck :(
>>
>>> [root@tux ~]# sudo rmmod em28xx_rc
>>> [root@tux ~]# sudo rmmod em28xx_dvb
>>> [root@tux ~]# sudo rmmod em28xx
>>> [root@tux ~]# modprobe em28xx_rc ir_debug=1
>>
>> I don't see any additional messages in dmesg.
>>
>> I verified the remote still works in windows (a stupidity check on my
>> part)
>
> Maybe Kernel debugs are not enabled? em28xx driver is a little bit
> legacy in logging too as it uses own logging whilst nowadays dynamic
> logging is recommended.
>
> replace KERN_DEBUG as KERN_INFO inside em28xx-input.c and test. It will
> change driver to use Kernel normal log writings instead of current debug
> ones.
>
> regards
> Antti
>
>
That unfortunately doesn't make any difference.

I even tried adding a print statment before the debug line got called 
like this (line 97 added; em28xx-input.c):
  97     printk(KERN_INFO "key %02x\n", b);
  98     i2cdprintk("key %02x\n", b);

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 08.12.2012 23:04, schrieb Matthew Gyurgyik:
> On 12/08/2012 04:47 PM, Antti Palosaari wrote:
>> On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
>>> On 12/08/2012 12:49 PM, Frank Schäfer wrote:
>>>> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>>>>
>>>> That shouldn't be necessary. I just noticed that there is a module
>>>> parameter 'ir_debug'. ;)
>>>> With ir_debug enabled, you should see messages
>>>>
>>>>          em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>>>>
>>>> everytime you press a button. Once we know the key codes, we can
>>>> set up
>>>> a key map (if it doesn't exist yet).
>>>>
>>>
>>> Maybe I'm doing something wrong but didn't have any luck :(
>>>
>>>> [root@tux ~]# sudo rmmod em28xx_rc
>>>> [root@tux ~]# sudo rmmod em28xx_dvb
>>>> [root@tux ~]# sudo rmmod em28xx
>>>> [root@tux ~]# modprobe em28xx_rc ir_debug=1
>>>
>>> I don't see any additional messages in dmesg.
>>>
>>> I verified the remote still works in windows (a stupidity check on my
>>> part)
>>
>> Maybe Kernel debugs are not enabled? em28xx driver is a little bit
>> legacy in logging too as it uses own logging whilst nowadays dynamic
>> logging is recommended.
>>
>> replace KERN_DEBUG as KERN_INFO inside em28xx-input.c and test. It will
>> change driver to use Kernel normal log writings instead of current debug
>> ones.
>>
>> regards
>> Antti
>>
>>
> That unfortunately doesn't make any difference.
>
> I even tried adding a print statment before the debug line got called
> like this (line 97 added; em28xx-input.c):
>  97     printk(KERN_INFO "key %02x\n", b);
>  98     i2cdprintk("key %02x\n", b);
>

The relevant line is

297        dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,

Change it to

297        printk(KERN_INFO "%s: toggle: %d, count: %d, key
0x%02x%02x\n", __func__,

Also double-check that the IR module (em28xx_rc) is enabled / gets loaded.

Regards,
Frank

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/09/2012 07:48 AM, Frank Schäfer wrote:
> Am 08.12.2012 23:04, schrieb Matthew Gyurgyik:
>> On 12/08/2012 04:47 PM, Antti Palosaari wrote:
>>> On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
>>>> On 12/08/2012 12:49 PM, Frank Schäfer wrote:
>>>>> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>>>>>
>>>>> That shouldn't be necessary. I just noticed that there is a module
>>>>> parameter 'ir_debug'. ;)
>>>>> With ir_debug enabled, you should see messages
>>>>>
>>>>>           em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>>>>>
>>>>> everytime you press a button. Once we know the key codes, we can
>>>>> set up
>>>>> a key map (if it doesn't exist yet).
>>>>>
>>>>
>>>> Maybe I'm doing something wrong but didn't have any luck :(
>>>>
>>>>> [root@tux ~]# sudo rmmod em28xx_rc
>>>>> [root@tux ~]# sudo rmmod em28xx_dvb
>>>>> [root@tux ~]# sudo rmmod em28xx
>>>>> [root@tux ~]# modprobe em28xx_rc ir_debug=1
>>>>
>>>> I don't see any additional messages in dmesg.
>>>>
>>>> I verified the remote still works in windows (a stupidity check on my
>>>> part)
>>>
>>> Maybe Kernel debugs are not enabled? em28xx driver is a little bit
>>> legacy in logging too as it uses own logging whilst nowadays dynamic
>>> logging is recommended.
>>>
>>> replace KERN_DEBUG as KERN_INFO inside em28xx-input.c and test. It will
>>> change driver to use Kernel normal log writings instead of current debug
>>> ones.
>>>
>>> regards
>>> Antti
>>>
>>>
>> That unfortunately doesn't make any difference.
>>
>> I even tried adding a print statment before the debug line got called
>> like this (line 97 added; em28xx-input.c):
>>   97     printk(KERN_INFO "key %02x\n", b);
>>   98     i2cdprintk("key %02x\n", b);
>>
>
> The relevant line is
>
> 297        dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
>
> Change it to
>
> 297        printk(KERN_INFO "%s: toggle: %d, count: %d, key
> 0x%02x%02x\n", __func__,
>
> Also double-check that the IR module (em28xx_rc) is enabled / gets loaded.
>
> Regards,
> Frank
>
>
Sadly I'm still not getting anything.

[root@tux ~]# rmmod em28xx_rc 

[root@tux ~]# rmmod em28xx_dvb
[root@tux ~]# rmmod em28xx
[root@tux ~]# lsmod | grep em28xx
[root@tux ~]# modprobe em28xx_rc ir_debug=1

[root@tux ~]# lsmod | grep em28xx
em28xx_dvb             17075  0
em28xx_rc               6250  0
em28xx                 85996  2 em28xx_dvb,em28xx_rc
rc_core                12193  3 rc_msi_digivox_iii,em28xx_rc
dvb_core               86050  2 em28xx_dvb,lgdt3305
tveeprom               13658  1 em28xx
videobuf_vmalloc        4136  1 em28xx
videobuf_core          15216  2 videobuf_vmalloc,em28xx
v4l2_common             6927  1 em28xx
videodev               97480  2 em28xx,v4l2_common


Just to make sure I'm not misunderstanding, the messages should get 
logged to dmesg, correct?

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Devin Heitmueller]

On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik <matthew@pyther.net> wrote:
> Just to make sure I'm not misunderstanding, the messages should get logged
> to dmesg, correct?

I wrote the original IR support for the em2874, but it seems to have
changed a bit since I submitted it.  One thing that jumps out at me is
if you specify a remote control of the wrong *type* (e.g. the driver
is configured for RC5 but the actual remote is configured for NEC),
then you're likely to get no events from the device.

You may wish to lookup what type of remote RC_MAP_KWORLD_315U is, and
try a remote that is of the other protocol type (e.g. if
RC_MAP_KWORLD_315U is RC5 then try a remote which is NEC).  Then see
if you get events.  If so, then you know you have the correct RC
protocol and just need to adjust the RC profile specified.

Also, it's possible the remote control is an RC6 remote, which I never
got around to adding em2874 driver support for.  Take a look at the
windows trace and see what register R50 is being set to.  In
particular, bits [3-2] will tell you what RC protocol the Windows
driver expects the remote to be.  I'm pretty sure I put the definition
for the relevant bits in em28xx-reg.h.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 09.12.2012 16:46, schrieb Devin Heitmueller:
> On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>> Just to make sure I'm not misunderstanding, the messages should get logged
>> to dmesg, correct?
> I wrote the original IR support for the em2874, but it seems to have
> changed a bit since I submitted it.  One thing that jumps out at me is
> if you specify a remote control of the wrong *type* (e.g. the driver
> is configured for RC5 but the actual remote is configured for NEC),
> then you're likely to get no events from the device.
>
> You may wish to lookup what type of remote RC_MAP_KWORLD_315U is, and
> try a remote that is of the other protocol type (e.g. if
> RC_MAP_KWORLD_315U is RC5 then try a remote which is NEC).  Then see
> if you get events.  If so, then you know you have the correct RC
> protocol and just need to adjust the RC profile specified.
>
> Also, it's possible the remote control is an RC6 remote, which I never
> got around to adding em2874 driver support for.  Take a look at the
> windows trace and see what register R50 is being set to.  In
> particular, bits [3-2] will tell you what RC protocol the Windows
> driver expects the remote to be.  I'm pretty sure I put the definition
> for the relevant bits in em28xx-reg.h.

According to the USB log, register 0x50 is set to 0x01.

em28xx-reg.h says:

/* em2874 IR config register (0x50) */
#define EM2874_IR_NEC           0x00
#define EM2874_IR_RC5           0x04
#define EM2874_IR_RC6_MODE_0    0x08
#define EM2874_IR_RC6_MODE_6A   0x0b

Any idea what 0x01 is ?

It also seems that em28xx_ir_change_protocol() always sets reg 0x05 to
EM2874_IR_RC5...

Regards,
Frank

> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 09.12.2012 17:19, schrieb Frank Schäfer:
> Am 09.12.2012 16:46, schrieb Devin Heitmueller:
>> On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>>> Just to make sure I'm not misunderstanding, the messages should get logged
>>> to dmesg, correct?
>> I wrote the original IR support for the em2874, but it seems to have
>> changed a bit since I submitted it.  One thing that jumps out at me is
>> if you specify a remote control of the wrong *type* (e.g. the driver
>> is configured for RC5 but the actual remote is configured for NEC),
>> then you're likely to get no events from the device.
>>
>> You may wish to lookup what type of remote RC_MAP_KWORLD_315U is, and
>> try a remote that is of the other protocol type (e.g. if
>> RC_MAP_KWORLD_315U is RC5 then try a remote which is NEC).  Then see
>> if you get events.  If so, then you know you have the correct RC
>> protocol and just need to adjust the RC profile specified.
>>
>> Also, it's possible the remote control is an RC6 remote, which I never
>> got around to adding em2874 driver support for.  Take a look at the
>> windows trace and see what register R50 is being set to.  In
>> particular, bits [3-2] will tell you what RC protocol the Windows
>> driver expects the remote to be.  I'm pretty sure I put the definition
>> for the relevant bits in em28xx-reg.h.
> According to the USB log, register 0x50 is set to 0x01.
>
> em28xx-reg.h says:
>
> /* em2874 IR config register (0x50) */
> #define EM2874_IR_NEC           0x00
> #define EM2874_IR_RC5           0x04
> #define EM2874_IR_RC6_MODE_0    0x08
> #define EM2874_IR_RC6_MODE_6A   0x0b
>
> Any idea what 0x01 is ?
>
> It also seems that em28xx_ir_change_protocol() always sets reg 0x05 to
> EM2874_IR_RC5...

Sorry, I was wrong. Of course it sets 0x05 to EM2874_IR_RC5 or
EM2874_IR_NEC depending on field .xclk in the board struct.

Frank

>
> Regards,
> Frank
>
>> Devin
>>
>> --
>> Devin J. Heitmueller - Kernel Labs
>> http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 09.12.2012 17:23, schrieb Frank Schäfer:
> Am 09.12.2012 17:19, schrieb Frank Schäfer:
>> Am 09.12.2012 16:46, schrieb Devin Heitmueller:
>>> On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>>>> Just to make sure I'm not misunderstanding, the messages should get logged
>>>> to dmesg, correct?
>>> I wrote the original IR support for the em2874, but it seems to have
>>> changed a bit since I submitted it.  One thing that jumps out at me is
>>> if you specify a remote control of the wrong *type* (e.g. the driver
>>> is configured for RC5 but the actual remote is configured for NEC),
>>> then you're likely to get no events from the device.
>>>
>>> You may wish to lookup what type of remote RC_MAP_KWORLD_315U is, and
>>> try a remote that is of the other protocol type (e.g. if
>>> RC_MAP_KWORLD_315U is RC5 then try a remote which is NEC).  Then see
>>> if you get events.  If so, then you know you have the correct RC
>>> protocol and just need to adjust the RC profile specified.
>>>
>>> Also, it's possible the remote control is an RC6 remote, which I never
>>> got around to adding em2874 driver support for.  Take a look at the
>>> windows trace and see what register R50 is being set to.  In
>>> particular, bits [3-2] will tell you what RC protocol the Windows
>>> driver expects the remote to be.  I'm pretty sure I put the definition
>>> for the relevant bits in em28xx-reg.h.
>> According to the USB log, register 0x50 is set to 0x01.
>>
>> em28xx-reg.h says:
>>
>> /* em2874 IR config register (0x50) */
>> #define EM2874_IR_NEC           0x00
>> #define EM2874_IR_RC5           0x04
>> #define EM2874_IR_RC6_MODE_0    0x08
>> #define EM2874_IR_RC6_MODE_6A   0x0b
>>
>> Any idea what 0x01 is ?
>>
>> It also seems that em28xx_ir_change_protocol() always sets reg 0x05 to
>> EM2874_IR_RC5...
> Sorry, I was wrong. Of course it sets 0x05 to EM2874_IR_RC5 or
> EM2874_IR_NEC depending on field .xclk in the board struct.

Forget this sh... (never do multiple things at the same time ;) )

Reg 0x50 is set to according to rc_type specified in the selected remote
control map.
So if the correct map is selected, everything should be fine (as long as
it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).

RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
the stick seems to use no NEC protocol.

Matthew, insert a line

        ir_config = 0x01;

before

380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);

in em28xx-input.c and see if something shows up in the dmesg output.

Regards,
Frank

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/09/2012 12:06 PM, Frank Schäfer wrote:
> Forget this sh... (never do multiple things at the same time ;) )
>
> Reg 0x50 is set to according to rc_type specified in the selected remote
> control map.
> So if the correct map is selected, everything should be fine (as long as
> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).
>
> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
> the stick seems to use no NEC protocol.
>
> Matthew, insert a line
>
>          ir_config = 0x01;
>
> before
>
> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
>
> in em28xx-input.c and see if something shows up in the dmesg output.
>
> Regards,
> Frank

That seems to be a bit more successful!

Here is the dmesg output:

> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6
> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6
> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6
> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6
> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6
> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6
> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2, key 0x61d6

I pressed all the buttons on the remote (40 buttons).

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
> On 12/09/2012 12:06 PM, Frank Schäfer wrote:
>> Forget this sh... (never do multiple things at the same time ;) )
>>
>> Reg 0x50 is set to according to rc_type specified in the selected remote
>> control map.
>> So if the correct map is selected, everything should be fine (as long as
>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).
>>
>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
>> the stick seems to use no NEC protocol.
>>
>> Matthew, insert a line
>>
>>          ir_config = 0x01;
>>
>> before
>>
>> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
>>
>> in em28xx-input.c and see if something shows up in the dmesg output.
>>
>> Regards,
>> Frank
>
> That seems to be a bit more successful!
>
> Here is the dmesg output:
>
>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>> key 0x61d6
>
> I pressed all the buttons on the remote (40 buttons).

Did you cut the dmesg output ? Or do you really get these messages for
key 0x61d6 only ?

It seems like things are working different with reg 0x50 = 0x01. Taking
a look into the datasheet might help, but I don't have it. ;)

Regards,
Frank

>
> Thanks,
> Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Devin Heitmueller]

On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer
<fschaefer.oss@googlemail.com> wrote:
> Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
>> On 12/09/2012 12:06 PM, Frank Schäfer wrote:
>>> Forget this sh... (never do multiple things at the same time ;) )
>>>
>>> Reg 0x50 is set to according to rc_type specified in the selected remote
>>> control map.
>>> So if the correct map is selected, everything should be fine (as long as
>>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).
>>>
>>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
>>> the stick seems to use no NEC protocol.
>>>
>>> Matthew, insert a line
>>>
>>>          ir_config = 0x01;
>>>
>>> before
>>>
>>> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
>>>
>>> in em28xx-input.c and see if something shows up in the dmesg output.
>>>
>>> Regards,
>>> Frank
>>
>> That seems to be a bit more successful!
>>
>> Here is the dmesg output:
>>
>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>>> key 0x61d6
>>
>> I pressed all the buttons on the remote (40 buttons).
>
> Did you cut the dmesg output ? Or do you really get these messages for
> key 0x61d6 only ?
>
> It seems like things are working different with reg 0x50 = 0x01. Taking
> a look into the datasheet might help, but I don't have it. ;)

Setting that bit turns off NEC parity checking.  I don't think we've
ever had a need for it before, which is why it isn't exposed as
configurable functionality in the driver.

No clear answer on how this should be fixed, if that's what is really
required.  I guess in theory we could introduce some new board config
option, but that would likely interfere with the ability to
reconfigure the RC protocol at runtime.  An alternative would be a new
property of the RC profile, but that would pollute the definition of
the struct presumably to work around some bug in a crappy remote
control.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 10.12.2012 16:46, schrieb Devin Heitmueller:
> On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
>>> On 12/09/2012 12:06 PM, Frank Schäfer wrote:
>>>> Forget this sh... (never do multiple things at the same time ;) )
>>>>
>>>> Reg 0x50 is set to according to rc_type specified in the selected remote
>>>> control map.
>>>> So if the correct map is selected, everything should be fine (as long as
>>>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).
>>>>
>>>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
>>>> the stick seems to use no NEC protocol.
>>>>
>>>> Matthew, insert a line
>>>>
>>>>          ir_config = 0x01;
>>>>
>>>> before
>>>>
>>>> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
>>>>
>>>> in em28xx-input.c and see if something shows up in the dmesg output.
>>>>
>>>> Regards,
>>>> Frank
>>> That seems to be a bit more successful!
>>>
>>> Here is the dmesg output:
>>>
>>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>>>> key 0x61d6
>>> I pressed all the buttons on the remote (40 buttons).
>> Did you cut the dmesg output ? Or do you really get these messages for
>> key 0x61d6 only ?
>>
>> It seems like things are working different with reg 0x50 = 0x01. Taking
>> a look into the datasheet might help, but I don't have it. ;)
> Setting that bit turns off NEC parity checking.  I don't think we've
> ever had a need for it before, which is why it isn't exposed as
> configurable functionality in the driver.
>
> No clear answer on how this should be fixed, if that's what is really
> required.  I guess in theory we could introduce some new board config
> option, but that would likely interfere with the ability to
> reconfigure the RC protocol at runtime.  An alternative would be a new
> property of the RC profile, but that would pollute the definition of
> the struct presumably to work around some bug in a crappy remote
> control.

Adding a new property to the RC profile certainly seems to be the
cleanest solution.
Do all protocols have paritiy checking ? Otherwise we could add a new
type RC_TYPE_NEC_NO_PARITY.
OTOH, introducing a new bitfield in struct rc_map might be usefull for
other flags, too, in the future...

Regards,
Frank
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Devin Heitmueller]

On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
> Adding a new property to the RC profile certainly seems to be the
> cleanest solution.
> Do all protocols have paritiy checking ? Otherwise we could add a new
> type RC_TYPE_NEC_NO_PARITY.
> OTOH, introducing a new bitfield in struct rc_map might be usefull for
> other flags, too, in the future...

It's probably also worth mentioning that in that mode the device
reports four bytes, not two.  I guess perhaps if parity is ignored it
reports the data in some other format?  You will probably have to do
some experimentation there.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
>> Adding a new property to the RC profile certainly seems to be the
>> cleanest solution.
>> Do all protocols have paritiy checking ? Otherwise we could add a new
>> type RC_TYPE_NEC_NO_PARITY.
>> OTOH, introducing a new bitfield in struct rc_map might be usefull for
>> other flags, too, in the future...
>
> It's probably also worth mentioning that in that mode the device
> reports four bytes, not two.  I guess perhaps if parity is ignored it
> reports the data in some other format?  You will probably have to do
> some experimentation there.

Uh, current em28xx NEC implementation is locked to traditional 16 bit 
NEC, where is hw checksum used.

Implementation should be changed to more general to support 24 and 32 
bit NEC too. There is multiple drivers doing already that, for example 
AF9015.

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 10.12.2012 18:57, schrieb Antti Palosaari:
> On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
>>> Adding a new property to the RC profile certainly seems to be the
>>> cleanest solution.
>>> Do all protocols have paritiy checking ? Otherwise we could add a new
>>> type RC_TYPE_NEC_NO_PARITY.
>>> OTOH, introducing a new bitfield in struct rc_map might be usefull for
>>> other flags, too, in the future...
>>
>> It's probably also worth mentioning that in that mode the device
>> reports four bytes, not two.  I guess perhaps if parity is ignored it
>> reports the data in some other format?  You will probably have to do
>> some experimentation there.
>
> Uh, current em28xx NEC implementation is locked to traditional 16 bit
> NEC, where is hw checksum used.
>
> Implementation should be changed to more general to support 24 and 32
> bit NEC too. There is multiple drivers doing already that, for example
> AF9015.
>

Hmm... are there and documents (, links, books, ...) where I can learn
more about all those RC protocols ?

Regards
Frank

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/10/2012 09:24 PM, Frank Schäfer wrote:
> Am 10.12.2012 18:57, schrieb Antti Palosaari:
>> On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
>>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
>>>> Adding a new property to the RC profile certainly seems to be the
>>>> cleanest solution.
>>>> Do all protocols have paritiy checking ? Otherwise we could add a new
>>>> type RC_TYPE_NEC_NO_PARITY.
>>>> OTOH, introducing a new bitfield in struct rc_map might be usefull for
>>>> other flags, too, in the future...
>>>
>>> It's probably also worth mentioning that in that mode the device
>>> reports four bytes, not two.  I guess perhaps if parity is ignored it
>>> reports the data in some other format?  You will probably have to do
>>> some experimentation there.
>>
>> Uh, current em28xx NEC implementation is locked to traditional 16 bit
>> NEC, where is hw checksum used.
>>
>> Implementation should be changed to more general to support 24 and 32
>> bit NEC too. There is multiple drivers doing already that, for example
>> AF9015.
>>
>
> Hmm... are there and documents (, links, books, ...) where I can learn
> more about all those RC protocols ?

Specification comes here:
NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:

1) 16bit NEC standard, 1 byte address code, 1 byte key code
full 4 byte code: AA BB CC DD
where:
AA = address code
BB = ~address code
CC = key code
DD = ~key code

checksum:
AA + BB = 0xff
CC + DD = 0xff

2) 24bit NEC extended, 2 byte address code, 1 byte key code
full 4 byte code: AA BB CC DD
where:
AA = address code (MSB)
BB = address code (LSB)
CC = key code
DD = ~key code

3) 32bit NEC full, 4 byte key code
full 4 byte code: AA BB CC DD
where:
AA =
BB =
CC =
DD =

I am not sure if there is separate parts for address and key code in 
case of 32bit NEC. See some existing remote keytables if there is any 
such table. It is very rare protocol. 1) and 2) are much more common.


regards
Antti


-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 10.12.2012 21:48, schrieb Antti Palosaari:
> On 12/10/2012 09:24 PM, Frank Schäfer wrote:
>> Am 10.12.2012 18:57, schrieb Antti Palosaari:
>>> On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
>>>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
>>>>> Adding a new property to the RC profile certainly seems to be the
>>>>> cleanest solution.
>>>>> Do all protocols have paritiy checking ? Otherwise we could add a new
>>>>> type RC_TYPE_NEC_NO_PARITY.
>>>>> OTOH, introducing a new bitfield in struct rc_map might be usefull
>>>>> for
>>>>> other flags, too, in the future...
>>>>
>>>> It's probably also worth mentioning that in that mode the device
>>>> reports four bytes, not two.  I guess perhaps if parity is ignored it
>>>> reports the data in some other format?  You will probably have to do
>>>> some experimentation there.

...

>>>
>>> Uh, current em28xx NEC implementation is locked to traditional 16 bit
>>> NEC, where is hw checksum used.
>>>
>>> Implementation should be changed to more general to support 24 and 32
>>> bit NEC too. There is multiple drivers doing already that, for example
>>> AF9015.
>>>
>>
>> Hmm... are there and documents (, links, books, ...) where I can learn
>> more about all those RC protocols ?
>
> Specification comes here:
> NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
>
> 1) 16bit NEC standard, 1 byte address code, 1 byte key code
> full 4 byte code: AA BB CC DD
> where:
> AA = address code
> BB = ~address code
> CC = key code
> DD = ~key code
>
> checksum:
> AA + BB = 0xff
> CC + DD = 0xff
>
> 2) 24bit NEC extended, 2 byte address code, 1 byte key code
> full 4 byte code: AA BB CC DD
> where:
> AA = address code (MSB)
> BB = address code (LSB)
> CC = key code
> DD = ~key code
>
> 3) 32bit NEC full, 4 byte key code
> full 4 byte code: AA BB CC DD
> where:
> AA =
> BB =
> CC =
> DD =
>
> I am not sure if there is separate parts for address and key code in
> case of 32bit NEC. See some existing remote keytables if there is any
> such table. It is very rare protocol. 1) and 2) are much more common.
>

Many thanks.
So the problem is, that we have only a single RC_TYPE for all 3 protocol
variants and need a method to distinguish between them, right ?

Regards,
Frank


>
> regards
> Antti
>
>

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/11/2012 10:51 PM, Frank Schäfer wrote:
> Am 10.12.2012 21:48, schrieb Antti Palosaari:
>> On 12/10/2012 09:24 PM, Frank Schäfer wrote:
>>> Am 10.12.2012 18:57, schrieb Antti Palosaari:
>>>> On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
>>>>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
>>>>>> Adding a new property to the RC profile certainly seems to be the
>>>>>> cleanest solution.
>>>>>> Do all protocols have paritiy checking ? Otherwise we could add a new
>>>>>> type RC_TYPE_NEC_NO_PARITY.
>>>>>> OTOH, introducing a new bitfield in struct rc_map might be usefull
>>>>>> for
>>>>>> other flags, too, in the future...
>>>>>
>>>>> It's probably also worth mentioning that in that mode the device
>>>>> reports four bytes, not two.  I guess perhaps if parity is ignored it
>>>>> reports the data in some other format?  You will probably have to do
>>>>> some experimentation there.
>
> ...
>
>>>>
>>>> Uh, current em28xx NEC implementation is locked to traditional 16 bit
>>>> NEC, where is hw checksum used.
>>>>
>>>> Implementation should be changed to more general to support 24 and 32
>>>> bit NEC too. There is multiple drivers doing already that, for example
>>>> AF9015.
>>>>
>>>
>>> Hmm... are there and documents (, links, books, ...) where I can learn
>>> more about all those RC protocols ?
>>
>> Specification comes here:
>> NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
>>
>> 1) 16bit NEC standard, 1 byte address code, 1 byte key code
>> full 4 byte code: AA BB CC DD
>> where:
>> AA = address code
>> BB = ~address code
>> CC = key code
>> DD = ~key code
>>
>> checksum:
>> AA + BB = 0xff
>> CC + DD = 0xff
>>
>> 2) 24bit NEC extended, 2 byte address code, 1 byte key code
>> full 4 byte code: AA BB CC DD
>> where:
>> AA = address code (MSB)
>> BB = address code (LSB)
>> CC = key code
>> DD = ~key code
>>
>> 3) 32bit NEC full, 4 byte key code
>> full 4 byte code: AA BB CC DD
>> where:
>> AA =
>> BB =
>> CC =
>> DD =
>>
>> I am not sure if there is separate parts for address and key code in
>> case of 32bit NEC. See some existing remote keytables if there is any
>> such table. It is very rare protocol. 1) and 2) are much more common.
>>
>
> Many thanks.
> So the problem is, that we have only a single RC_TYPE for all 3 protocol
> variants and need a method to distinguish between them, right ?

Yes, that is. I have said it "million" times I would like to see that 
implemented as a one single 4 byte NEC, but it is currently what it is. 
What I understand David Härdeman has done some work toward that too, but 
it is not ready.
See current af9015 driver as example how driver makes decision which 
variant of NEC is used. You will need something similar. Read all 4 NEC 
bytes from the hardware and then use driver to make decision which 
variant it is. I am quite sure em28xx hardware supports reading all 4 
bytes, but if not, you will need to do some other tricks.

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 11.12.2012 21:59, schrieb Antti Palosaari:
> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
>> Am 10.12.2012 21:48, schrieb Antti Palosaari:
>>> On 12/10/2012 09:24 PM, Frank Schäfer wrote:
>>>> Am 10.12.2012 18:57, schrieb Antti Palosaari:
>>>>> On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
>>>>>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
>>>>>>> Adding a new property to the RC profile certainly seems to be the
>>>>>>> cleanest solution.
>>>>>>> Do all protocols have paritiy checking ? Otherwise we could add
>>>>>>> a new
>>>>>>> type RC_TYPE_NEC_NO_PARITY.
>>>>>>> OTOH, introducing a new bitfield in struct rc_map might be usefull
>>>>>>> for
>>>>>>> other flags, too, in the future...
>>>>>>
>>>>>> It's probably also worth mentioning that in that mode the device
>>>>>> reports four bytes, not two.  I guess perhaps if parity is
>>>>>> ignored it
>>>>>> reports the data in some other format?  You will probably have to do
>>>>>> some experimentation there.
>>
>> ...
>>
>>>>>
>>>>> Uh, current em28xx NEC implementation is locked to traditional 16 bit
>>>>> NEC, where is hw checksum used.
>>>>>
>>>>> Implementation should be changed to more general to support 24 and 32
>>>>> bit NEC too. There is multiple drivers doing already that, for
>>>>> example
>>>>> AF9015.
>>>>>
>>>>
>>>> Hmm... are there and documents (, links, books, ...) where I can learn
>>>> more about all those RC protocols ?
>>>
>>> Specification comes here:
>>> NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
>>>
>>> 1) 16bit NEC standard, 1 byte address code, 1 byte key code
>>> full 4 byte code: AA BB CC DD
>>> where:
>>> AA = address code
>>> BB = ~address code
>>> CC = key code
>>> DD = ~key code
>>>
>>> checksum:
>>> AA + BB = 0xff
>>> CC + DD = 0xff
>>>
>>> 2) 24bit NEC extended, 2 byte address code, 1 byte key code
>>> full 4 byte code: AA BB CC DD
>>> where:
>>> AA = address code (MSB)
>>> BB = address code (LSB)
>>> CC = key code
>>> DD = ~key code
>>>
>>> 3) 32bit NEC full, 4 byte key code
>>> full 4 byte code: AA BB CC DD
>>> where:
>>> AA =
>>> BB =
>>> CC =
>>> DD =
>>>
>>> I am not sure if there is separate parts for address and key code in
>>> case of 32bit NEC. See some existing remote keytables if there is any
>>> such table. It is very rare protocol. 1) and 2) are much more common.
>>>
>>
>> Many thanks.
>> So the problem is, that we have only a single RC_TYPE for all 3 protocol
>> variants and need a method to distinguish between them, right ?
>
> Yes, that is. I have said it "million" times I would like to see that
> implemented as a one single 4 byte NEC, but it is currently what it
> is. What I understand David Härdeman has done some work toward that
> too, but it is not ready.
> See current af9015 driver as example how driver makes decision which
> variant of NEC is used. You will need something similar. Read all 4
> NEC bytes from the hardware and then use driver to make decision which
> variant it is.

Yes, checking for inverted address and key code bytes would be a
possibility...
OTOH it's a kind of hack and I think this issue should be fixed in th rc
core.

A possible solution would be to add three new RC_TYPEs (e.g.
RC_TYPE_NEC_STD, RC_TYPE_NEC_EXT, RC_TYPE_NEC_FULL).
RC_TYPE_NEC can be kept for compatibility but should be marked as
deprecated.

Hmmm... thinking about it for some minutes... Why the hell do we bind rc
maps to protocols ?
A key map consists of pairs of a scan code and the corresponding key
code. But that's common to all protocols, right ?
So why do we restrict a keymap to a specific protocol ?
Ok, rc_type is a bit field, so a key map can be bound to multiple protocols.
But then we can't use it to configure the hardware driver, which is
exactly out problem here...

> I am quite sure em28xx hardware supports reading all 4 bytes, but if
> not, you will need to do some other tricks.

Yes, reading 4 bytes form the hardware seems to supported.

Devin, how does it works with reg 0x50=0x01 ?
Have I understood you right that it means the 32bit NEC protocol variant
is used ?
Can the key code be read as usual from regs 0x52-0x55 ?
Any changes in reg 0x51 ?
And for that matter - what's the meaning of bit 1 in reg 0x50 ? ;)

Regards,
Frank

>
> regards
> Antti
>

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 12.12.2012 22:25, schrieb Frank Schäfer:

...
> Am 11.12.2012 21:59, schrieb Antti Palosaari:
>> See current af9015 driver as example how driver makes decision which
>> variant of NEC is used. You will need something similar. Read all 4
>> NEC bytes from the hardware and then use driver to make decision which
>> variant it is.
> Yes, checking for inverted address and key code bytes would be a
> possibility...

The problem here is of course, that we have to configure the device first.
So we need to know the protocol variant before getting any bytes from
the device...

Frank

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/12/2012 11:34 PM, Frank Schäfer wrote:
> Am 12.12.2012 22:25, schrieb Frank Schäfer:
>
> ...
>> Am 11.12.2012 21:59, schrieb Antti Palosaari:
>>> See current af9015 driver as example how driver makes decision which
>>> variant of NEC is used. You will need something similar. Read all 4
>>> NEC bytes from the hardware and then use driver to make decision which
>>> variant it is.
>> Yes, checking for inverted address and key code bytes would be a
>> possibility...
>
> The problem here is of course, that we have to configure the device first.
> So we need to know the protocol variant before getting any bytes from
> the device...

No, you now don't see the point correctly. If you read 4 byte "full NEC" 
code from the hardware, you will not need to know which variant it is 
for configure hardware. 4 byte, full NEC, presents all the variants.

Think it like NEC code is always 4 byte long as lower layer. All NEC 
remotes sends 4 byte codes regardless which variant. In receiver side, 
after decoding there is also 4 byte always. Variants are done very upper 
layer after decoding.

Let me take some existing examples:
------------------
rc-trekstor.c:	{ 0x0084, KEY_0 },
This is actually 1 byte NEC, which is device id == 0.
4 byte real code is: 00 ff 84 7b
------------------
rc-terratec-slim-2.c:	{ 0x800d, KEY_0 },
This is normal, traditional, oldest, most common, 2 byte NEC.
4 byte real code is: 80 7f 0d f2
------------------
rc-terratec-slim.c:	{ 0x02bd09, KEY_0 },
Extended NEC, quite common, 3 byte NEC.
4 byte real code is: 02 bd 09 f6
------------------
rc-tivo.c:	{ 0xa10c8c03, KEY_NUMERIC_0 },
"full" NEC, 4 byte NEC.
Not very common, but coming slowly more popular.
4 byte real code is: a1 0c 8c 03


As you can see all NEC variants could be presented as 4 byte NEC. Even 
the "one byte NEC", which comes in that case (rc-trekstor.c) "00 ff 84 
7b" as 4 byte real notation.


regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 13.12.2012 16:09, schrieb Antti Palosaari:
> On 12/12/2012 11:34 PM, Frank Schäfer wrote:
>> Am 12.12.2012 22:25, schrieb Frank Schäfer:
>>
>> ...
>>> Am 11.12.2012 21:59, schrieb Antti Palosaari:
>>>> See current af9015 driver as example how driver makes decision which
>>>> variant of NEC is used. You will need something similar. Read all 4
>>>> NEC bytes from the hardware and then use driver to make decision which
>>>> variant it is.
>>> Yes, checking for inverted address and key code bytes would be a
>>> possibility...
>>
>> The problem here is of course, that we have to configure the device
>> first.
>> So we need to know the protocol variant before getting any bytes from
>> the device...
>
> No, you now don't see the point correctly. If you read 4 byte "full
> NEC" code from the hardware, you will not need to know which variant
> it is for configure hardware. 4 byte, full NEC, presents all the
> variants.
>
> Think it like NEC code is always 4 byte long as lower layer. All NEC
> remotes sends 4 byte codes regardless which variant. In receiver side,
> after decoding there is also 4 byte always. Variants are done very
> upper layer after decoding.
>
> Let me take some existing examples:
> ------------------
> rc-trekstor.c:    { 0x0084, KEY_0 },
> This is actually 1 byte NEC, which is device id == 0.
> 4 byte real code is: 00 ff 84 7b
> ------------------
> rc-terratec-slim-2.c:    { 0x800d, KEY_0 },
> This is normal, traditional, oldest, most common, 2 byte NEC.
> 4 byte real code is: 80 7f 0d f2
> ------------------
> rc-terratec-slim.c:    { 0x02bd09, KEY_0 },
> Extended NEC, quite common, 3 byte NEC.
> 4 byte real code is: 02 bd 09 f6
> ------------------
> rc-tivo.c:    { 0xa10c8c03, KEY_NUMERIC_0 },
> "full" NEC, 4 byte NEC.
> Not very common, but coming slowly more popular.
> 4 byte real code is: a1 0c 8c 03
>
>
> As you can see all NEC variants could be presented as 4 byte NEC. Even
> the "one byte NEC", which comes in that case (rc-trekstor.c) "00 ff 84
> 7b" as 4 byte real notation.

Sure, we always get 4 bytes from the hardware.
But there must be a difference on the hardware level, otherwise the
em2874 wouldn't use different values for reg 0x50 (and Matthew should
see messages for ALL keys).

Regards,
Frank

>
>
> regards
> Antti
>

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
> > Am 10.12.2012 21:48, schrieb Antti Palosaari:
> >> On 12/10/2012 09:24 PM, Frank Schäfer wrote:
> >>> Am 10.12.2012 18:57, schrieb Antti Palosaari:
> >>>> On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
> >>>>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
> >>>>>> Adding a new property to the RC profile certainly seems to be the
> >>>>>> cleanest solution.
> >>>>>> Do all protocols have paritiy checking ? Otherwise we could add a new
> >>>>>> type RC_TYPE_NEC_NO_PARITY.
> >>>>>> OTOH, introducing a new bitfield in struct rc_map might be usefull
> >>>>>> for
> >>>>>> other flags, too, in the future...
> >>>>>
> >>>>> It's probably also worth mentioning that in that mode the device
> >>>>> reports four bytes, not two.  I guess perhaps if parity is ignored it
> >>>>> reports the data in some other format?  You will probably have to do
> >>>>> some experimentation there.
> >
> > ...
> >
> >>>>
> >>>> Uh, current em28xx NEC implementation is locked to traditional 16 bit
> >>>> NEC, where is hw checksum used.
> >>>>
> >>>> Implementation should be changed to more general to support 24 and 32
> >>>> bit NEC too. There is multiple drivers doing already that, for example
> >>>> AF9015.
> >>>>
> >>>
> >>> Hmm... are there and documents (, links, books, ...) where I can learn
> >>> more about all those RC protocols ?
> >>
> >> Specification comes here:
> >> NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
> >>
> >> 1) 16bit NEC standard, 1 byte address code, 1 byte key code
> >> full 4 byte code: AA BB CC DD
> >> where:
> >> AA = address code
> >> BB = ~address code
> >> CC = key code
> >> DD = ~key code
> >>
> >> checksum:
> >> AA + BB = 0xff
> >> CC + DD = 0xff
> >>
> >> 2) 24bit NEC extended, 2 byte address code, 1 byte key code
> >> full 4 byte code: AA BB CC DD
> >> where:
> >> AA = address code (MSB)
> >> BB = address code (LSB)
> >> CC = key code
> >> DD = ~key code
> >>
> >> 3) 32bit NEC full, 4 byte key code
> >> full 4 byte code: AA BB CC DD
> >> where:
> >> AA =
> >> BB =
> >> CC =
> >> DD =
> >>
> >> I am not sure if there is separate parts for address and key code in
> >> case of 32bit NEC. See some existing remote keytables if there is any
> >> such table. It is very rare protocol. 1) and 2) are much more common.
> >>
> >
> > Many thanks.
> > So the problem is, that we have only a single RC_TYPE for all 3 protocol
> > variants and need a method to distinguish between them, right ?

This is not actually needed, as it is very easy to distinguish them when
doing the table lookups. Take a look at v4l-utils, at /utils/keytable/rc_keymaps:

A 16-bits NEC table:
	# table kworld_315u, type: NEC
	0x6143 KEY_POWER
	0x6101 KEY_VIDEO
	...

A 24-bits NEC table:
	# table pixelview_002t, type: NEC
	0x866b13 KEY_MUTE
	0x866b12 KEY_POWER2
	...

A 32-bits NEC table:
	# table tivo, type: NEC
	0xa10c900f KEY_MEDIA
	0xa10c0807 KEY_POWER2
	...

If you see there, there's no way for the Kernel to handle it wrong, as
there's an implicit rule when dealing with "extended NEC" protocols:

Being the IR code being given by: AA BB CC DD

On a 24-bit NEC table: AA is always different than ~BB, otherwise, it would
be a 16-bit NEC.

On a 32-bit NEC table: CC is always different than ~DD, otherwise, it would be
a 24-bit NEC.

> Yes, that is. I have said it "million" times I would like to see that 
> implemented as a one single 4 byte NEC, but it is currently what it is. 

The hard thing is that, if this is changed upstream, existing
tools/keytables will break. So, regressions will be introduced.

> What I understand David Härdeman has done some work toward that too, but 
> it is not ready.

One alternative would be to add some compatibility code at the table
read function that would convert a 16 bits or 24 bits NEC keycode table
into a 32 bits one, but doing it right can be a problem.

> See current af9015 driver as example how driver makes decision which 
> variant of NEC is used. You will need something similar. Read all 4 NEC 
> bytes from the hardware and then use driver to make decision which 
> variant it is. I am quite sure em28xx hardware supports reading all 4 
> bytes, but if not, you will need to do some other tricks.
> 
> regards
> Antti
> 

Regards,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
> Em Tue, 11 Dec 2012 22:59:06 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
>>> Am 10.12.2012 21:48, schrieb Antti Palosaari:
>>>> On 12/10/2012 09:24 PM, Frank Schäfer wrote:
>>>>> Am 10.12.2012 18:57, schrieb Antti Palosaari:
>>>>> Specification comes here:
>>>>> NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
>>>>>
>>>>> 1) 16bit NEC standard, 1 byte address code, 1 byte key code
>>>>> full 4 byte code: AA BB CC DD
>>>>> where:
>>>>> AA = address code
>>>>> BB = ~address code
>>>>> CC = key code
>>>>> DD = ~key code
>>>>>
>>>>> checksum:
>>>>> AA + BB = 0xff
>>>>> CC + DD = 0xff
>>>>>
>>>>> 2) 24bit NEC extended, 2 byte address code, 1 byte key code
>>>>> full 4 byte code: AA BB CC DD
>>>>> where:
>>>>> AA = address code (MSB)
>>>>> BB = address code (LSB)
>>>>> CC = key code
>>>>> DD = ~key code
>>>>>
>>>>> 3) 32bit NEC full, 4 byte key code
>>>>> full 4 byte code: AA BB CC DD
>>>>> where:
>>>>> AA =
>>>>> BB =
>>>>> CC =
>>>>> DD =
>>>>>
>>>>> I am not sure if there is separate parts for address and key code in
>>>>> case of 32bit NEC. See some existing remote keytables if there is any
>>>>> such table. It is very rare protocol. 1) and 2) are much more common.
>>>>>
>>> Many thanks.
>>> So the problem is, that we have only a single RC_TYPE for all 3 protocol
>>> variants and need a method to distinguish between them, right ?
> This is not actually needed, as it is very easy to distinguish them when
> doing the table lookups. Take a look at v4l-utils, at /utils/keytable/rc_keymaps:
>
> A 16-bits NEC table:
> 	# table kworld_315u, type: NEC
> 	0x6143 KEY_POWER
> 	0x6101 KEY_VIDEO
> 	...

So 0x6143 is not the same as 0x006143 and 0x00006143 ???

And even when assuming that 00 bytes are unused: do you really think the
driver should parse the whole rc map and check all scancodes to find out
which sub-protocol is used ?


> A 24-bits NEC table:
> 	# table pixelview_002t, type: NEC
> 	0x866b13 KEY_MUTE
> 	0x866b12 KEY_POWER2
> 	...
>
> A 32-bits NEC table:
> 	# table tivo, type: NEC
> 	0xa10c900f KEY_MEDIA
> 	0xa10c0807 KEY_POWER2
> 	...
>
> If you see there, there's no way for the Kernel to handle it wrong, as
> there's an implicit rule when dealing with "extended NEC" protocols:
>
> Being the IR code being given by: AA BB CC DD
>
> On a 24-bit NEC table: AA is always different than ~BB, otherwise, it would
> be a 16-bit NEC.

No, if AA != ~BB it can't be 16 bit, but if AA == ~BB, it can still be
16, 24 or 32bit !

> On a 32-bit NEC table: CC is always different than ~DD, otherwise, it would be
> a 24-bit NEC.

Right, if CC != ~DD it must be 32 bit.


So what if we get 52 AD 76 89 from the hardware ? This can be 32, 24 or
16 bit !


Anyway, first we have to GET the bytes from the hardware. That's our
current problem !
And the hardware seems to need a different setup for reg 0x50 for the
different NEC sub protocols.
Which means that the we need to know the sub protocol BEFORE we get any
bytes from the device.

Regards,
Frank

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

[-- Attachment #1: Type: text/plain, Size: 4035 bytes --]

On 12/14/2012 05:33 PM, Frank Schäfer wrote:
> Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
>> Em Tue, 11 Dec 2012 22:59:06 +0200
>> Antti Palosaari <crope@iki.fi> escreveu:
>>
>>> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
>>>> Am 10.12.2012 21:48, schrieb Antti Palosaari:
>>>>> On 12/10/2012 09:24 PM, Frank Schäfer wrote:
>>>>>> Am 10.12.2012 18:57, schrieb Antti Palosaari:
>>>>>> Specification comes here:
>>>>>> NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
>>>>>>
>>>>>> 1) 16bit NEC standard, 1 byte address code, 1 byte key code
>>>>>> full 4 byte code: AA BB CC DD
>>>>>> where:
>>>>>> AA = address code
>>>>>> BB = ~address code
>>>>>> CC = key code
>>>>>> DD = ~key code
>>>>>>
>>>>>> checksum:
>>>>>> AA + BB = 0xff
>>>>>> CC + DD = 0xff
>>>>>>
>>>>>> 2) 24bit NEC extended, 2 byte address code, 1 byte key code
>>>>>> full 4 byte code: AA BB CC DD
>>>>>> where:
>>>>>> AA = address code (MSB)
>>>>>> BB = address code (LSB)
>>>>>> CC = key code
>>>>>> DD = ~key code
>>>>>>
>>>>>> 3) 32bit NEC full, 4 byte key code
>>>>>> full 4 byte code: AA BB CC DD
>>>>>> where:
>>>>>> AA =
>>>>>> BB =
>>>>>> CC =
>>>>>> DD =
>>>>>>
>>>>>> I am not sure if there is separate parts for address and key code in
>>>>>> case of 32bit NEC. See some existing remote keytables if there is any
>>>>>> such table. It is very rare protocol. 1) and 2) are much more common.
>>>>>>
>>>> Many thanks.
>>>> So the problem is, that we have only a single RC_TYPE for all 3 protocol
>>>> variants and need a method to distinguish between them, right ?
>> This is not actually needed, as it is very easy to distinguish them when
>> doing the table lookups. Take a look at v4l-utils, at /utils/keytable/rc_keymaps:
>>
>> A 16-bits NEC table:
>> 	# table kworld_315u, type: NEC
>> 	0x6143 KEY_POWER
>> 	0x6101 KEY_VIDEO
>> 	...
>
> So 0x6143 is not the same as 0x006143 and 0x00006143 ???
>
> And even when assuming that 00 bytes are unused: do you really think the
> driver should parse the whole rc map and check all scancodes to find out
> which sub-protocol is used ?
>
>
>> A 24-bits NEC table:
>> 	# table pixelview_002t, type: NEC
>> 	0x866b13 KEY_MUTE
>> 	0x866b12 KEY_POWER2
>> 	...
>>
>> A 32-bits NEC table:
>> 	# table tivo, type: NEC
>> 	0xa10c900f KEY_MEDIA
>> 	0xa10c0807 KEY_POWER2
>> 	...
>>
>> If you see there, there's no way for the Kernel to handle it wrong, as
>> there's an implicit rule when dealing with "extended NEC" protocols:
>>
>> Being the IR code being given by: AA BB CC DD
>>
>> On a 24-bit NEC table: AA is always different than ~BB, otherwise, it would
>> be a 16-bit NEC.
>
> No, if AA != ~BB it can't be 16 bit, but if AA == ~BB, it can still be
> 16, 24 or 32bit !
>
>> On a 32-bit NEC table: CC is always different than ~DD, otherwise, it would be
>> a 24-bit NEC.
>
> Right, if CC != ~DD it must be 32 bit.
>
>
> So what if we get 52 AD 76 89 from the hardware ? This can be 32, 24 or
> 16 bit !
>
>
> Anyway, first we have to GET the bytes from the hardware. That's our
> current problem !
> And the hardware seems to need a different setup for reg 0x50 for the
> different NEC sub protocols.
> Which means that the we need to know the sub protocol BEFORE we get any
> bytes from the device.

I don't understand you. As to prove this possible, I made simple test. 
Patch attached.

Tested with two devices, em2884 and em28174. Here are the results:

rc-anysee.c:	{ 0x0800, KEY_0 },
em28xx_rc: 81 08 f7 01 fe

em28xx_rc: 01 02 bd 00 ff
rc-terratec-slim.c:	{ 0x02bd09, KEY_0 },

for my eyes the results, output from the hardware, is just what we want.


I will not change my opinion until you prove I made some mistake and it 
could not work. This is just similar what goes to af9015 and could be 
implemented similarly in order to make it general NEC IR receiver.

RC-core stupid key binding with all the variants is another stupid issue 
which should be fixed by converting all the key maps to 32bit format and 
use only it. IMHO.

regards
Antti

-- 
http://palosaari.fi/

[-- Attachment #2: em28xx_32bit_nec.patch --]
[-- Type: text/x-patch, Size: 1072 bytes --]

diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
index 660bf80..d26c5f7 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -257,6 +257,8 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
 	 */
 	rc = dev->em28xx_read_reg_req_len(dev, 0, EM2874_R51_IR,
 					  msg, sizeof(msg));
+
+	pr_info("%s: %*ph\n", KBUILD_MODNAME, 5, &msg);
 	if (rc < 0)
 		return rc;
 
@@ -352,6 +354,8 @@ static int em28xx_ir_change_protocol(struct rc_dev *rc_dev, u64 *rc_type)
 	struct em28xx *dev = ir->dev;
 	u8 ir_config = EM2874_IR_RC5;
 
+	*rc_type = RC_BIT_NEC;
+
 	/* Adjust xclk based o IR table for RC5/NEC tables */
 
 	if (*rc_type & RC_BIT_RC5) {
@@ -369,6 +373,8 @@ static int em28xx_ir_change_protocol(struct rc_dev *rc_dev, u64 *rc_type)
 	em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev->board.xclk,
 			      EM28XX_XCLK_IR_RC5_MODE);
 
+	ir_config = 0x01; // 32bit NEC
+
 	/* Setup the proper handler based on the chip */
 	switch (dev->chip_id) {
 	case CHIP_ID_EM2860:

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/14/2012 06:32 PM, Antti Palosaari wrote:
> On 12/14/2012 05:33 PM, Frank Schäfer wrote:
>> Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
>>> Em Tue, 11 Dec 2012 22:59:06 +0200
>>> Antti Palosaari <crope@iki.fi> escreveu:
>>>
>>>> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
>>>>> Am 10.12.2012 21:48, schrieb Antti Palosaari:
>>>>>> On 12/10/2012 09:24 PM, Frank Schäfer wrote:
>>>>>>> Am 10.12.2012 18:57, schrieb Antti Palosaari:
>>>>>>> Specification comes here:
>>>>>>> NEC send always 32 bit, 4 bytes. There is 3 different "sub"
>>>>>>> protocols:
>>>>>>>
>>>>>>> 1) 16bit NEC standard, 1 byte address code, 1 byte key code
>>>>>>> full 4 byte code: AA BB CC DD
>>>>>>> where:
>>>>>>> AA = address code
>>>>>>> BB = ~address code
>>>>>>> CC = key code
>>>>>>> DD = ~key code
>>>>>>>
>>>>>>> checksum:
>>>>>>> AA + BB = 0xff
>>>>>>> CC + DD = 0xff
>>>>>>>
>>>>>>> 2) 24bit NEC extended, 2 byte address code, 1 byte key code
>>>>>>> full 4 byte code: AA BB CC DD
>>>>>>> where:
>>>>>>> AA = address code (MSB)
>>>>>>> BB = address code (LSB)
>>>>>>> CC = key code
>>>>>>> DD = ~key code
>>>>>>>
>>>>>>> 3) 32bit NEC full, 4 byte key code
>>>>>>> full 4 byte code: AA BB CC DD
>>>>>>> where:
>>>>>>> AA =
>>>>>>> BB =
>>>>>>> CC =
>>>>>>> DD =
>>>>>>>
>>>>>>> I am not sure if there is separate parts for address and key code in
>>>>>>> case of 32bit NEC. See some existing remote keytables if there is
>>>>>>> any
>>>>>>> such table. It is very rare protocol. 1) and 2) are much more
>>>>>>> common.
>>>>>>>
>>>>> Many thanks.
>>>>> So the problem is, that we have only a single RC_TYPE for all 3
>>>>> protocol
>>>>> variants and need a method to distinguish between them, right ?
>>> This is not actually needed, as it is very easy to distinguish them when
>>> doing the table lookups. Take a look at v4l-utils, at
>>> /utils/keytable/rc_keymaps:
>>>
>>> A 16-bits NEC table:
>>>     # table kworld_315u, type: NEC
>>>     0x6143 KEY_POWER
>>>     0x6101 KEY_VIDEO
>>>     ...
>>
>> So 0x6143 is not the same as 0x006143 and 0x00006143 ???
>>
>> And even when assuming that 00 bytes are unused: do you really think the
>> driver should parse the whole rc map and check all scancodes to find out
>> which sub-protocol is used ?
>>
>>
>>> A 24-bits NEC table:
>>>     # table pixelview_002t, type: NEC
>>>     0x866b13 KEY_MUTE
>>>     0x866b12 KEY_POWER2
>>>     ...
>>>
>>> A 32-bits NEC table:
>>>     # table tivo, type: NEC
>>>     0xa10c900f KEY_MEDIA
>>>     0xa10c0807 KEY_POWER2
>>>     ...
>>>
>>> If you see there, there's no way for the Kernel to handle it wrong, as
>>> there's an implicit rule when dealing with "extended NEC" protocols:
>>>
>>> Being the IR code being given by: AA BB CC DD
>>>
>>> On a 24-bit NEC table: AA is always different than ~BB, otherwise, it
>>> would
>>> be a 16-bit NEC.
>>
>> No, if AA != ~BB it can't be 16 bit, but if AA == ~BB, it can still be
>> 16, 24 or 32bit !
>>
>>> On a 32-bit NEC table: CC is always different than ~DD, otherwise, it
>>> would be
>>> a 24-bit NEC.
>>
>> Right, if CC != ~DD it must be 32 bit.
>>
>>
>> So what if we get 52 AD 76 89 from the hardware ? This can be 32, 24 or
>> 16 bit !
>>
>>
>> Anyway, first we have to GET the bytes from the hardware. That's our
>> current problem !
>> And the hardware seems to need a different setup for reg 0x50 for the
>> different NEC sub protocols.
>> Which means that the we need to know the sub protocol BEFORE we get any
>> bytes from the device.
>
> I don't understand you. As to prove this possible, I made simple test.
> Patch attached.
>
> Tested with two devices, em2884 and em28174. Here are the results:
>
> rc-anysee.c:    { 0x0800, KEY_0 },
> em28xx_rc: 81 08 f7 01 fe
>
> em28xx_rc: 01 02 bd 00 ff
> rc-terratec-slim.c:    { 0x02bd09, KEY_0 },

Ooops, I copy&pasted wrong buttons, key 1 as key 0 was taken from the 
maps. Here is correct debug outputs matching given key maps.

em28xx_rc: 81 08 f7 00 ff
em28xx_rc: 01 02 bd 09 f6

>
> for my eyes the results, output from the hardware, is just what we want.
>
>
> I will not change my opinion until you prove I made some mistake and it
> could not work. This is just similar what goes to af9015 and could be
> implemented similarly in order to make it general NEC IR receiver.
>
> RC-core stupid key binding with all the variants is another stupid issue
> which should be fixed by converting all the key maps to 32bit format and
> use only it. IMHO.
>
> regards
> Antti
>


-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Fri, 14 Dec 2012 16:33:34 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
> > Em Tue, 11 Dec 2012 22:59:06 +0200
> > Antti Palosaari <crope@iki.fi> escreveu:
> >
> >> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
> >>> Am 10.12.2012 21:48, schrieb Antti Palosaari:
> >>>> On 12/10/2012 09:24 PM, Frank Schäfer wrote:
> >>>>> Am 10.12.2012 18:57, schrieb Antti Palosaari:
> >>>>> Specification comes here:
> >>>>> NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
> >>>>>
> >>>>> 1) 16bit NEC standard, 1 byte address code, 1 byte key code
> >>>>> full 4 byte code: AA BB CC DD
> >>>>> where:
> >>>>> AA = address code
> >>>>> BB = ~address code
> >>>>> CC = key code
> >>>>> DD = ~key code
> >>>>>
> >>>>> checksum:
> >>>>> AA + BB = 0xff
> >>>>> CC + DD = 0xff
> >>>>>
> >>>>> 2) 24bit NEC extended, 2 byte address code, 1 byte key code
> >>>>> full 4 byte code: AA BB CC DD
> >>>>> where:
> >>>>> AA = address code (MSB)
> >>>>> BB = address code (LSB)
> >>>>> CC = key code
> >>>>> DD = ~key code
> >>>>>
> >>>>> 3) 32bit NEC full, 4 byte key code
> >>>>> full 4 byte code: AA BB CC DD
> >>>>> where:
> >>>>> AA =
> >>>>> BB =
> >>>>> CC =
> >>>>> DD =
> >>>>>
> >>>>> I am not sure if there is separate parts for address and key code in
> >>>>> case of 32bit NEC. See some existing remote keytables if there is any
> >>>>> such table. It is very rare protocol. 1) and 2) are much more common.
> >>>>>
> >>> Many thanks.
> >>> So the problem is, that we have only a single RC_TYPE for all 3 protocol
> >>> variants and need a method to distinguish between them, right ?
> > This is not actually needed, as it is very easy to distinguish them when
> > doing the table lookups. Take a look at v4l-utils, at /utils/keytable/rc_keymaps:
> >
> > A 16-bits NEC table:
> > 	# table kworld_315u, type: NEC
> > 	0x6143 KEY_POWER
> > 	0x6101 KEY_VIDEO
> > 	...
> 
> So 0x6143 is not the same as 0x006143 and 0x00006143 ???
> 
> And even when assuming that 00 bytes are unused: 

I never seen that.

> do you really think the
> driver should parse the whole rc map and check all scancodes to find out
> which sub-protocol is used ?

Scancode search can use a b-tree (I think it currently does).

In any case, the typical usage is that the IR table will match the
IR device in usage. So, a not-found scancode just means that some
error happened during the transmission.

> > On a 24-bit NEC table: AA is always different than ~BB, otherwise, it would
> > be a 16-bit NEC.
> 
> No, if AA != ~BB it can't be 16 bit, but if AA == ~BB, it can still be
> 16, 24 or 32bit !

Have you ever seen any remote using something like that??? 

The hole point of the IR address is to distinguish a given IR device from the
others. The specs define specific addresses for VCR, TV Set, DVD, etc.

So, no, if AA == ~BB it must be a 16 or 24 bits NEC protocol, as there's just 8
bits (or 16 bits) to differentiate the IR address for a given remote 
from other NEC IR addresses.

> > On a 32-bit NEC table: CC is always different than ~DD, otherwise, it would be
> > a 24-bit NEC.
> 
> Right, if CC != ~DD it must be 32 bit.
> 
> 
> So what if we get 52 AD 76 89 from the hardware ? This can be 32, 24 or
> 16 bit !

It is 16 bits, except if someone at the manufacturer is completely
senseless, and explicitly wants to cause troubles to their customers
by using an IR address and IR commands that could be produced by
some other vendor's remotes.

In any case, the RC core will still support such crappy device, as the
IR keytable can have a mix of 16 bits/24 bits/32 bits NEC codes inside
it.

We do have some tables with multiple IR's inside. For example, the
Hauppauge RC5 table contains keycodes for 3 different types of Hauppauge
controls. The same happens to one NEC's terratec table, where we're
storing there both the codes of different IR models.

The rationale is that the same board may be sold with different remotes.

> Anyway, first we have to GET the bytes from the hardware. That's our
> current problem !
> And the hardware seems to need a different setup for reg 0x50 for the
> different NEC sub protocols.
> Which means that the we need to know the sub protocol BEFORE we get any
> bytes from the device.

No. All em28xx needs is to make sure that the NEC protocol will return
the full 32 bits scancode.

Regards,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> > Anyway, first we have to GET the bytes from the hardware. That's our
> > current problem !
> > And the hardware seems to need a different setup for reg 0x50 for the
> > different NEC sub protocols.
> > Which means that the we need to know the sub protocol BEFORE we get any
> > bytes from the device.
> 
> No. All em28xx needs is to make sure that the NEC protocol will return
> the full 32 bits scancode.

It seems a way easier/quicker to just add the proper support there at the
driver than keep answering to this thread ;)

Tested here with a Terratec HTC stick, and using two different IR's:
	- a Terratec IR (address code 0x14 - standard NEC);
	- a Pixelview IR (address code 0x866b - 24 bits NEC).

All tests were done with the very latest version of ir-keytable, found at
v4l-utils.git tree (http://git.linuxtv.org/v4l-utils.git).

See the results, with the Terratec table loaded (default when the
driver is loaded):

	# ir-keytable -t 
	Testing events. Please, press CTRL-C to abort.
		# Terratec IR
	1355529698.198046: event type EV_MSC(0x04): scancode = 0x1402
	1355529698.198046: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
	1355529698.198046: event type EV_SYN(0x00).
	11355529698.298170: event type EV_MSC(0x04): scancode = 0x1402
	1355529698.298170: event type EV_SYN(0x00).
	1355529698.547998: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
	1355529698.547998: event type EV_SYN(0x00).
		# Pixelview IR
	1355530261.416415: event type EV_MSC(0x04): scancode = 0x866b01
	1355530261.416415: event type EV_SYN(0x00).
	1355530262.216301: event type EV_MSC(0x04): scancode = 0x866b0b
	1355530262.216301: event type EV_SYN(0x00).

Replacing the keytable to the Pixelview's one:

	# ir-keytable -w /etc/rc_keymaps/pixelview_002t -c
	Read pixelview_002t table
	Old keytable cleared
	Wrote 26 keycode(s) to driver
	Protocols changed to NEC 

	# ir-keytable -t 
	Testing events. Please, press CTRL-C to abort.
	1355530569.420398: event type EV_MSC(0x04): scancode = 0x1402
	1355530569.420398: event type EV_SYN(0x00).
	1355530588.120409: event type EV_MSC(0x04): scancode = 0x866b01
	1355530588.120409: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
	1355530591.670077: event type EV_SYN(0x00).

And, finally, keeping both keytables active at the same time:

	# ir-keytable -c -w /etc/rc_keymaps/pixelview_002t -w /etc/rc_keymaps/nec_terratec_cinergy_xs 
	Read pixelview_002t table
	Read nec_terratec_cinergy_xs table
	Old keytable cleared
	Wrote 74 keycode(s) to driver
	Protocols changed to NEC 

	# sudo ir-keytable  -t 
	Testing events. Please, press CTRL-C to abort.
	1355530856.325201: event type EV_MSC(0x04): scancode = 0x866b01
	1355530856.325201: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
	1355530856.325201: event type EV_SYN(0x00).
	11355530856.575070: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
	1355530856.575070: event type EV_SYN(0x00).
	1355530869.125226: event type EV_MSC(0x04): scancode = 0x1402
	1355530869.125226: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
	1355530869.125226: event type EV_SYN(0x00).
	11355530869.225216: event type EV_MSC(0x04): scancode = 0x1402
	1355530869.225216: event type EV_SYN(0x00).
	1355530869.475075: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
	1355530869.475075: event type EV_SYN(0x00).

-

em28xx: add support for 24bits/32 bits NEC variants on em2874 and upper

By disabling the NEC parity check, it is possible to handle all 3 NEC
protocol variants (32, 24 or 16 bits).

Change the driver in order to handle all of them.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
index 97d36b4..c84e4c8 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -57,8 +57,8 @@ MODULE_PARM_DESC(ir_debug, "enable debug messages [IR]");
 struct em28xx_ir_poll_result {
 	unsigned int toggle_bit:1;
 	unsigned int read_count:7;
-	u8 rc_address;
-	u8 rc_data[4]; /* 1 byte on em2860/2880, 4 on em2874 */
+
+	u32 scancode;
 };
 
 struct em28xx_IR {
@@ -72,6 +72,7 @@ struct em28xx_IR {
 	struct delayed_work work;
 	unsigned int full_code:1;
 	unsigned int last_readcount;
+	u64 rc_type;
 
 	int  (*get_key)(struct em28xx_IR *, struct em28xx_ir_poll_result *);
 };
@@ -236,11 +237,8 @@ static int default_polling_getkey(struct em28xx_IR *ir,
 	/* Infrared read count (Reg 0x45[6:0] */
 	poll_result->read_count = (msg[0] & 0x7f);
 
-	/* Remote Control Address (Reg 0x46) */
-	poll_result->rc_address = msg[1];
-
-	/* Remote Control Data (Reg 0x47) */
-	poll_result->rc_data[0] = msg[2];
+	/* Remote Control Address/Data (Regs 0x46/0x47) */
+	poll_result->scancode = msg[1] << 8 | msg[2];
 
 	return 0;
 }
@@ -266,13 +264,30 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
 	/* Infrared read count (Reg 0x51[6:0] */
 	poll_result->read_count = (msg[0] & 0x7f);
 
-	/* Remote Control Address (Reg 0x52) */
-	poll_result->rc_address = msg[1];
-
-	/* Remote Control Data (Reg 0x53-55) */
-	poll_result->rc_data[0] = msg[2];
-	poll_result->rc_data[1] = msg[3];
-	poll_result->rc_data[2] = msg[4];
+		/* Remote Control Address (Reg 0x52) */
+		/* Remote Control Data (Reg 0x53-0x55) */
+	switch (ir->rc_type) {
+	case RC_TYPE_RC5:
+		poll_result->scancode = msg[1] << 8 | msg[2];
+		break;
+	case RC_TYPE_NEC:
+		if ((msg[3] ^ msg[4]) != 0xff) 		/* 32 bits NEC */
+			poll_result->scancode = (msg[1] << 24) |
+						(msg[2] << 16) |
+						(msg[3] << 8)  |
+						 msg[4];
+		else if ((msg[1] ^ msg[2]) != 0xff)	/* 24 bits NEC */
+			poll_result->scancode = (msg[1] << 16) |
+						(msg[3] << 8)  |
+						 msg[4];
+		else					/* Normal NEC */
+			poll_result->scancode = msg[1] << 8 | msg[3];
+		break;
+	default:
+		poll_result->scancode = (msg[1] << 24) | (msg[2] << 16) |
+					(msg[3] << 8)  | msg[4];
+		break;
+	}
 
 	return 0;
 }
@@ -294,17 +309,16 @@ static void em28xx_ir_handle_key(struct em28xx_IR *ir)
 	}
 
 	if (unlikely(poll_result.read_count != ir->last_readcount)) {
-		dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
+		dprintk("%s: toggle: %d, count: %d, key 0x%04x\n", __func__,
 			poll_result.toggle_bit, poll_result.read_count,
-			poll_result.rc_address, poll_result.rc_data[0]);
+			poll_result.scancode);
 		if (ir->full_code)
 			rc_keydown(ir->rc,
-				   poll_result.rc_address << 8 |
-				   poll_result.rc_data[0],
+				   poll_result.scancode,
 				   poll_result.toggle_bit);
 		else
 			rc_keydown(ir->rc,
-				   poll_result.rc_data[0],
+				   poll_result.scancode & 0xff,
 				   poll_result.toggle_bit);
 
 		if (ir->dev->chip_id == CHIP_ID_EM2874 ||
@@ -359,11 +373,13 @@ static int em28xx_ir_change_protocol(struct rc_dev *rc_dev, u64 rc_type)
 		ir->full_code = 1;
 	} else if (rc_type == RC_TYPE_NEC) {
 		dev->board.xclk &= ~EM28XX_XCLK_IR_RC5_MODE;
-		ir_config = EM2874_IR_NEC;
+		ir_config = EM2874_IR_NEC | EM2874_IR_NEC_NO_PARITY;
 		ir->full_code = 1;
 	} else if (rc_type != RC_TYPE_UNKNOWN)
 		rc = -EINVAL;
 
+	ir->rc_type = rc_type;
+
 	em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev->board.xclk,
 			      EM28XX_XCLK_IR_RC5_MODE);
 
diff --git a/drivers/media/usb/em28xx/em28xx-reg.h b/drivers/media/usb/em28xx/em28xx-reg.h
index 6ff3682..2ad3573 100644
--- a/drivers/media/usb/em28xx/em28xx-reg.h
+++ b/drivers/media/usb/em28xx/em28xx-reg.h
@@ -177,6 +177,7 @@
 
 /* em2874 IR config register (0x50) */
 #define EM2874_IR_NEC           0x00
+#define EM2874_IR_NEC_NO_PARITY 0x01
 #define EM2874_IR_RC5           0x04
 #define EM2874_IR_RC6_MODE_0    0x08
 #define EM2874_IR_RC6_MODE_6A   0x0b

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Fri, 14 Dec 2012 22:26:31 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> Em Fri, 14 Dec 2012 17:39:50 -0200
> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> 
> > > Anyway, first we have to GET the bytes from the hardware. That's our
> > > current problem !
> > > And the hardware seems to need a different setup for reg 0x50 for the
> > > different NEC sub protocols.
> > > Which means that the we need to know the sub protocol BEFORE we get any
> > > bytes from the device.
> > 
> > No. All em28xx needs is to make sure that the NEC protocol will return
> > the full 32 bits scancode.
> 
> It seems a way easier/quicker to just add the proper support there at the
> driver than keep answering to this thread ;)
> 
> Tested here with a Terratec HTC stick, and using two different IR's:
> 	- a Terratec IR (address code 0x14 - standard NEC);
> 	- a Pixelview IR (address code 0x866b - 24 bits NEC).

Just in case, I tested also that RC5 keeps working, by using a
Hauppauge grey control:

	# ir-keytable  -c -w /etc/rc_keymaps/hauppauge 
	Read hauppauge table
	Old keytable cleared
	Wrote 136 keycode(s) to driver
	Protocols changed to RC-5 

	# sudo ir-keytable  -t 
	Testing events. Please, press CTRL-C to abort.
	1355531445.443208: event type EV_MSC(0x04): scancode = 0x1e02
	1355531445.443208: event type EV_KEY(0x01) key_down: KEY_2(0x0001)
	1355531445.443208: event type EV_SYN(0x00).
	21355531445.543207: event type EV_MSC(0x04): scancode = 0x1e02
	1355531445.543207: event type EV_SYN(0x00).
	1355531445.793072: event type EV_KEY(0x01) key_up: KEY_2(0x0001)
	1355531445.793072: event type EV_SYN(0x00).
	1355531446.643224: event type EV_MSC(0x04): scancode = 0x1e02
	1355531446.643224: event type EV_KEY(0x01) key_down: KEY_2(0x0001)
	1355531446.643224: event type EV_SYN(0x00).
	21355531446.743205: event type EV_MSC(0x04): scancode = 0x1e02
	1355531446.743205: event type EV_SYN(0x00).


Cheers,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
> Em Fri, 14 Dec 2012 17:39:50 -0200
> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
>
>>> Anyway, first we have to GET the bytes from the hardware. That's our
>>> current problem !
>>> And the hardware seems to need a different setup for reg 0x50 for the
>>> different NEC sub protocols.
>>> Which means that the we need to know the sub protocol BEFORE we get any
>>> bytes from the device.
>>
>> No. All em28xx needs is to make sure that the NEC protocol will return
>> the full 32 bits scancode.
>
> It seems a way easier/quicker to just add the proper support there at the
> driver than keep answering to this thread ;)
>
> Tested here with a Terratec HTC stick, and using two different IR's:
> 	- a Terratec IR (address code 0x14 - standard NEC);
> 	- a Pixelview IR (address code 0x866b - 24 bits NEC).
>
> All tests were done with the very latest version of ir-keytable, found at
> v4l-utils.git tree (http://git.linuxtv.org/v4l-utils.git).
>
> See the results, with the Terratec table loaded (default when the
> driver is loaded):
>
> 	# ir-keytable -t
> 	Testing events. Please, press CTRL-C to abort.
> 		# Terratec IR
> 	1355529698.198046: event type EV_MSC(0x04): scancode = 0x1402
> 	1355529698.198046: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
> 	1355529698.198046: event type EV_SYN(0x00).
> 	11355529698.298170: event type EV_MSC(0x04): scancode = 0x1402
> 	1355529698.298170: event type EV_SYN(0x00).
> 	1355529698.547998: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
> 	1355529698.547998: event type EV_SYN(0x00).
> 		# Pixelview IR
> 	1355530261.416415: event type EV_MSC(0x04): scancode = 0x866b01
> 	1355530261.416415: event type EV_SYN(0x00).
> 	1355530262.216301: event type EV_MSC(0x04): scancode = 0x866b0b
> 	1355530262.216301: event type EV_SYN(0x00).
>
> Replacing the keytable to the Pixelview's one:
>
> 	# ir-keytable -w /etc/rc_keymaps/pixelview_002t -c
> 	Read pixelview_002t table
> 	Old keytable cleared
> 	Wrote 26 keycode(s) to driver
> 	Protocols changed to NEC
>
> 	# ir-keytable -t
> 	Testing events. Please, press CTRL-C to abort.
> 	1355530569.420398: event type EV_MSC(0x04): scancode = 0x1402
> 	1355530569.420398: event type EV_SYN(0x00).
> 	1355530588.120409: event type EV_MSC(0x04): scancode = 0x866b01
> 	1355530588.120409: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
> 	1355530591.670077: event type EV_SYN(0x00).
>
> And, finally, keeping both keytables active at the same time:
>
> 	# ir-keytable -c -w /etc/rc_keymaps/pixelview_002t -w /etc/rc_keymaps/nec_terratec_cinergy_xs
> 	Read pixelview_002t table
> 	Read nec_terratec_cinergy_xs table
> 	Old keytable cleared
> 	Wrote 74 keycode(s) to driver
> 	Protocols changed to NEC
>
> 	# sudo ir-keytable  -t
> 	Testing events. Please, press CTRL-C to abort.
> 	1355530856.325201: event type EV_MSC(0x04): scancode = 0x866b01
> 	1355530856.325201: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
> 	1355530856.325201: event type EV_SYN(0x00).
> 	11355530856.575070: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
> 	1355530856.575070: event type EV_SYN(0x00).
> 	1355530869.125226: event type EV_MSC(0x04): scancode = 0x1402
> 	1355530869.125226: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
> 	1355530869.125226: event type EV_SYN(0x00).
> 	11355530869.225216: event type EV_MSC(0x04): scancode = 0x1402
> 	1355530869.225216: event type EV_SYN(0x00).
> 	1355530869.475075: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
> 	1355530869.475075: event type EV_SYN(0x00).
>
> -
>
> em28xx: add support for 24bits/32 bits NEC variants on em2874 and upper
>
> By disabling the NEC parity check, it is possible to handle all 3 NEC
> protocol variants (32, 24 or 16 bits).
>
> Change the driver in order to handle all of them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>





NACK. NEC variant selection logic is broken by design.





>
> diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
> index 97d36b4..c84e4c8 100644
> --- a/drivers/media/usb/em28xx/em28xx-input.c
> +++ b/drivers/media/usb/em28xx/em28xx-input.c
> @@ -57,8 +57,8 @@ MODULE_PARM_DESC(ir_debug, "enable debug messages [IR]");
>   struct em28xx_ir_poll_result {
>   	unsigned int toggle_bit:1;
>   	unsigned int read_count:7;
> -	u8 rc_address;
> -	u8 rc_data[4]; /* 1 byte on em2860/2880, 4 on em2874 */
> +
> +	u32 scancode;
>   };
>
>   struct em28xx_IR {
> @@ -72,6 +72,7 @@ struct em28xx_IR {
>   	struct delayed_work work;
>   	unsigned int full_code:1;
>   	unsigned int last_readcount;
> +	u64 rc_type;
>
>   	int  (*get_key)(struct em28xx_IR *, struct em28xx_ir_poll_result *);
>   };
> @@ -236,11 +237,8 @@ static int default_polling_getkey(struct em28xx_IR *ir,
>   	/* Infrared read count (Reg 0x45[6:0] */
>   	poll_result->read_count = (msg[0] & 0x7f);
>
> -	/* Remote Control Address (Reg 0x46) */
> -	poll_result->rc_address = msg[1];
> -
> -	/* Remote Control Data (Reg 0x47) */
> -	poll_result->rc_data[0] = msg[2];
> +	/* Remote Control Address/Data (Regs 0x46/0x47) */
> +	poll_result->scancode = msg[1] << 8 | msg[2];
>
>   	return 0;
>   }
> @@ -266,13 +264,30 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
>   	/* Infrared read count (Reg 0x51[6:0] */
>   	poll_result->read_count = (msg[0] & 0x7f);
>
> -	/* Remote Control Address (Reg 0x52) */
> -	poll_result->rc_address = msg[1];
> -
> -	/* Remote Control Data (Reg 0x53-55) */
> -	poll_result->rc_data[0] = msg[2];
> -	poll_result->rc_data[1] = msg[3];
> -	poll_result->rc_data[2] = msg[4];
> +		/* Remote Control Address (Reg 0x52) */
> +		/* Remote Control Data (Reg 0x53-0x55) */
> +	switch (ir->rc_type) {
> +	case RC_TYPE_RC5:
> +		poll_result->scancode = msg[1] << 8 | msg[2];
> +		break;
> +	case RC_TYPE_NEC:
> +		if ((msg[3] ^ msg[4]) != 0xff) 		/* 32 bits NEC */

See for example KEY_CYCLEWINDOWS from RC_MAP_TIVO. Do you think it 
works..... :-(

> +			poll_result->scancode = (msg[1] << 24) |
> +						(msg[2] << 16) |
> +						(msg[3] << 8)  |
> +						 msg[4];
> +		else if ((msg[1] ^ msg[2]) != 0xff)	/* 24 bits NEC */
> +			poll_result->scancode = (msg[1] << 16) |
> +						(msg[3] << 8)  |
> +						 msg[4];
> +		else					/* Normal NEC */
> +			poll_result->scancode = msg[1] << 8 | msg[3];
> +		break;
> +	default:
> +		poll_result->scancode = (msg[1] << 24) | (msg[2] << 16) |
> +					(msg[3] << 8)  | msg[4];
> +		break;
> +	}
>
>   	return 0;
>   }
> @@ -294,17 +309,16 @@ static void em28xx_ir_handle_key(struct em28xx_IR *ir)
>   	}
>
>   	if (unlikely(poll_result.read_count != ir->last_readcount)) {
> -		dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
> +		dprintk("%s: toggle: %d, count: %d, key 0x%04x\n", __func__,
>   			poll_result.toggle_bit, poll_result.read_count,
> -			poll_result.rc_address, poll_result.rc_data[0]);
> +			poll_result.scancode);
>   		if (ir->full_code)
>   			rc_keydown(ir->rc,
> -				   poll_result.rc_address << 8 |
> -				   poll_result.rc_data[0],
> +				   poll_result.scancode,
>   				   poll_result.toggle_bit);
>   		else
>   			rc_keydown(ir->rc,
> -				   poll_result.rc_data[0],
> +				   poll_result.scancode & 0xff,
>   				   poll_result.toggle_bit);
>
>   		if (ir->dev->chip_id == CHIP_ID_EM2874 ||
> @@ -359,11 +373,13 @@ static int em28xx_ir_change_protocol(struct rc_dev *rc_dev, u64 rc_type)
>   		ir->full_code = 1;
>   	} else if (rc_type == RC_TYPE_NEC) {
>   		dev->board.xclk &= ~EM28XX_XCLK_IR_RC5_MODE;
> -		ir_config = EM2874_IR_NEC;
> +		ir_config = EM2874_IR_NEC | EM2874_IR_NEC_NO_PARITY;
>   		ir->full_code = 1;
>   	} else if (rc_type != RC_TYPE_UNKNOWN)
>   		rc = -EINVAL;
>
> +	ir->rc_type = rc_type;
> +
>   	em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev->board.xclk,
>   			      EM28XX_XCLK_IR_RC5_MODE);
>
> diff --git a/drivers/media/usb/em28xx/em28xx-reg.h b/drivers/media/usb/em28xx/em28xx-reg.h
> index 6ff3682..2ad3573 100644
> --- a/drivers/media/usb/em28xx/em28xx-reg.h
> +++ b/drivers/media/usb/em28xx/em28xx-reg.h
> @@ -177,6 +177,7 @@
>
>   /* em2874 IR config register (0x50) */
>   #define EM2874_IR_NEC           0x00
> +#define EM2874_IR_NEC_NO_PARITY 0x01
>   #define EM2874_IR_RC5           0x04
>   #define EM2874_IR_RC6_MODE_0    0x08
>   #define EM2874_IR_RC6_MODE_6A   0x0b
>


OK, it is much better and I can even see that in Kernel than keeping 
old, very limited implementation.

My aim was just to probe whole variant selection method is quite broken, 
and it is impossible to get working with 100% reliable. As I have said 
loudly :) , I want 32bit scancodes for all NEC remotes, no variants at 
all. I think you are about the only person who wants to keep current 
multiple NEC variant implementation...


regards
Antti


-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> NACK. NEC variant selection logic is broken by design.

If you think so, then feel free to fix it without causing regressions to
the existing userspace.

While you don't do it, I don't see anything wrong on this patch, as it
will behave just like any other NEC decoder.

Cheers,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote:
> Em Sat, 15 Dec 2012 02:56:25 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> NACK. NEC variant selection logic is broken by design.
>
> If you think so, then feel free to fix it without causing regressions to
> the existing userspace.
>
> While you don't do it, I don't see anything wrong on this patch, as it
> will behave just like any other NEC decoder.

yes, so true as I mentioned end of the mail. But it is very high 
probability there is some non/wrong working keys when 32bit NEC variant 
remote is used with that implementation.

And what happened those patches David sends sometime ago. I remember 
there was a patch for the af9015 which removes that kind of logic from 
the driver. If not change NEC to 32bit at least heuristic could be moved 
to single point - rc-core.

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Sat, 15 Dec 2012 03:12:58 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote:
> > Em Sat, 15 Dec 2012 02:56:25 +0200
> > Antti Palosaari <crope@iki.fi> escreveu:
> >
> >> NACK. NEC variant selection logic is broken by design.
> >
> > If you think so, then feel free to fix it without causing regressions to
> > the existing userspace.
> >
> > While you don't do it, I don't see anything wrong on this patch, as it
> > will behave just like any other NEC decoder.
> 
> yes, so true as I mentioned end of the mail.

Oh, I didn't saw your comments. Sorry.

Please, next time, drop the part of the code that you're not commenting.
On long emails like that, it is sometimes hard to see what's out there.

I'll reply to your comments there again.

> But it is very high 
> probability there is some non/wrong working keys when 32bit NEC variant 
> remote is used with that implementation.
> 
> And what happened those patches David sends sometime ago. I remember 
> there was a patch for the af9015 which removes that kind of logic from 
> the driver. If not change NEC to 32bit at least heuristic could be moved 
> to single point - rc-core.

There were some problems on his series, and it was breaking the userspace
API.

David made a new series, with a smaller set of patches that got applied,
without those changes.

The big issue there is to not break the current NEC userspace tables.

Unfortunately, when the NEC software decoder was written, it were taking
care only of the real NEC standard (the 24-bits and 32-bits variants aren't
part of any spec I'm aware of). When we latter added support for those
weird variants (RC-5 variants; Sony variants; NEC variants), it was
decided, after long debates at the mailing list, to not create a new 
protocol for each, but, instead, to add support for them into the existing 
code.

This is OK on most cases, as the variants are real variants, and the decoder
can properly distinguish them.

Unfortunately, NEC protocol variants don't fill on such case, as the only
difference is that they doesn't honour to the checksum bytes. So, again
after long discussions, it was decided to implement it the way it is.

Changing it right now is not trivial, as it is easy to break existing
userspace.

Regards,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
> > Em Fri, 14 Dec 2012 17:39:50 -0200
> > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> >
> >>> Anyway, first we have to GET the bytes from the hardware. That's our
> >>> current problem !
> >>> And the hardware seems to need a different setup for reg 0x50 for the
> >>> different NEC sub protocols.
> >>> Which means that the we need to know the sub protocol BEFORE we get any
> >>> bytes from the device.
> >>
> >> No. All em28xx needs is to make sure that the NEC protocol will return
> >> the full 32 bits scancode.
> >
> > It seems a way easier/quicker to just add the proper support there at the
> > driver than keep answering to this thread ;)
> >
> > Tested here with a Terratec HTC stick, and using two different IR's:
> > 	- a Terratec IR (address code 0x14 - standard NEC);
> > 	- a Pixelview IR (address code 0x866b - 24 bits NEC).
> >
> > All tests were done with the very latest version of ir-keytable, found at
> > v4l-utils.git tree (http://git.linuxtv.org/v4l-utils.git).
> >
> > See the results, with the Terratec table loaded (default when the
> > driver is loaded):
> >
> > 	# ir-keytable -t
> > 	Testing events. Please, press CTRL-C to abort.
> > 		# Terratec IR
> > 	1355529698.198046: event type EV_MSC(0x04): scancode = 0x1402
> > 	1355529698.198046: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
> > 	1355529698.198046: event type EV_SYN(0x00).
> > 	11355529698.298170: event type EV_MSC(0x04): scancode = 0x1402
> > 	1355529698.298170: event type EV_SYN(0x00).
> > 	1355529698.547998: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
> > 	1355529698.547998: event type EV_SYN(0x00).
> > 		# Pixelview IR
> > 	1355530261.416415: event type EV_MSC(0x04): scancode = 0x866b01
> > 	1355530261.416415: event type EV_SYN(0x00).
> > 	1355530262.216301: event type EV_MSC(0x04): scancode = 0x866b0b
> > 	1355530262.216301: event type EV_SYN(0x00).
> >
> > Replacing the keytable to the Pixelview's one:
> >
> > 	# ir-keytable -w /etc/rc_keymaps/pixelview_002t -c
> > 	Read pixelview_002t table
> > 	Old keytable cleared
> > 	Wrote 26 keycode(s) to driver
> > 	Protocols changed to NEC
> >
> > 	# ir-keytable -t
> > 	Testing events. Please, press CTRL-C to abort.
> > 	1355530569.420398: event type EV_MSC(0x04): scancode = 0x1402
> > 	1355530569.420398: event type EV_SYN(0x00).
> > 	1355530588.120409: event type EV_MSC(0x04): scancode = 0x866b01
> > 	1355530588.120409: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
> > 	1355530591.670077: event type EV_SYN(0x00).
> >
> > And, finally, keeping both keytables active at the same time:
> >
> > 	# ir-keytable -c -w /etc/rc_keymaps/pixelview_002t -w /etc/rc_keymaps/nec_terratec_cinergy_xs
> > 	Read pixelview_002t table
> > 	Read nec_terratec_cinergy_xs table
> > 	Old keytable cleared
> > 	Wrote 74 keycode(s) to driver
> > 	Protocols changed to NEC
> >
> > 	# sudo ir-keytable  -t
> > 	Testing events. Please, press CTRL-C to abort.
> > 	1355530856.325201: event type EV_MSC(0x04): scancode = 0x866b01
> > 	1355530856.325201: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
> > 	1355530856.325201: event type EV_SYN(0x00).
> > 	11355530856.575070: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
> > 	1355530856.575070: event type EV_SYN(0x00).
> > 	1355530869.125226: event type EV_MSC(0x04): scancode = 0x1402
> > 	1355530869.125226: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
> > 	1355530869.125226: event type EV_SYN(0x00).
> > 	11355530869.225216: event type EV_MSC(0x04): scancode = 0x1402
> > 	1355530869.225216: event type EV_SYN(0x00).
> > 	1355530869.475075: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
> > 	1355530869.475075: event type EV_SYN(0x00).
> >
> > -
> >
> > em28xx: add support for 24bits/32 bits NEC variants on em2874 and upper
> >
> > By disabling the NEC parity check, it is possible to handle all 3 NEC
> > protocol variants (32, 24 or 16 bits).
> >
> > Change the driver in order to handle all of them.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> 
> 
> 
> 
> NACK. NEC variant selection logic is broken by design.
> 
> 
> 
> 
> 
> >
> > diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
> > index 97d36b4..c84e4c8 100644
> > --- a/drivers/media/usb/em28xx/em28xx-input.c
> > +++ b/drivers/media/usb/em28xx/em28xx-input.c
> > @@ -57,8 +57,8 @@ MODULE_PARM_DESC(ir_debug, "enable debug messages [IR]");
> >   struct em28xx_ir_poll_result {
> >   	unsigned int toggle_bit:1;
> >   	unsigned int read_count:7;
> > -	u8 rc_address;
> > -	u8 rc_data[4]; /* 1 byte on em2860/2880, 4 on em2874 */
> > +
> > +	u32 scancode;
> >   };
> >
> >   struct em28xx_IR {
> > @@ -72,6 +72,7 @@ struct em28xx_IR {
> >   	struct delayed_work work;
> >   	unsigned int full_code:1;
> >   	unsigned int last_readcount;
> > +	u64 rc_type;
> >
> >   	int  (*get_key)(struct em28xx_IR *, struct em28xx_ir_poll_result *);
> >   };
> > @@ -236,11 +237,8 @@ static int default_polling_getkey(struct em28xx_IR *ir,
> >   	/* Infrared read count (Reg 0x45[6:0] */
> >   	poll_result->read_count = (msg[0] & 0x7f);
> >
> > -	/* Remote Control Address (Reg 0x46) */
> > -	poll_result->rc_address = msg[1];
> > -
> > -	/* Remote Control Data (Reg 0x47) */
> > -	poll_result->rc_data[0] = msg[2];
> > +	/* Remote Control Address/Data (Regs 0x46/0x47) */
> > +	poll_result->scancode = msg[1] << 8 | msg[2];
> >
> >   	return 0;
> >   }
> > @@ -266,13 +264,30 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
> >   	/* Infrared read count (Reg 0x51[6:0] */
> >   	poll_result->read_count = (msg[0] & 0x7f);
> >
> > -	/* Remote Control Address (Reg 0x52) */
> > -	poll_result->rc_address = msg[1];
> > -
> > -	/* Remote Control Data (Reg 0x53-55) */
> > -	poll_result->rc_data[0] = msg[2];
> > -	poll_result->rc_data[1] = msg[3];
> > -	poll_result->rc_data[2] = msg[4];
> > +		/* Remote Control Address (Reg 0x52) */
> > +		/* Remote Control Data (Reg 0x53-0x55) */
> > +	switch (ir->rc_type) {
> > +	case RC_TYPE_RC5:
> > +		poll_result->scancode = msg[1] << 8 | msg[2];
> > +		break;
> > +	case RC_TYPE_NEC:
> > +		if ((msg[3] ^ msg[4]) != 0xff) 		/* 32 bits NEC */
> 
> See for example KEY_CYCLEWINDOWS from RC_MAP_TIVO. Do you think it 
> works..... :-(

	{ 0xa10cfa05, KEY_CYCLEWINDOWS }, /* Window */

You're right: for it to work, this key would be needed to be defined as:

	{ 0xa10c05, KEY_CYCLEWINDOWS }, /* Window */

I agree, that's weird, but a vendor that uses a key definition like
that doesn't know what he's doing, as a remote control with address = 0xa10c
will very likely produce the same code.

Btw, the way it is currently declared won't work either with mceusb, as
the IR decoder also does the same thing.

(c/c Jarod, as he added the Tivo IR).

...

> OK, it is much better and I can even see that in Kernel than keeping 
> old, very limited implementation.
> 
> My aim was just to probe whole variant selection method is quite broken, 
> and it is impossible to get working with 100% reliable. As I have said 
> loudly :) , I want 32bit scancodes for all NEC remotes, no variants at 
> all. I think you are about the only person who wants to keep current 
> multiple NEC variant implementation...

I'm not bound to it, and no, I'm not the only one that voted for this
implementation. This were discussed in the past, when support for "extended"
nec got added (24 bits). When the first 32 bits NEC-yet-another-weird-variant
arrived, the choice was natural.

The thing is: userspace can't be broken by whatever change we do. The way
it got implemented were the one that wouldn't generate regressions.
It is as simple as that.

Cheers,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
> Em Sat, 15 Dec 2012 02:56:25 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 14 Dec 2012 17:39:50 -0200
>>> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
>>>
>>>>> Anyway, first we have to GET the bytes from the hardware. That's our
>>>>> current problem !
>>>>> And the hardware seems to need a different setup for reg 0x50 for the
>>>>> different NEC sub protocols.
>>>>> Which means that the we need to know the sub protocol BEFORE we get any
>>>>> bytes from the device.
>>>> No. All em28xx needs is to make sure that the NEC protocol will return
>>>> the full 32 bits scancode.
>>> It seems a way easier/quicker to just add the proper support there at the
>>> driver than keep answering to this thread ;)
>>>
>>> Tested here with a Terratec HTC stick, and using two different IR's:
>>> 	- a Terratec IR (address code 0x14 - standard NEC);
>>> 	- a Pixelview IR (address code 0x866b - 24 bits NEC).
>>>
>>> All tests were done with the very latest version of ir-keytable, found at
>>> v4l-utils.git tree (http://git.linuxtv.org/v4l-utils.git).
>>>
>>> See the results, with the Terratec table loaded (default when the
>>> driver is loaded):
>>>
>>> 	# ir-keytable -t
>>> 	Testing events. Please, press CTRL-C to abort.
>>> 		# Terratec IR
>>> 	1355529698.198046: event type EV_MSC(0x04): scancode = 0x1402
>>> 	1355529698.198046: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
>>> 	1355529698.198046: event type EV_SYN(0x00).
>>> 	11355529698.298170: event type EV_MSC(0x04): scancode = 0x1402
>>> 	1355529698.298170: event type EV_SYN(0x00).
>>> 	1355529698.547998: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
>>> 	1355529698.547998: event type EV_SYN(0x00).
>>> 		# Pixelview IR
>>> 	1355530261.416415: event type EV_MSC(0x04): scancode = 0x866b01
>>> 	1355530261.416415: event type EV_SYN(0x00).
>>> 	1355530262.216301: event type EV_MSC(0x04): scancode = 0x866b0b
>>> 	1355530262.216301: event type EV_SYN(0x00).
>>>
>>> Replacing the keytable to the Pixelview's one:
>>>
>>> 	# ir-keytable -w /etc/rc_keymaps/pixelview_002t -c
>>> 	Read pixelview_002t table
>>> 	Old keytable cleared
>>> 	Wrote 26 keycode(s) to driver
>>> 	Protocols changed to NEC
>>>
>>> 	# ir-keytable -t
>>> 	Testing events. Please, press CTRL-C to abort.
>>> 	1355530569.420398: event type EV_MSC(0x04): scancode = 0x1402
>>> 	1355530569.420398: event type EV_SYN(0x00).
>>> 	1355530588.120409: event type EV_MSC(0x04): scancode = 0x866b01
>>> 	1355530588.120409: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
>>> 	1355530591.670077: event type EV_SYN(0x00).
>>>
>>> And, finally, keeping both keytables active at the same time:
>>>
>>> 	# ir-keytable -c -w /etc/rc_keymaps/pixelview_002t -w /etc/rc_keymaps/nec_terratec_cinergy_xs
>>> 	Read pixelview_002t table
>>> 	Read nec_terratec_cinergy_xs table
>>> 	Old keytable cleared
>>> 	Wrote 74 keycode(s) to driver
>>> 	Protocols changed to NEC
>>>
>>> 	# sudo ir-keytable  -t
>>> 	Testing events. Please, press CTRL-C to abort.
>>> 	1355530856.325201: event type EV_MSC(0x04): scancode = 0x866b01
>>> 	1355530856.325201: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
>>> 	1355530856.325201: event type EV_SYN(0x00).
>>> 	11355530856.575070: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
>>> 	1355530856.575070: event type EV_SYN(0x00).
>>> 	1355530869.125226: event type EV_MSC(0x04): scancode = 0x1402
>>> 	1355530869.125226: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
>>> 	1355530869.125226: event type EV_SYN(0x00).
>>> 	11355530869.225216: event type EV_MSC(0x04): scancode = 0x1402
>>> 	1355530869.225216: event type EV_SYN(0x00).
>>> 	1355530869.475075: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
>>> 	1355530869.475075: event type EV_SYN(0x00).
>>>
>>> -
>>>
>>> em28xx: add support for 24bits/32 bits NEC variants on em2874 and upper
>>>
>>> By disabling the NEC parity check, it is possible to handle all 3 NEC
>>> protocol variants (32, 24 or 16 bits).
>>>
>>> Change the driver in order to handle all of them.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>>
>>
>>
>>
>> NACK. NEC variant selection logic is broken by design.
>>
>>
>>
>>
>>
>>> diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
>>> index 97d36b4..c84e4c8 100644
>>> --- a/drivers/media/usb/em28xx/em28xx-input.c
>>> +++ b/drivers/media/usb/em28xx/em28xx-input.c
>>> @@ -57,8 +57,8 @@ MODULE_PARM_DESC(ir_debug, "enable debug messages [IR]");
>>>   struct em28xx_ir_poll_result {
>>>   	unsigned int toggle_bit:1;
>>>   	unsigned int read_count:7;
>>> -	u8 rc_address;
>>> -	u8 rc_data[4]; /* 1 byte on em2860/2880, 4 on em2874 */
>>> +
>>> +	u32 scancode;
>>>   };
>>>
>>>   struct em28xx_IR {
>>> @@ -72,6 +72,7 @@ struct em28xx_IR {
>>>   	struct delayed_work work;
>>>   	unsigned int full_code:1;
>>>   	unsigned int last_readcount;
>>> +	u64 rc_type;
>>>
>>>   	int  (*get_key)(struct em28xx_IR *, struct em28xx_ir_poll_result *);
>>>   };
>>> @@ -236,11 +237,8 @@ static int default_polling_getkey(struct em28xx_IR *ir,
>>>   	/* Infrared read count (Reg 0x45[6:0] */
>>>   	poll_result->read_count = (msg[0] & 0x7f);
>>>
>>> -	/* Remote Control Address (Reg 0x46) */
>>> -	poll_result->rc_address = msg[1];
>>> -
>>> -	/* Remote Control Data (Reg 0x47) */
>>> -	poll_result->rc_data[0] = msg[2];
>>> +	/* Remote Control Address/Data (Regs 0x46/0x47) */
>>> +	poll_result->scancode = msg[1] << 8 | msg[2];
>>>
>>>   	return 0;
>>>   }
>>> @@ -266,13 +264,30 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
>>>   	/* Infrared read count (Reg 0x51[6:0] */
>>>   	poll_result->read_count = (msg[0] & 0x7f);
>>>
>>> -	/* Remote Control Address (Reg 0x52) */
>>> -	poll_result->rc_address = msg[1];
>>> -
>>> -	/* Remote Control Data (Reg 0x53-55) */
>>> -	poll_result->rc_data[0] = msg[2];
>>> -	poll_result->rc_data[1] = msg[3];
>>> -	poll_result->rc_data[2] = msg[4];
>>> +		/* Remote Control Address (Reg 0x52) */
>>> +		/* Remote Control Data (Reg 0x53-0x55) */
>>> +	switch (ir->rc_type) {
>>> +	case RC_TYPE_RC5:
>>> +		poll_result->scancode = msg[1] << 8 | msg[2];
>>> +		break;
>>> +	case RC_TYPE_NEC:
>>> +		if ((msg[3] ^ msg[4]) != 0xff) 		/* 32 bits NEC */
>> See for example KEY_CYCLEWINDOWS from RC_MAP_TIVO. Do you think it 
>> works..... :-(
> 	{ 0xa10cfa05, KEY_CYCLEWINDOWS }, /* Window */
>
> You're right: for it to work, this key would be needed to be defined as:
>
> 	{ 0xa10c05, KEY_CYCLEWINDOWS }, /* Window */
>
> I agree, that's weird, but a vendor that uses a key definition like
> that doesn't know what he's doing, as a remote control with address = 0xa10c
> will very likely produce the same code.
>
> Btw, the way it is currently declared won't work either with mceusb, as
> the IR decoder also does the same thing.
>
> (c/c Jarod, as he added the Tivo IR).
>
> ...
>
>> OK, it is much better and I can even see that in Kernel than keeping 
>> old, very limited implementation.
>>
>> My aim was just to probe whole variant selection method is quite broken, 
>> and it is impossible to get working with 100% reliable. As I have said 
>> loudly :) , I want 32bit scancodes for all NEC remotes, no variants at 
>> all. I think you are about the only person who wants to keep current 
>> multiple NEC variant implementation...
> I'm not bound to it, and no, I'm not the only one that voted for this
> implementation. This were discussed in the past, when support for "extended"
> nec got added (24 bits). When the first 32 bits NEC-yet-another-weird-variant
> arrived, the choice was natural.
>
> The thing is: userspace can't be broken by whatever change we do. The way
> it got implemented were the one that wouldn't generate regressions.
> It is as simple as that.
>
> Cheers,
> Mauro

Sorry.... we completely lost the focus !
Do you remeber the thread title ? ;)

We have two separate issues here.
1) Making Matthews hardware / the scancode retrieval code work
And _if_ it turns out that we can't make it work without knowing the sub
protocol type in advance
2) how to handle this (which doesn't necessarily mean that we have to
solve it in the RC core)

So lets focus on 1) first:
After reading the code again, it boils down to the following code lines
in em28xx_ir_handle_key():

    if (unlikely(poll_result.read_count != ir->last_readcount)) {
        dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
        ...
        rc_keydown(...)

With reg 0x50 set to EM2874_IR_NEC=0x00, Matthew doesn't get any
debugging messages when he presses the RC buttons.
With reg 0x50 set to 0x01, there are only few messages, with the same
single scancode:

Am 10.12.2012 17:00, schrieb Matthew Gyurgyik:
>>> Here is the dmesg output:
>>>
>>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>>>> key 0x61d6
>>>
>>> I pressed all the buttons on the remote (40 buttons).
>>
>> Did you cut the dmesg output ? Or do you really get these messages for
>> key 0x61d6 only ?
>
> Correct, I only got the messages for key 0x61d6 regardless of which
> physical button I press. 

So if Matthew didn't make any mistakes, the problem seems to be the read
count handling...


----------------------------------


Concerning the rc core / keymap stuff: it seems like there are some weak
spots.
The discussion is focussed on the scan codes and it seems to have a long
history.
I just want to make clear that I don't have an opinion about this yet
(nor do I want to change someone elses opinion !). I actually don't care
about it at the moment.
If we're going to discuss this further, I suggest to do that in a
separate thread with a more meaningful title.


Regards,
Frank

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Sat, 15 Dec 2012 14:11:24 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Sorry.... we completely lost the focus !
> Do you remeber the thread title ? ;)
> 
> We have two separate issues here.
> 1) Making Matthews hardware

Didn't read the entire thread, but it seems that this were already solved.

> / the scancode retrieval code work
> And _if_ it turns out that we can't make it work without knowing the sub
> protocol type in advance

The patches for IR to work with NEC-24/32 bits and RC6 mode 0 were posted.

All it lacks after applying the patches is likely to:
	1) put any dummy IR table on the board card logic, to enable IR code;
	2) run ir-keycode -t on his hardware to get the remote controller scancode;
	3) find the table that matches his IR at drivers/media/rc/keymaps/
	   or add a new one with the discovered scancodes;
	4) put the right IR table ad em28xx-cards.c;
	5) send the final patches upstream.

> 2) how to handle this (which doesn't necessarily mean that we have to
> solve it in the RC core)
> 
> So lets focus on 1) first:
> After reading the code again, it boils down to the following code lines
> in em28xx_ir_handle_key():
> 
>     if (unlikely(poll_result.read_count != ir->last_readcount)) {
>         dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
>         ...
>         rc_keydown(...)
> 
> With reg 0x50 set to EM2874_IR_NEC=0x00, Matthew doesn't get any
> debugging messages when he presses the RC buttons.
> With reg 0x50 set to 0x01, there are only few messages, with the same
> single scancode:
> 
> Am 10.12.2012 17:00, schrieb Matthew Gyurgyik:
> >>> Here is the dmesg output:
> >>>
> >>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
> >>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
> >>>> key 0x61d6
> >>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
> >>>> key 0x61d6
> >>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
> >>>> key 0x61d6
> >>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
> >>>> key 0x61d6
> >>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
> >>>> key 0x61d6
> >>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
> >>>> key 0x61d6
> >>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
> >>>> key 0x61d6

The above is obviously not using the patches I sent yesterday/today, otherwise,
it would be seeing, instead, the full 32 bits code there.

Also, the better is to use ir-keytable program on test mode ("ir-keytable -t"),
as it allows to see if the 3 protocol messages received by each keystroke are
being received (EV_MSC, EV_KEY and EV_SYN).

> >>>
> >>> I pressed all the buttons on the remote (40 buttons).
> >>
> >> Did you cut the dmesg output ? Or do you really get these messages for
> >> key 0x61d6 only ?
> >
> > Correct, I only got the messages for key 0x61d6 regardless of which
> > physical button I press. 
> 
> So if Matthew didn't make any mistakes, the problem seems to be the read
> count handling...
> 
> 
> ----------------------------------
> 
> 
> Concerning the rc core / keymap stuff: it seems like there are some weak
> spots.
> The discussion is focussed on the scan codes and it seems to have a long
> history.
> I just want to make clear that I don't have an opinion about this yet
> (nor do I want to change someone elses opinion !). I actually don't care
> about it at the moment.
> If we're going to discuss this further, I suggest to do that in a
> separate thread with a more meaningful title.

Agreed. This is a separate question, and should be handled on a different
thread.

Regards,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/15/2012 03:11 PM, Frank Schäfer wrote:
> Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
>> Em Sat, 15 Dec 2012 02:56:25 +0200
>> Antti Palosaari <crope@iki.fi> escreveu:
>>
>>> On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
>>>> Em Fri, 14 Dec 2012 17:39:50 -0200
>>>> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
>>>>
>>>>>> Anyway, first we have to GET the bytes from the hardware. That's our
>>>>>> current problem !
>>>>>> And the hardware seems to need a different setup for reg 0x50 for the
>>>>>> different NEC sub protocols.
>>>>>> Which means that the we need to know the sub protocol BEFORE we get any
>>>>>> bytes from the device.
>>>>> No. All em28xx needs is to make sure that the NEC protocol will return
>>>>> the full 32 bits scancode.
>>>> It seems a way easier/quicker to just add the proper support there at the
>>>> driver than keep answering to this thread ;)
>>>>
>>>> Tested here with a Terratec HTC stick, and using two different IR's:
>>>> 	- a Terratec IR (address code 0x14 - standard NEC);
>>>> 	- a Pixelview IR (address code 0x866b - 24 bits NEC).
>>>>
>>>> All tests were done with the very latest version of ir-keytable, found at
>>>> v4l-utils.git tree (http://git.linuxtv.org/v4l-utils.git).
>>>>
>>>> See the results, with the Terratec table loaded (default when the
>>>> driver is loaded):
>>>>
>>>> 	# ir-keytable -t
>>>> 	Testing events. Please, press CTRL-C to abort.
>>>> 		# Terratec IR
>>>> 	1355529698.198046: event type EV_MSC(0x04): scancode = 0x1402
>>>> 	1355529698.198046: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
>>>> 	1355529698.198046: event type EV_SYN(0x00).
>>>> 	11355529698.298170: event type EV_MSC(0x04): scancode = 0x1402
>>>> 	1355529698.298170: event type EV_SYN(0x00).
>>>> 	1355529698.547998: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
>>>> 	1355529698.547998: event type EV_SYN(0x00).
>>>> 		# Pixelview IR
>>>> 	1355530261.416415: event type EV_MSC(0x04): scancode = 0x866b01
>>>> 	1355530261.416415: event type EV_SYN(0x00).
>>>> 	1355530262.216301: event type EV_MSC(0x04): scancode = 0x866b0b
>>>> 	1355530262.216301: event type EV_SYN(0x00).
>>>>
>>>> Replacing the keytable to the Pixelview's one:
>>>>
>>>> 	# ir-keytable -w /etc/rc_keymaps/pixelview_002t -c
>>>> 	Read pixelview_002t table
>>>> 	Old keytable cleared
>>>> 	Wrote 26 keycode(s) to driver
>>>> 	Protocols changed to NEC
>>>>
>>>> 	# ir-keytable -t
>>>> 	Testing events. Please, press CTRL-C to abort.
>>>> 	1355530569.420398: event type EV_MSC(0x04): scancode = 0x1402
>>>> 	1355530569.420398: event type EV_SYN(0x00).
>>>> 	1355530588.120409: event type EV_MSC(0x04): scancode = 0x866b01
>>>> 	1355530588.120409: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
>>>> 	1355530591.670077: event type EV_SYN(0x00).
>>>>
>>>> And, finally, keeping both keytables active at the same time:
>>>>
>>>> 	# ir-keytable -c -w /etc/rc_keymaps/pixelview_002t -w /etc/rc_keymaps/nec_terratec_cinergy_xs
>>>> 	Read pixelview_002t table
>>>> 	Read nec_terratec_cinergy_xs table
>>>> 	Old keytable cleared
>>>> 	Wrote 74 keycode(s) to driver
>>>> 	Protocols changed to NEC
>>>>
>>>> 	# sudo ir-keytable  -t
>>>> 	Testing events. Please, press CTRL-C to abort.
>>>> 	1355530856.325201: event type EV_MSC(0x04): scancode = 0x866b01
>>>> 	1355530856.325201: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
>>>> 	1355530856.325201: event type EV_SYN(0x00).
>>>> 	11355530856.575070: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
>>>> 	1355530856.575070: event type EV_SYN(0x00).
>>>> 	1355530869.125226: event type EV_MSC(0x04): scancode = 0x1402
>>>> 	1355530869.125226: event type EV_KEY(0x01) key_down: KEY_1(0x0001)
>>>> 	1355530869.125226: event type EV_SYN(0x00).
>>>> 	11355530869.225216: event type EV_MSC(0x04): scancode = 0x1402
>>>> 	1355530869.225216: event type EV_SYN(0x00).
>>>> 	1355530869.475075: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
>>>> 	1355530869.475075: event type EV_SYN(0x00).
>>>>
>>>> -
>>>>
>>>> em28xx: add support for 24bits/32 bits NEC variants on em2874 and upper
>>>>
>>>> By disabling the NEC parity check, it is possible to handle all 3 NEC
>>>> protocol variants (32, 24 or 16 bits).
>>>>
>>>> Change the driver in order to handle all of them.
>>>>
>>>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>>>
>>>
>>>
>>>
>>> NACK. NEC variant selection logic is broken by design.
>>>
>>>
>>>
>>>
>>>
>>>> diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
>>>> index 97d36b4..c84e4c8 100644
>>>> --- a/drivers/media/usb/em28xx/em28xx-input.c
>>>> +++ b/drivers/media/usb/em28xx/em28xx-input.c
>>>> @@ -57,8 +57,8 @@ MODULE_PARM_DESC(ir_debug, "enable debug messages [IR]");
>>>>    struct em28xx_ir_poll_result {
>>>>    	unsigned int toggle_bit:1;
>>>>    	unsigned int read_count:7;
>>>> -	u8 rc_address;
>>>> -	u8 rc_data[4]; /* 1 byte on em2860/2880, 4 on em2874 */
>>>> +
>>>> +	u32 scancode;
>>>>    };
>>>>
>>>>    struct em28xx_IR {
>>>> @@ -72,6 +72,7 @@ struct em28xx_IR {
>>>>    	struct delayed_work work;
>>>>    	unsigned int full_code:1;
>>>>    	unsigned int last_readcount;
>>>> +	u64 rc_type;
>>>>
>>>>    	int  (*get_key)(struct em28xx_IR *, struct em28xx_ir_poll_result *);
>>>>    };
>>>> @@ -236,11 +237,8 @@ static int default_polling_getkey(struct em28xx_IR *ir,
>>>>    	/* Infrared read count (Reg 0x45[6:0] */
>>>>    	poll_result->read_count = (msg[0] & 0x7f);
>>>>
>>>> -	/* Remote Control Address (Reg 0x46) */
>>>> -	poll_result->rc_address = msg[1];
>>>> -
>>>> -	/* Remote Control Data (Reg 0x47) */
>>>> -	poll_result->rc_data[0] = msg[2];
>>>> +	/* Remote Control Address/Data (Regs 0x46/0x47) */
>>>> +	poll_result->scancode = msg[1] << 8 | msg[2];
>>>>
>>>>    	return 0;
>>>>    }
>>>> @@ -266,13 +264,30 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
>>>>    	/* Infrared read count (Reg 0x51[6:0] */
>>>>    	poll_result->read_count = (msg[0] & 0x7f);
>>>>
>>>> -	/* Remote Control Address (Reg 0x52) */
>>>> -	poll_result->rc_address = msg[1];
>>>> -
>>>> -	/* Remote Control Data (Reg 0x53-55) */
>>>> -	poll_result->rc_data[0] = msg[2];
>>>> -	poll_result->rc_data[1] = msg[3];
>>>> -	poll_result->rc_data[2] = msg[4];
>>>> +		/* Remote Control Address (Reg 0x52) */
>>>> +		/* Remote Control Data (Reg 0x53-0x55) */
>>>> +	switch (ir->rc_type) {
>>>> +	case RC_TYPE_RC5:
>>>> +		poll_result->scancode = msg[1] << 8 | msg[2];
>>>> +		break;
>>>> +	case RC_TYPE_NEC:
>>>> +		if ((msg[3] ^ msg[4]) != 0xff) 		/* 32 bits NEC */
>>> See for example KEY_CYCLEWINDOWS from RC_MAP_TIVO. Do you think it
>>> works..... :-(
>> 	{ 0xa10cfa05, KEY_CYCLEWINDOWS }, /* Window */
>>
>> You're right: for it to work, this key would be needed to be defined as:
>>
>> 	{ 0xa10c05, KEY_CYCLEWINDOWS }, /* Window */
>>
>> I agree, that's weird, but a vendor that uses a key definition like
>> that doesn't know what he's doing, as a remote control with address = 0xa10c
>> will very likely produce the same code.
>>
>> Btw, the way it is currently declared won't work either with mceusb, as
>> the IR decoder also does the same thing.
>>
>> (c/c Jarod, as he added the Tivo IR).
>>
>> ...
>>
>>> OK, it is much better and I can even see that in Kernel than keeping
>>> old, very limited implementation.
>>>
>>> My aim was just to probe whole variant selection method is quite broken,
>>> and it is impossible to get working with 100% reliable. As I have said
>>> loudly :) , I want 32bit scancodes for all NEC remotes, no variants at
>>> all. I think you are about the only person who wants to keep current
>>> multiple NEC variant implementation...
>> I'm not bound to it, and no, I'm not the only one that voted for this
>> implementation. This were discussed in the past, when support for "extended"
>> nec got added (24 bits). When the first 32 bits NEC-yet-another-weird-variant
>> arrived, the choice was natural.
>>
>> The thing is: userspace can't be broken by whatever change we do. The way
>> it got implemented were the one that wouldn't generate regressions.
>> It is as simple as that.
>>
>> Cheers,
>> Mauro
>
> Sorry.... we completely lost the focus !
> Do you remeber the thread title ? ;)
>
> We have two separate issues here.
> 1) Making Matthews hardware / the scancode retrieval code work
> And _if_ it turns out that we can't make it work without knowing the sub
> protocol type in advance
> 2) how to handle this (which doesn't necessarily mean that we have to
> solve it in the RC core)
>
> So lets focus on 1) first:
> After reading the code again, it boils down to the following code lines
> in em28xx_ir_handle_key():
>
>      if (unlikely(poll_result.read_count != ir->last_readcount)) {
>          dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
>          ...
>          rc_keydown(...)
>
> With reg 0x50 set to EM2874_IR_NEC=0x00, Matthew doesn't get any
> debugging messages when he presses the RC buttons.
> With reg 0x50 set to 0x01, there are only few messages, with the same
> single scancode:
>
> Am 10.12.2012 17:00, schrieb Matthew Gyurgyik:
>>>> Here is the dmesg output:
>>>>
>>>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
>>>>> key 0x61d6
>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
>>>>> key 0x61d6
>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
>>>>> key 0x61d6
>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>>>>> key 0x61d6
>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>>>>> key 0x61d6
>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>>>>> key 0x61d6
>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>>>>> key 0x61d6
>>>>
>>>> I pressed all the buttons on the remote (40 buttons).
>>>
>>> Did you cut the dmesg output ? Or do you really get these messages for
>>> key 0x61d6 only ?
>>
>> Correct, I only got the messages for key 0x61d6 regardless of which
>> physical button I press.
>
> So if Matthew didn't make any mistakes, the problem seems to be the read
> count handling...

That is what happened and it is correct behavior as Matthews remote is 
24 bit NEC (and driver does not know how to handle it). If you look 
again those raw dumps which I send previous mail you could see the 
issue. 61d6 seen here is remote controller address, two first bits. It 
outputs that because debug does not output rest 2 remaining bytes where 
is actual key code. If you set em28xx to 32bit NEC mode then key code 
for that remote set 61d6 by driver mistakenly as it does not know there 
is 2 bytes more to handle.

I copy & pasted here relevant lines from the em28xx driver. Maybe you 
could now see why code is wrong - why the extended address byte is set 
as to scancode mistakenly. Look especially care following variables: 
msg[1], msg[2], poll_result->rc_address and poll_result.rc_data[0]

static int em2874_polling_getkey()
{
rc = dev->em28xx_read_reg_req_len(dev, 0, EM2874_R51_IR, msg, sizeof(msg));

/* Remote Control Address (Reg 0x52) */
poll_result->rc_address = msg[1];

/* Remote Control Data (Reg 0x53-55) */
poll_result->rc_data[0] = msg[2];
poll_result->rc_data[1] = msg[3];
poll_result->rc_data[2] = msg[4];
}



static void em28xx_ir_handle_key()
{
dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
	poll_result.toggle_bit, poll_result.read_count,
	poll_result.rc_address, poll_result.rc_data[0]);
}


I am about 99% sure Mauro's patch works correctly for Matthews device.


Maybe you missed point hardware returns different format in case of 
32bit and 16bit values. If it is 16bit mode it return only 2 bytes and 
if 32bit mode it returns 4 bytes?




>
>
> ----------------------------------
>
>
> Concerning the rc core / keymap stuff: it seems like there are some weak
> spots.
> The discussion is focussed on the scan codes and it seems to have a long
> history.
> I just want to make clear that I don't have an opinion about this yet
> (nor do I want to change someone elses opinion !). I actually don't care
> about it at the moment.
> If we're going to discuss this further, I suggest to do that in a
> separate thread with a more meaningful title.
>
>
> Regards,
> Frank

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 15.12.2012 14:38, schrieb Antti Palosaari:
> On 12/15/2012 03:11 PM, Frank Schäfer wrote:
>> Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
>>> Em Sat, 15 Dec 2012 02:56:25 +0200
>>> Antti Palosaari <crope@iki.fi> escreveu:
>>>
>>>> On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
>>>>> Em Fri, 14 Dec 2012 17:39:50 -0200
>>>>> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
>>>>>
>>>>>>> Anyway, first we have to GET the bytes from the hardware. That's
>>>>>>> our
>>>>>>> current problem !
>>>>>>> And the hardware seems to need a different setup for reg 0x50
>>>>>>> for the
>>>>>>> different NEC sub protocols.
>>>>>>> Which means that the we need to know the sub protocol BEFORE we
>>>>>>> get any
>>>>>>> bytes from the device.
>>>>>> No. All em28xx needs is to make sure that the NEC protocol will
>>>>>> return
>>>>>> the full 32 bits scancode.
>>>>> It seems a way easier/quicker to just add the proper support there
>>>>> at the
>>>>> driver than keep answering to this thread ;)
>>>>>
>>>>> Tested here with a Terratec HTC stick, and using two different IR's:
>>>>>     - a Terratec IR (address code 0x14 - standard NEC);
>>>>>     - a Pixelview IR (address code 0x866b - 24 bits NEC).
>>>>>
>>>>> All tests were done with the very latest version of ir-keytable,
>>>>> found at
>>>>> v4l-utils.git tree (http://git.linuxtv.org/v4l-utils.git).
>>>>>
>>>>> See the results, with the Terratec table loaded (default when the
>>>>> driver is loaded):
>>>>>
>>>>>     # ir-keytable -t
>>>>>     Testing events. Please, press CTRL-C to abort.
>>>>>         # Terratec IR
>>>>>     1355529698.198046: event type EV_MSC(0x04): scancode = 0x1402
>>>>>     1355529698.198046: event type EV_KEY(0x01) key_down:
>>>>> KEY_1(0x0001)
>>>>>     1355529698.198046: event type EV_SYN(0x00).
>>>>>     11355529698.298170: event type EV_MSC(0x04): scancode = 0x1402
>>>>>     1355529698.298170: event type EV_SYN(0x00).
>>>>>     1355529698.547998: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
>>>>>     1355529698.547998: event type EV_SYN(0x00).
>>>>>         # Pixelview IR
>>>>>     1355530261.416415: event type EV_MSC(0x04): scancode = 0x866b01
>>>>>     1355530261.416415: event type EV_SYN(0x00).
>>>>>     1355530262.216301: event type EV_MSC(0x04): scancode = 0x866b0b
>>>>>     1355530262.216301: event type EV_SYN(0x00).
>>>>>
>>>>> Replacing the keytable to the Pixelview's one:
>>>>>
>>>>>     # ir-keytable -w /etc/rc_keymaps/pixelview_002t -c
>>>>>     Read pixelview_002t table
>>>>>     Old keytable cleared
>>>>>     Wrote 26 keycode(s) to driver
>>>>>     Protocols changed to NEC
>>>>>
>>>>>     # ir-keytable -t
>>>>>     Testing events. Please, press CTRL-C to abort.
>>>>>     1355530569.420398: event type EV_MSC(0x04): scancode = 0x1402
>>>>>     1355530569.420398: event type EV_SYN(0x00).
>>>>>     1355530588.120409: event type EV_MSC(0x04): scancode = 0x866b01
>>>>>     1355530588.120409: event type EV_KEY(0x01) key_down:
>>>>> KEY_1(0x0001)
>>>>>     1355530591.670077: event type EV_SYN(0x00).
>>>>>
>>>>> And, finally, keeping both keytables active at the same time:
>>>>>
>>>>>     # ir-keytable -c -w /etc/rc_keymaps/pixelview_002t -w
>>>>> /etc/rc_keymaps/nec_terratec_cinergy_xs
>>>>>     Read pixelview_002t table
>>>>>     Read nec_terratec_cinergy_xs table
>>>>>     Old keytable cleared
>>>>>     Wrote 74 keycode(s) to driver
>>>>>     Protocols changed to NEC
>>>>>
>>>>>     # sudo ir-keytable  -t
>>>>>     Testing events. Please, press CTRL-C to abort.
>>>>>     1355530856.325201: event type EV_MSC(0x04): scancode = 0x866b01
>>>>>     1355530856.325201: event type EV_KEY(0x01) key_down:
>>>>> KEY_1(0x0001)
>>>>>     1355530856.325201: event type EV_SYN(0x00).
>>>>>     11355530856.575070: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
>>>>>     1355530856.575070: event type EV_SYN(0x00).
>>>>>     1355530869.125226: event type EV_MSC(0x04): scancode = 0x1402
>>>>>     1355530869.125226: event type EV_KEY(0x01) key_down:
>>>>> KEY_1(0x0001)
>>>>>     1355530869.125226: event type EV_SYN(0x00).
>>>>>     11355530869.225216: event type EV_MSC(0x04): scancode = 0x1402
>>>>>     1355530869.225216: event type EV_SYN(0x00).
>>>>>     1355530869.475075: event type EV_KEY(0x01) key_up: KEY_1(0x0001)
>>>>>     1355530869.475075: event type EV_SYN(0x00).
>>>>>
>>>>> -
>>>>>
>>>>> em28xx: add support for 24bits/32 bits NEC variants on em2874 and
>>>>> upper
>>>>>
>>>>> By disabling the NEC parity check, it is possible to handle all 3 NEC
>>>>> protocol variants (32, 24 or 16 bits).
>>>>>
>>>>> Change the driver in order to handle all of them.
>>>>>
>>>>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>>>>
>>>>
>>>>
>>>>
>>>> NACK. NEC variant selection logic is broken by design.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> diff --git a/drivers/media/usb/em28xx/em28xx-input.c
>>>>> b/drivers/media/usb/em28xx/em28xx-input.c
>>>>> index 97d36b4..c84e4c8 100644
>>>>> --- a/drivers/media/usb/em28xx/em28xx-input.c
>>>>> +++ b/drivers/media/usb/em28xx/em28xx-input.c
>>>>> @@ -57,8 +57,8 @@ MODULE_PARM_DESC(ir_debug, "enable debug
>>>>> messages [IR]");
>>>>>    struct em28xx_ir_poll_result {
>>>>>        unsigned int toggle_bit:1;
>>>>>        unsigned int read_count:7;
>>>>> -    u8 rc_address;
>>>>> -    u8 rc_data[4]; /* 1 byte on em2860/2880, 4 on em2874 */
>>>>> +
>>>>> +    u32 scancode;
>>>>>    };
>>>>>
>>>>>    struct em28xx_IR {
>>>>> @@ -72,6 +72,7 @@ struct em28xx_IR {
>>>>>        struct delayed_work work;
>>>>>        unsigned int full_code:1;
>>>>>        unsigned int last_readcount;
>>>>> +    u64 rc_type;
>>>>>
>>>>>        int  (*get_key)(struct em28xx_IR *, struct
>>>>> em28xx_ir_poll_result *);
>>>>>    };
>>>>> @@ -236,11 +237,8 @@ static int default_polling_getkey(struct
>>>>> em28xx_IR *ir,
>>>>>        /* Infrared read count (Reg 0x45[6:0] */
>>>>>        poll_result->read_count = (msg[0] & 0x7f);
>>>>>
>>>>> -    /* Remote Control Address (Reg 0x46) */
>>>>> -    poll_result->rc_address = msg[1];
>>>>> -
>>>>> -    /* Remote Control Data (Reg 0x47) */
>>>>> -    poll_result->rc_data[0] = msg[2];
>>>>> +    /* Remote Control Address/Data (Regs 0x46/0x47) */
>>>>> +    poll_result->scancode = msg[1] << 8 | msg[2];
>>>>>
>>>>>        return 0;
>>>>>    }
>>>>> @@ -266,13 +264,30 @@ static int em2874_polling_getkey(struct
>>>>> em28xx_IR *ir,
>>>>>        /* Infrared read count (Reg 0x51[6:0] */
>>>>>        poll_result->read_count = (msg[0] & 0x7f);
>>>>>
>>>>> -    /* Remote Control Address (Reg 0x52) */
>>>>> -    poll_result->rc_address = msg[1];
>>>>> -
>>>>> -    /* Remote Control Data (Reg 0x53-55) */
>>>>> -    poll_result->rc_data[0] = msg[2];
>>>>> -    poll_result->rc_data[1] = msg[3];
>>>>> -    poll_result->rc_data[2] = msg[4];
>>>>> +        /* Remote Control Address (Reg 0x52) */
>>>>> +        /* Remote Control Data (Reg 0x53-0x55) */
>>>>> +    switch (ir->rc_type) {
>>>>> +    case RC_TYPE_RC5:
>>>>> +        poll_result->scancode = msg[1] << 8 | msg[2];
>>>>> +        break;
>>>>> +    case RC_TYPE_NEC:
>>>>> +        if ((msg[3] ^ msg[4]) != 0xff)         /* 32 bits NEC */
>>>> See for example KEY_CYCLEWINDOWS from RC_MAP_TIVO. Do you think it
>>>> works..... :-(
>>>     { 0xa10cfa05, KEY_CYCLEWINDOWS }, /* Window */
>>>
>>> You're right: for it to work, this key would be needed to be defined
>>> as:
>>>
>>>     { 0xa10c05, KEY_CYCLEWINDOWS }, /* Window */
>>>
>>> I agree, that's weird, but a vendor that uses a key definition like
>>> that doesn't know what he's doing, as a remote control with address
>>> = 0xa10c
>>> will very likely produce the same code.
>>>
>>> Btw, the way it is currently declared won't work either with mceusb, as
>>> the IR decoder also does the same thing.
>>>
>>> (c/c Jarod, as he added the Tivo IR).
>>>
>>> ...
>>>
>>>> OK, it is much better and I can even see that in Kernel than keeping
>>>> old, very limited implementation.
>>>>
>>>> My aim was just to probe whole variant selection method is quite
>>>> broken,
>>>> and it is impossible to get working with 100% reliable. As I have said
>>>> loudly :) , I want 32bit scancodes for all NEC remotes, no variants at
>>>> all. I think you are about the only person who wants to keep current
>>>> multiple NEC variant implementation...
>>> I'm not bound to it, and no, I'm not the only one that voted for this
>>> implementation. This were discussed in the past, when support for
>>> "extended"
>>> nec got added (24 bits). When the first 32 bits
>>> NEC-yet-another-weird-variant
>>> arrived, the choice was natural.
>>>
>>> The thing is: userspace can't be broken by whatever change we do.
>>> The way
>>> it got implemented were the one that wouldn't generate regressions.
>>> It is as simple as that.
>>>
>>> Cheers,
>>> Mauro
>>
>> Sorry.... we completely lost the focus !
>> Do you remeber the thread title ? ;)
>>
>> We have two separate issues here.
>> 1) Making Matthews hardware / the scancode retrieval code work
>> And _if_ it turns out that we can't make it work without knowing the sub
>> protocol type in advance
>> 2) how to handle this (which doesn't necessarily mean that we have to
>> solve it in the RC core)
>>
>> So lets focus on 1) first:
>> After reading the code again, it boils down to the following code lines
>> in em28xx_ir_handle_key():
>>
>>      if (unlikely(poll_result.read_count != ir->last_readcount)) {
>>          dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n",
>> __func__,
>>          ...
>>          rc_keydown(...)
>>
>> With reg 0x50 set to EM2874_IR_NEC=0x00, Matthew doesn't get any
>> debugging messages when he presses the RC buttons.
>> With reg 0x50 set to 0x01, there are only few messages, with the same
>> single scancode:
>>
>> Am 10.12.2012 17:00, schrieb Matthew Gyurgyik:
>>>>> Here is the dmesg output:
>>>>>
>>>>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep
>>>>>> handle
>>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0,
>>>>>> count: 1,
>>>>>> key 0x61d6
>>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0,
>>>>>> count: 2,
>>>>>> key 0x61d6
>>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1,
>>>>>> count: 1,
>>>>>> key 0x61d6
>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>>>>>> key 0x61d6
>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>>>>>> key 0x61d6
>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>>>>>> key 0x61d6
>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>>>>>> key 0x61d6
>>>>>
>>>>> I pressed all the buttons on the remote (40 buttons).
>>>>
>>>> Did you cut the dmesg output ? Or do you really get these messages for
>>>> key 0x61d6 only ?
>>>
>>> Correct, I only got the messages for key 0x61d6 regardless of which
>>> physical button I press.
>>
>> So if Matthew didn't make any mistakes, the problem seems to be the read
>> count handling...
>
> That is what happened and it is correct behavior as Matthews remote is
> 24 bit NEC (and driver does not know how to handle it). If you look
> again those raw dumps which I send previous mail you could see the
> issue. 61d6 seen here is remote controller address, two first bits. It
> outputs that because debug does not output rest 2 remaining bytes
> where is actual key code. If you set em28xx to 32bit NEC mode then key
> code for that remote set 61d6 by driver mistakenly as it does not know
> there is 2 bytes more to handle.

Antti, the problem with Matthews RC isn't the number of bytes printed to
the log.
The problems is, that NO messages appear in the log (with one exception).

>
> I copy & pasted here relevant lines from the em28xx driver. Maybe you
> could now see why code is wrong - why the extended address byte is set
> as to scancode mistakenly. Look especially care following variables:
> msg[1], msg[2], poll_result->rc_address and poll_result.rc_data[0]
>
> static int em2874_polling_getkey()
> {
> rc = dev->em28xx_read_reg_req_len(dev, 0, EM2874_R51_IR, msg,
> sizeof(msg));
>
> /* Remote Control Address (Reg 0x52) */
> poll_result->rc_address = msg[1];
>
> /* Remote Control Data (Reg 0x53-55) */
> poll_result->rc_data[0] = msg[2];
> poll_result->rc_data[1] = msg[3];
> poll_result->rc_data[2] = msg[4];
> }
>

You missed the relevant part of the code:

static int em2874_polling_getkey()
{
...
    /* Infrared read count (Reg 0x51[6:0] */
    poll_result->read_count = (msg[0] & 0x7f);
...
}


>
>
> static void em28xx_ir_handle_key()
> {
> dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
>     poll_result.toggle_bit, poll_result.read_count,
>     poll_result.rc_address, poll_result.rc_data[0]);
> }
>

Same here, you missed the if () statement:

static void em28xx_ir_handle_key(struct em28xx_IR *ir)
{
...
    if (unlikely(poll_result.read_count != ir->last_readcount)) {
        dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
            poll_result.toggle_bit, poll_result.read_count,
            poll_result.rc_address, poll_result.rc_data[0]);
...
}


It doesn't matter which format the scancode (4 bytes) has, a message
should be printed in any case.
But according to Matthew, that doesn't happen. Hence, the
poll_result.read_count != ir->last_readcount must be the problem.

>
> I am about 99% sure Mauro's patch works correctly for Matthews device.
>

If Matthew didn't make any mistakes, I can't see how these patches can
make it work. Which doesn't mean that they don't make sense.


Matthew, could you please validate your test results and try Mauros
patches ?
If it doesn't work, please create another USB-log.


> Maybe you missed point hardware returns different format in case of
> 32bit and 16bit values. If it is 16bit mode it return only 2 bytes and
> if 32bit mode it returns 4 bytes?
>

No.


Regards,
Frank

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/15/2012 06:21 PM, Frank Schäfer wrote:
> Am 15.12.2012 14:38, schrieb Antti Palosaari:
>> On 12/15/2012 03:11 PM, Frank Schäfer wrote:
>>> Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
>>>> Em Sat, 15 Dec 2012 02:56:25 +0200
>>>> Antti Palosaari <crope@iki.fi> escreveu:
>>>>
>>>>> On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
>>>>>> Em Fri, 14 Dec 2012 17:39:50 -0200
>>>>>> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

>>> Am 10.12.2012 17:00, schrieb Matthew Gyurgyik:
>>>>>> Here is the dmesg output:
>>>>>>
>>>>>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep
>>>>>>> handle
>>>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0,
>>>>>>> count: 1,
>>>>>>> key 0x61d6
>>>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0,
>>>>>>> count: 2,
>>>>>>> key 0x61d6
>>>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1,
>>>>>>> count: 1,
>>>>>>> key 0x61d6
>>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>>>>>>> key 0x61d6
>>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>>>>>>> key 0x61d6
>>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>>>>>>> key 0x61d6
>>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>>>>>>> key 0x61d6
>>>>>>
>>>>>> I pressed all the buttons on the remote (40 buttons).
>>>>>
>>>>> Did you cut the dmesg output ? Or do you really get these messages for
>>>>> key 0x61d6 only ?
>>>>
>>>> Correct, I only got the messages for key 0x61d6 regardless of which
>>>> physical button I press.
>>>
>>> So if Matthew didn't make any mistakes, the problem seems to be the read
>>> count handling...
>>
>> That is what happened and it is correct behavior as Matthews remote is
>> 24 bit NEC (and driver does not know how to handle it). If you look
>> again those raw dumps which I send previous mail you could see the
>> issue. 61d6 seen here is remote controller address, two first bits. It
>> outputs that because debug does not output rest 2 remaining bytes
>> where is actual key code. If you set em28xx to 32bit NEC mode then key
>> code for that remote set 61d6 by driver mistakenly as it does not know
>> there is 2 bytes more to handle.
>
> Antti, the problem with Matthews RC isn't the number of bytes printed to
> the log.
> The problems is, that NO messages appear in the log (with one exception).

What is that exception?

In that case there should be around 40 similar debug lines - as address 
byte is same for all buttons and debug prints only address byte, toggle 
and count. As toggle and count still outputs some numbers we will see 
that many line. Without toggle and count there is likely only one debug 
line seen as output is piped through uniq which drops similar lines.

>> I copy & pasted here relevant lines from the em28xx driver. Maybe you
>> could now see why code is wrong - why the extended address byte is set
>> as to scancode mistakenly. Look especially care following variables:
>> msg[1], msg[2], poll_result->rc_address and poll_result.rc_data[0]
>>
>> static int em2874_polling_getkey()
>> {
>> rc = dev->em28xx_read_reg_req_len(dev, 0, EM2874_R51_IR, msg,
>> sizeof(msg));
>>
>> /* Remote Control Address (Reg 0x52) */
>> poll_result->rc_address = msg[1];
>>
>> /* Remote Control Data (Reg 0x53-55) */
>> poll_result->rc_data[0] = msg[2];
>> poll_result->rc_data[1] = msg[3];
>> poll_result->rc_data[2] = msg[4];
>> }
>>
>
> You missed the relevant part of the code:
>
> static int em2874_polling_getkey()
> {
> ...
>      /* Infrared read count (Reg 0x51[6:0] */
>      poll_result->read_count = (msg[0] & 0x7f);
> ...
> }
>
>
>>
>>
>> static void em28xx_ir_handle_key()
>> {
>> dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
>>      poll_result.toggle_bit, poll_result.read_count,
>>      poll_result.rc_address, poll_result.rc_data[0]);
>> }
>>
>
> Same here, you missed the if () statement:
>
> static void em28xx_ir_handle_key(struct em28xx_IR *ir)
> {
> ...
>      if (unlikely(poll_result.read_count != ir->last_readcount)) {
>          dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
>              poll_result.toggle_bit, poll_result.read_count,
>              poll_result.rc_address, poll_result.rc_data[0]);
> ...
> }
>
>
> It doesn't matter which format the scancode (4 bytes) has, a message
> should be printed in any case.
> But according to Matthew, that doesn't happen. Hence, the
> poll_result.read_count != ir->last_readcount must be the problem.

I don't see which messages are missing.

I think read_count is not incremented in case NEC 16bit checksum fails - 
hw just discards whole code => read_count not increase => no debug. For 
my tests there was always 81/01 when key was pressed and 00 when no key 
pressed (as seen also logs I posted yesterday).

>> I am about 99% sure Mauro's patch works correctly for Matthews device.
>>
>
> If Matthew didn't make any mistakes, I can't see how these patches can
> make it work. Which doesn't mean that they don't make sense.
>
>
> Matthew, could you please validate your test results and try Mauros
> patches ?
> If it doesn't work, please create another USB-log.
>
>
>> Maybe you missed point hardware returns different format in case of
>> 32bit and 16bit values. If it is 16bit mode it return only 2 bytes and
>> if 32bit mode it returns 4 bytes?
>>
>
> No.
>
>
> Regards,
> Frank

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 15.12.2012 17:51, schrieb Antti Palosaari:
> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>> Am 15.12.2012 14:38, schrieb Antti Palosaari:
>>> On 12/15/2012 03:11 PM, Frank Schäfer wrote:
>>>> Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
>>>>> Em Sat, 15 Dec 2012 02:56:25 +0200
>>>>> Antti Palosaari <crope@iki.fi> escreveu:
>>>>>
>>>>>> On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
>>>>>>> Em Fri, 14 Dec 2012 17:39:50 -0200
>>>>>>> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
>
>>>> Am 10.12.2012 17:00, schrieb Matthew Gyurgyik:
>>>>>>> Here is the dmesg output:
>>>>>>>
>>>>>>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep
>>>>>>>> handle
>>>>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0,
>>>>>>>> count: 1,
>>>>>>>> key 0x61d6
>>>>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0,
>>>>>>>> count: 2,
>>>>>>>> key 0x61d6
>>>>>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1,
>>>>>>>> count: 1,
>>>>>>>> key 0x61d6
>>>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0,
>>>>>>>> count: 1,
>>>>>>>> key 0x61d6
>>>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0,
>>>>>>>> count: 2,
>>>>>>>> key 0x61d6
>>>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1,
>>>>>>>> count: 1,
>>>>>>>> key 0x61d6
>>>>>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1,
>>>>>>>> count: 2,
>>>>>>>> key 0x61d6
>>>>>>>
>>>>>>> I pressed all the buttons on the remote (40 buttons).
>>>>>>
>>>>>> Did you cut the dmesg output ? Or do you really get these
>>>>>> messages for
>>>>>> key 0x61d6 only ?
>>>>>
>>>>> Correct, I only got the messages for key 0x61d6 regardless of which
>>>>> physical button I press.
>>>>
>>>> So if Matthew didn't make any mistakes, the problem seems to be the
>>>> read
>>>> count handling...
>>>
>>> That is what happened and it is correct behavior as Matthews remote is
>>> 24 bit NEC (and driver does not know how to handle it). If you look
>>> again those raw dumps which I send previous mail you could see the
>>> issue. 61d6 seen here is remote controller address, two first bits. It
>>> outputs that because debug does not output rest 2 remaining bytes
>>> where is actual key code. If you set em28xx to 32bit NEC mode then key
>>> code for that remote set 61d6 by driver mistakenly as it does not know
>>> there is 2 bytes more to handle.
>>
>> Antti, the problem with Matthews RC isn't the number of bytes printed to
>> the log.
>> The problems is, that NO messages appear in the log (with one
>> exception).
>
> What is that exception?
>
> In that case there should be around 40 similar debug lines - as
> address byte is same for all buttons and debug prints only address
> byte, toggle and count.

That's what I mean. He said he didn't cut dmesg.


> As toggle and count still outputs some numbers we will see that many
> line. Without toggle and count there is likely only one debug line
> seen as output is piped through uniq which drops similar lines.
>
>>> I copy & pasted here relevant lines from the em28xx driver. Maybe you
>>> could now see why code is wrong - why the extended address byte is set
>>> as to scancode mistakenly. Look especially care following variables:
>>> msg[1], msg[2], poll_result->rc_address and poll_result.rc_data[0]
>>>
>>> static int em2874_polling_getkey()
>>> {
>>> rc = dev->em28xx_read_reg_req_len(dev, 0, EM2874_R51_IR, msg,
>>> sizeof(msg));
>>>
>>> /* Remote Control Address (Reg 0x52) */
>>> poll_result->rc_address = msg[1];
>>>
>>> /* Remote Control Data (Reg 0x53-55) */
>>> poll_result->rc_data[0] = msg[2];
>>> poll_result->rc_data[1] = msg[3];
>>> poll_result->rc_data[2] = msg[4];
>>> }
>>>
>>
>> You missed the relevant part of the code:
>>
>> static int em2874_polling_getkey()
>> {
>> ...
>>      /* Infrared read count (Reg 0x51[6:0] */
>>      poll_result->read_count = (msg[0] & 0x7f);
>> ...
>> }
>>
>>
>>>
>>>
>>> static void em28xx_ir_handle_key()
>>> {
>>> dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
>>>      poll_result.toggle_bit, poll_result.read_count,
>>>      poll_result.rc_address, poll_result.rc_data[0]);
>>> }
>>>
>>
>> Same here, you missed the if () statement:
>>
>> static void em28xx_ir_handle_key(struct em28xx_IR *ir)
>> {
>> ...
>>      if (unlikely(poll_result.read_count != ir->last_readcount)) {
>>          dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n",
>> __func__,
>>              poll_result.toggle_bit, poll_result.read_count,
>>              poll_result.rc_address, poll_result.rc_data[0]);
>> ...
>> }
>>
>>
>> It doesn't matter which format the scancode (4 bytes) has, a message
>> should be printed in any case.
>> But according to Matthew, that doesn't happen. Hence, the
>> poll_result.read_count != ir->last_readcount must be the problem.
>
> I don't see which messages are missing.
>
> I think read_count is not incremented in case NEC 16bit checksum fails
> - hw just discards whole code => read_count not increase => no debug.
> For my tests there was always 81/01 when key was pressed and 00 when
> no key pressed (as seen also logs I posted yesterday).

I don't know, I don't have the data sheet, I don't have the hardware and
I didn't make the test myself.
If you are sure you can declare it working, fine.

Care to fix the tuner issues ?

Regards,
Frank

>
>>> I am about 99% sure Mauro's patch works correctly for Matthews device.
>>>
>>
>> If Matthew didn't make any mistakes, I can't see how these patches can
>> make it work. Which doesn't mean that they don't make sense.
>>
>>
>> Matthew, could you please validate your test results and try Mauros
>> patches ?
>> If it doesn't work, please create another USB-log.
>>
>>
>>> Maybe you missed point hardware returns different format in case of
>>> 32bit and 16bit values. If it is 16bit mode it return only 2 bytes and
>>> if 32bit mode it returns 4 bytes?
>>>
>>
>> No.
>>
>>
>> Regards,
>> Frank
>
> regards
> Antti
>

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>> Matthew, could you please validate your test results and try Mauros
>> patches ? If it doesn't work, please create another USB-log.
>>

Sorry it took me so long to test the patch, but the results look 
promising, I actually got various keycodes!

dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt

evtest was also generating output

Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 
61d618e7
Event: time 1355705906.950551, -------------- SYN_REPORT ------------

This is the current patch I'm using: 
http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt

What needs to be done to generate a keymap file?

Is there anything I can collect or try to do, to get channel scanning 
working?

Just let me know what you need me to do. I really appreciate all the help!

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>> Matthew, could you please validate your test results and try Mauros
>>> patches ? If it doesn't work, please create another USB-log.
>>>
>
> Sorry it took me so long to test the patch, but the results look
> promising, I actually got various keycodes!
>
> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>
> evtest was also generating output
>
> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value
> 61d618e7
> Event: time 1355705906.950551, -------------- SYN_REPORT ------------
>
> This is the current patch I'm using:
> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>
> What needs to be done to generate a keymap file?
>
> Is there anything I can collect or try to do, to get channel scanning
> working?
>
> Just let me know what you need me to do. I really appreciate all the help!

You don't need to do nothing as that remote is already there. Just 
ensure buttons are same and we are happy.
http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37

RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order 
to load correct keytable by default. You could test it easily, just add 
following definition

.ir_codes = RC_MAP_MSI_DIGIVOX_III,

to em28xx-cards.c board config and it is all.

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/16/2012 08:26 PM, Antti Palosaari wrote:
> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>> Matthew, could you please validate your test results and try Mauros
>>>> patches ? If it doesn't work, please create another USB-log.
>>>>
>>
>> Sorry it took me so long to test the patch, but the results look
>> promising, I actually got various keycodes!
>>
>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>
>> evtest was also generating output
>>
>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value
>> 61d618e7
>> Event: time 1355705906.950551, -------------- SYN_REPORT ------------
>>
>> This is the current patch I'm using:
>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>
>> What needs to be done to generate a keymap file?
>>
>> Is there anything I can collect or try to do, to get channel scanning
>> working?
>>
>> Just let me know what you need me to do. I really appreciate all the
>> help!
>
> You don't need to do nothing as that remote is already there. Just
> ensure buttons are same and we are happy.
> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>
>
> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order
> to load correct keytable by default. You could test it easily, just add
> following definition
>
> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>
> to em28xx-cards.c board config and it is all.
>
> regards
> Antti
>
Maybe I'm missing something but these are different key codes and lengths.

tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
11
tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
9

As I understand it, this was the whole reason for the patches that 
Mauros wrote.

Regards,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
> On 12/16/2012 08:26 PM, Antti Palosaari wrote:
>> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>>> Matthew, could you please validate your test results and try Mauros
>>>>> patches ? If it doesn't work, please create another USB-log.
>>>>>
>>>
>>> Sorry it took me so long to test the patch, but the results look
>>> promising, I actually got various keycodes!
>>>
>>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>
>>> evtest was also generating output
>>>
>>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value
>>> 61d618e7
>>> Event: time 1355705906.950551, -------------- SYN_REPORT ------------
>>>
>>> This is the current patch I'm using:
>>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>
>>> What needs to be done to generate a keymap file?
>>>
>>> Is there anything I can collect or try to do, to get channel scanning
>>> working?
>>>
>>> Just let me know what you need me to do. I really appreciate all the
>>> help!
>>
>> You don't need to do nothing as that remote is already there. Just
>> ensure buttons are same and we are happy.
>> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>>
>>
>>
>> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order
>> to load correct keytable by default. You could test it easily, just add
>> following definition
>>
>> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>>
>> to em28xx-cards.c board config and it is all.
>>
>> regards
>> Antti
>>
> Maybe I'm missing something but these are different key codes and lengths.
>
> tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
> 11
> tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
> 9

0x61d643bc == 0x61d643
0x61d601fe == 0x61d601

Those are same codes, other (debug) is just 32bit full format. Last byte 
in that case is dropped out as it is used for parity check - formula: DD 
== ~DD

> As I understand it, this was the whole reason for the patches that
> Mauros wrote.

Nope, the reason was it didn't support 32bit at all.

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/17/2012 11:33 AM, Antti Palosaari wrote:
> On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
>> On 12/16/2012 08:26 PM, Antti Palosaari wrote:
>>> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>>>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>>>> Matthew, could you please validate your test results and try Mauros
>>>>>> patches ? If it doesn't work, please create another USB-log.
>>>>>>
>>>>
>>>> Sorry it took me so long to test the patch, but the results look
>>>> promising, I actually got various keycodes!
>>>>
>>>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>
>>>> evtest was also generating output
>>>>
>>>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN),
>>>> value
>>>> 61d618e7
>>>> Event: time 1355705906.950551, -------------- SYN_REPORT ------------
>>>>
>>>> This is the current patch I'm using:
>>>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>
>>>> What needs to be done to generate a keymap file?
>>>>
>>>> Is there anything I can collect or try to do, to get channel scanning
>>>> working?
>>>>
>>>> Just let me know what you need me to do. I really appreciate all the
>>>> help!
>>>
>>> You don't need to do nothing as that remote is already there. Just
>>> ensure buttons are same and we are happy.
>>> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>>>
>>>
>>>
>>>
>>> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order
>>> to load correct keytable by default. You could test it easily, just add
>>> following definition
>>>
>>> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>>>
>>> to em28xx-cards.c board config and it is all.
>>>
>>> regards
>>> Antti
>>>
>> Maybe I'm missing something but these are different key codes and
>> lengths.
>>
>> tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
>> 11
>> tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
>> 9
>
> 0x61d643bc == 0x61d643
> 0x61d601fe == 0x61d601
>
> Those are same codes, other (debug) is just 32bit full format. Last byte
> in that case is dropped out as it is used for parity check - formula: DD
> == ~DD
>
>> As I understand it, this was the whole reason for the patches that
>> Mauros wrote.
>
> Nope, the reason was it didn't support 32bit at all.

I looked the patch and it seems like it should store and print 24bit 
scancode for your remote. Maybe you didn't set default remote end it 
fall back to unknown remote protocol which stores all bytes. Or some 
other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if 
it does not output numbers there must be a bug. I am too lazy to test it 
currently.

regards
Antti


-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/17/2012 06:08 AM, Antti Palosaari wrote:
> On 12/17/2012 11:33 AM, Antti Palosaari wrote:
>> On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
>>> On 12/16/2012 08:26 PM, Antti Palosaari wrote:
>>>> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>>>>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>>>>> Matthew, could you please validate your test results and try Mauros
>>>>>>> patches ? If it doesn't work, please create another USB-log.
>>>>>>>
>>>>>
>>>>> Sorry it took me so long to test the patch, but the results look
>>>>> promising, I actually got various keycodes!
>>>>>
>>>>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>
>>>>> evtest was also generating output
>>>>>
>>>>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN),
>>>>> value
>>>>> 61d618e7
>>>>> Event: time 1355705906.950551, -------------- SYN_REPORT ------------
>>>>>
>>>>> This is the current patch I'm using:
>>>>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>
>>>>> What needs to be done to generate a keymap file?
>>>>>
>>>>> Is there anything I can collect or try to do, to get channel scanning
>>>>> working?
>>>>>
>>>>> Just let me know what you need me to do. I really appreciate all the
>>>>> help!
>>>>
>>>> You don't need to do nothing as that remote is already there. Just
>>>> ensure buttons are same and we are happy.
>>>> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order
>>>> to load correct keytable by default. You could test it easily, just add
>>>> following definition
>>>>
>>>> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>>>>
>>>> to em28xx-cards.c board config and it is all.
>>>>
>>>> regards
>>>> Antti
>>>>
>>> Maybe I'm missing something but these are different key codes and
>>> lengths.
>>>
>>> tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
>>> 11
>>> tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
>>> 9
>>
>> 0x61d643bc == 0x61d643
>> 0x61d601fe == 0x61d601
>>
>> Those are same codes, other (debug) is just 32bit full format. Last byte
>> in that case is dropped out as it is used for parity check - formula: DD
>> == ~DD
>>
>>> As I understand it, this was the whole reason for the patches that
>>> Mauros wrote.
>>
>> Nope, the reason was it didn't support 32bit at all.
>
> I looked the patch and it seems like it should store and print 24bit
> scancode for your remote. Maybe you didn't set default remote end it
> fall back to unknown remote protocol which stores all bytes. Or some
> other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if
> it does not output numbers there must be a bug. I am too lazy to test it
> currently.
>
> regards
> Antti
>
>
I am using the RC_MAP_MSI_DIGIVOX_III mapping

+ .ir_codes     = RC_MAP_MSI_DIGIVOX_III,
http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch

Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/17/2012 01:17 PM, Matthew Gyurgyik wrote:
> On 12/17/2012 06:08 AM, Antti Palosaari wrote:
>> On 12/17/2012 11:33 AM, Antti Palosaari wrote:
>>> On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
>>>> On 12/16/2012 08:26 PM, Antti Palosaari wrote:
>>>>> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>>>>>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>>>>>> Matthew, could you please validate your test results and try Mauros
>>>>>>>> patches ? If it doesn't work, please create another USB-log.
>>>>>>>>
>>>>>>
>>>>>> Sorry it took me so long to test the patch, but the results look
>>>>>> promising, I actually got various keycodes!
>>>>>>
>>>>>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>
>>>>>> evtest was also generating output
>>>>>>
>>>>>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN),
>>>>>> value
>>>>>> 61d618e7
>>>>>> Event: time 1355705906.950551, -------------- SYN_REPORT ------------
>>>>>>
>>>>>> This is the current patch I'm using:
>>>>>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>
>>>>>> What needs to be done to generate a keymap file?
>>>>>>
>>>>>> Is there anything I can collect or try to do, to get channel scanning
>>>>>> working?
>>>>>>
>>>>>> Just let me know what you need me to do. I really appreciate all the
>>>>>> help!
>>>>>
>>>>> You don't need to do nothing as that remote is already there. Just
>>>>> ensure buttons are same and we are happy.
>>>>> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order
>>>>> to load correct keytable by default. You could test it easily, just
>>>>> add
>>>>> following definition
>>>>>
>>>>> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>>>>>
>>>>> to em28xx-cards.c board config and it is all.
>>>>>
>>>>> regards
>>>>> Antti
>>>>>
>>>> Maybe I'm missing something but these are different key codes and
>>>> lengths.
>>>>
>>>> tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
>>>> 11
>>>> tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
>>>> 9
>>>
>>> 0x61d643bc == 0x61d643
>>> 0x61d601fe == 0x61d601
>>>
>>> Those are same codes, other (debug) is just 32bit full format. Last byte
>>> in that case is dropped out as it is used for parity check - formula: DD
>>> == ~DD
>>>
>>>> As I understand it, this was the whole reason for the patches that
>>>> Mauros wrote.
>>>
>>> Nope, the reason was it didn't support 32bit at all.
>>
>> I looked the patch and it seems like it should store and print 24bit
>> scancode for your remote. Maybe you didn't set default remote end it
>> fall back to unknown remote protocol which stores all bytes. Or some
>> other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if
>> it does not output numbers there must be a bug. I am too lazy to test it
>> currently.
>>
>> regards
>> Antti
>>
>>
> I am using the RC_MAP_MSI_DIGIVOX_III mapping
>
> + .ir_codes     = RC_MAP_MSI_DIGIVOX_III,
> http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch

I tested Mauros patch with nanoStick T2 290e, using 24bit NEC remote - 
worked fine. Your patch is hard to read as it contains that remote patch 
too. But what I looked one difference which look suspicious - it is that:
.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,

could you remove and test?

If it is really that one, then there is a bug in Mauros patches and it 
breaks all devices having NEC remote mapped currently.

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em 17-12-2012 10:30, Antti Palosaari escreveu:
> On 12/17/2012 01:17 PM, Matthew Gyurgyik wrote:
>> On 12/17/2012 06:08 AM, Antti Palosaari wrote:
>>> On 12/17/2012 11:33 AM, Antti Palosaari wrote:
>>>> On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
>>>>> On 12/16/2012 08:26 PM, Antti Palosaari wrote:
>>>>>> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>>>>>>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>>>>>>> Matthew, could you please validate your test results and try Mauros
>>>>>>>>> patches ? If it doesn't work, please create another USB-log.
>>>>>>>>>
>>>>>>>
>>>>>>> Sorry it took me so long to test the patch, but the results look
>>>>>>> promising, I actually got various keycodes!
>>>>>>>
>>>>>>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>>
>>>>>>> evtest was also generating output
>>>>>>>
>>>>>>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN),
>>>>>>> value
>>>>>>> 61d618e7
>>>>>>> Event: time 1355705906.950551, -------------- SYN_REPORT ------------
>>>>>>>
>>>>>>> This is the current patch I'm using:
>>>>>>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>>
>>>>>>> What needs to be done to generate a keymap file?
>>>>>>>
>>>>>>> Is there anything I can collect or try to do, to get channel scanning
>>>>>>> working?
>>>>>>>
>>>>>>> Just let me know what you need me to do. I really appreciate all the
>>>>>>> help!
>>>>>>
>>>>>> You don't need to do nothing as that remote is already there. Just
>>>>>> ensure buttons are same and we are happy.
>>>>>> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order
>>>>>> to load correct keytable by default. You could test it easily, just
>>>>>> add
>>>>>> following definition
>>>>>>
>>>>>> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>>>>>>
>>>>>> to em28xx-cards.c board config and it is all.
>>>>>>
>>>>>> regards
>>>>>> Antti
>>>>>>
>>>>> Maybe I'm missing something but these are different key codes and
>>>>> lengths.
>>>>>
>>>>> tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
>>>>> 11
>>>>> tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
>>>>> 9
>>>>
>>>> 0x61d643bc == 0x61d643
>>>> 0x61d601fe == 0x61d601
>>>>
>>>> Those are same codes, other (debug) is just 32bit full format. Last byte
>>>> in that case is dropped out as it is used for parity check - formula: DD
>>>> == ~DD
>>>>
>>>>> As I understand it, this was the whole reason for the patches that
>>>>> Mauros wrote.
>>>>
>>>> Nope, the reason was it didn't support 32bit at all.
>>>
>>> I looked the patch and it seems like it should store and print 24bit
>>> scancode for your remote. Maybe you didn't set default remote end it
>>> fall back to unknown remote protocol which stores all bytes. Or some
>>> other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if
>>> it does not output numbers there must be a bug. I am too lazy to test it
>>> currently.
>>>
>>> regards
>>> Antti
>>>
>>>
>> I am using the RC_MAP_MSI_DIGIVOX_III mapping
>>
>> + .ir_codes     = RC_MAP_MSI_DIGIVOX_III,
>> http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch
>
> I tested Mauros patch with nanoStick T2 290e, using 24bit NEC remote - worked fine. Your patch is hard to read as it contains that remote patch too. But what I looked one difference which look suspicious - it is that:
> .xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
>
> could you remove and test?
>
> If it is really that one, then there is a bug in Mauros patches and it breaks all devices having NEC remote mapped currently.

The em28xx-input should not be touching on xclk frequency changes. Some devices
require specific settings there in order to work, and mangling it is a very
bad idea.

Btw, I don't think that are there any bugs with regards to that, as we use
em28xx_write_reg_bits():

/*
  * em28xx_write_reg_bits()
  * sets only some bits (specified by bitmask) of a register, by first reading
  * the actual value
  */
int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val,
				 u8 bitmask)
{
...
	newval = (((u8) oldval) & ~bitmask) | (val & bitmask);

	return em28xx_write_regs(dev, reg, &newval, 1);
}

 From patch 2/2:

+	if (*rc_type & RC_BIT_RC5) {
+		dev->board.xclk |= EM28XX_XCLK_IR_RC5_MODE;
+		ir->full_code = 1;
+		*rc_type = RC_BIT_RC5;
+	} else if (*rc_type & RC_BIT_NEC) {
+		dev->board.xclk &= ~EM28XX_XCLK_IR_RC5_MODE;
+		ir->full_code = 1;
+		*rc_type = RC_BIT_NEC;
+	} else if (*rc_type & RC_BIT_UNKNOWN) {
+		*rc_type = RC_BIT_UNKNOWN;
+	} else {
+		*rc_type = ir->rc_type;
+		return -EINVAL;
+	}
+	ir->get_key = default_polling_getkey;
+	em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev->board.xclk,
+			      EM28XX_XCLK_IR_RC5_MODE);

(this is for em2860 code, but em2874_ir_change_protocol() has a similar
logic - the only exception is the support for RC6_0 as well)

This line:
  	em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev->board.xclk,
  			      EM28XX_XCLK_IR_RC5_MODE);

Warrants that only the EM28XX_XCLK_IR_RC5_MODE bit is affected.

So, except if I'm missing something, the implementation looks correct
on my eyes.

Regards,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Hi Matthew,

Em 17-12-2012 09:17, Matthew Gyurgyik escreveu:
> On 12/17/2012 06:08 AM, Antti Palosaari wrote:
>> On 12/17/2012 11:33 AM, Antti Palosaari wrote:
>>> On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
>>>> On 12/16/2012 08:26 PM, Antti Palosaari wrote:
>>>>> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>>>>>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>>>>>> Matthew, could you please validate your test results and try Mauros
>>>>>>>> patches ? If it doesn't work, please create another USB-log.
>>>>>>>>
>>>>>>
>>>>>> Sorry it took me so long to test the patch, but the results look
>>>>>> promising, I actually got various keycodes!
>>>>>>
>>>>>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>
>>>>>> evtest was also generating output
>>>>>>
>>>>>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN),
>>>>>> value
>>>>>> 61d618e7
>>>>>> Event: time 1355705906.950551, -------------- SYN_REPORT ------------
>>>>>>
>>>>>> This is the current patch I'm using:
>>>>>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>
>>>>>> What needs to be done to generate a keymap file?
>>>>>>
>>>>>> Is there anything I can collect or try to do, to get channel scanning
>>>>>> working?
>>>>>>
>>>>>> Just let me know what you need me to do. I really appreciate all the
>>>>>> help!
>>>>>
>>>>> You don't need to do nothing as that remote is already there. Just
>>>>> ensure buttons are same and we are happy.
>>>>> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order
>>>>> to load correct keytable by default. You could test it easily, just add
>>>>> following definition
>>>>>
>>>>> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>>>>>
>>>>> to em28xx-cards.c board config and it is all.
>>>>>
>>>>> regards
>>>>> Antti
>>>>>
>>>> Maybe I'm missing something but these are different key codes and
>>>> lengths.
>>>>
>>>> tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
>>>> 11
>>>> tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
>>>> 9
>>>
>>> 0x61d643bc == 0x61d643
>>> 0x61d601fe == 0x61d601
>>>
>>> Those are same codes, other (debug) is just 32bit full format. Last byte
>>> in that case is dropped out as it is used for parity check - formula: DD
>>> == ~DD
>>>
>>>> As I understand it, this was the whole reason for the patches that
>>>> Mauros wrote.
>>>
>>> Nope, the reason was it didn't support 32bit at all.
>>
>> I looked the patch and it seems like it should store and print 24bit
>> scancode for your remote. Maybe you didn't set default remote end it
>> fall back to unknown remote protocol which stores all bytes. Or some
>> other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if
>> it does not output numbers there must be a bug. I am too lazy to test it
>> currently.
>>
>> regards
>> Antti
>>
>>
> I am using the RC_MAP_MSI_DIGIVOX_III mapping
>
> + .ir_codes     = RC_MAP_MSI_DIGIVOX_III,
> http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch

 From this log:
	http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt

You clearly have a "standard" NEC-extended IR - e. g. 24 bits per scancode,
16 bits for address, 8 bits for command.

Instead of using evtest, I really recomend you to use ir-keytable
(part of v4l-utils package). You can compile it directly from our
git tree: http://git.linuxtv.org/v4l-utils.git with:
	$ autoreconf -vfi
	$ ./configure
	$ make
	# make install

The version there has a few updates to provide a more complete report.

In order to use it in test mode, you can just do:
	# ir-keycode -t

If your IR is at rc0 (otherwise, you'll need to use the "-s rc1" parameter).

It should print all events produced by an input device, including
the scancodes (EV_MSC) and keystrokes (EV_KEY).

One question: are you compiling a 32 bits or a 64 bits kernel? The is/were
a bug with gcc and switch() when a 64 bits int is used on switch. Maybe
we'll need to change the switch at the nec handling by a series of IFs
due to such bug.

Regards,
Mauro


>
> Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/17/2012 11:14 AM, Mauro Carvalho Chehab wrote:
> Hi Matthew,
>
> Em 17-12-2012 09:17, Matthew Gyurgyik escreveu:
>> On 12/17/2012 06:08 AM, Antti Palosaari wrote:
>>> On 12/17/2012 11:33 AM, Antti Palosaari wrote:
>>>> On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
>>>>> On 12/16/2012 08:26 PM, Antti Palosaari wrote:
>>>>>> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>>>>>>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>>>>>>> Matthew, could you please validate your test results and try
>>>>>>>>> Mauros
>>>>>>>>> patches ? If it doesn't work, please create another USB-log.
>>>>>>>>>
>>>>>>>
>>>>>>> Sorry it took me so long to test the patch, but the results look
>>>>>>> promising, I actually got various keycodes!
>>>>>>>
>>>>>>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>>
>>>>>>> evtest was also generating output
>>>>>>>
>>>>>>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN),
>>>>>>> value
>>>>>>> 61d618e7
>>>>>>> Event: time 1355705906.950551, -------------- SYN_REPORT
>>>>>>> ------------
>>>>>>>
>>>>>>> This is the current patch I'm using:
>>>>>>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>>
>>>>>>> What needs to be done to generate a keymap file?
>>>>>>>
>>>>>>> Is there anything I can collect or try to do, to get channel
>>>>>>> scanning
>>>>>>> working?
>>>>>>>
>>>>>>> Just let me know what you need me to do. I really appreciate all the
>>>>>>> help!
>>>>>>
>>>>>> You don't need to do nothing as that remote is already there. Just
>>>>>> ensure buttons are same and we are happy.
>>>>>> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in
>>>>>> order
>>>>>> to load correct keytable by default. You could test it easily,
>>>>>> just add
>>>>>> following definition
>>>>>>
>>>>>> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>>>>>>
>>>>>> to em28xx-cards.c board config and it is all.
>>>>>>
>>>>>> regards
>>>>>> Antti
>>>>>>
>>>>> Maybe I'm missing something but these are different key codes and
>>>>> lengths.
>>>>>
>>>>> tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
>>>>> 11
>>>>> tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
>>>>> 9
>>>>
>>>> 0x61d643bc == 0x61d643
>>>> 0x61d601fe == 0x61d601
>>>>
>>>> Those are same codes, other (debug) is just 32bit full format. Last
>>>> byte
>>>> in that case is dropped out as it is used for parity check -
>>>> formula: DD
>>>> == ~DD
>>>>
>>>>> As I understand it, this was the whole reason for the patches that
>>>>> Mauros wrote.
>>>>
>>>> Nope, the reason was it didn't support 32bit at all.
>>>
>>> I looked the patch and it seems like it should store and print 24bit
>>> scancode for your remote. Maybe you didn't set default remote end it
>>> fall back to unknown remote protocol which stores all bytes. Or some
>>> other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if
>>> it does not output numbers there must be a bug. I am too lazy to test it
>>> currently.
>>>
>>> regards
>>> Antti
>>>
>>>
>> I am using the RC_MAP_MSI_DIGIVOX_III mapping
>>
>> + .ir_codes     = RC_MAP_MSI_DIGIVOX_III,
>> http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch
>
>  From this log:
>      http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>
> You clearly have a "standard" NEC-extended IR - e. g. 24 bits per scancode,
> 16 bits for address, 8 bits for command.
>
> Instead of using evtest, I really recomend you to use ir-keytable
> (part of v4l-utils package). You can compile it directly from our
> git tree: http://git.linuxtv.org/v4l-utils.git with:
>      $ autoreconf -vfi
>      $ ./configure
>      $ make
>      # make install
>
> The version there has a few updates to provide a more complete report.
>
> In order to use it in test mode, you can just do:
>      # ir-keycode -t
>
> If your IR is at rc0 (otherwise, you'll need to use the "-s rc1"
> parameter).
>
> It should print all events produced by an input device, including
> the scancodes (EV_MSC) and keystrokes (EV_KEY).
>
> One question: are you compiling a 32 bits or a 64 bits kernel? The is/were
> a bug with gcc and switch() when a 64 bits int is used on switch. Maybe
> we'll need to change the switch at the nec handling by a series of IFs
> due to such bug.
>
I am compiling a 64 bit kernel.

I attempted to build a new kernel, however I am running into some 
difficulties. With the upcoming holiday I probably won't be able to get 
test results until the beginning of January, due to not having access to 
my PC. I hope this is ok.

> Regards,
> Mauro
>
>
>>
>> Matthew
>

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/17/2012 11:14 AM, Mauro Carvalho Chehab wrote:
> Hi Matthew,
>
> Em 17-12-2012 09:17, Matthew Gyurgyik escreveu:
>> On 12/17/2012 06:08 AM, Antti Palosaari wrote:
>>> On 12/17/2012 11:33 AM, Antti Palosaari wrote:
>>>> On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
>>>>> On 12/16/2012 08:26 PM, Antti Palosaari wrote:
>>>>>> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>>>>>>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>>>>>>> Matthew, could you please validate your test results and try
>>>>>>>>> Mauros
>>>>>>>>> patches ? If it doesn't work, please create another USB-log.
>>>>>>>>>
>>>>>>>
>>>>>>> Sorry it took me so long to test the patch, but the results look
>>>>>>> promising, I actually got various keycodes!
>>>>>>>
>>>>>>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>>
>>>>>>> evtest was also generating output
>>>>>>>
>>>>>>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN),
>>>>>>> value
>>>>>>> 61d618e7
>>>>>>> Event: time 1355705906.950551, -------------- SYN_REPORT
>>>>>>> ------------
>>>>>>>
>>>>>>> This is the current patch I'm using:
>>>>>>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>>
>>>>>>> What needs to be done to generate a keymap file?
>>>>>>>
>>>>>>> Is there anything I can collect or try to do, to get channel
>>>>>>> scanning
>>>>>>> working?
>>>>>>>
>>>>>>> Just let me know what you need me to do. I really appreciate all the
>>>>>>> help!
>>>>>>
>>>>>> You don't need to do nothing as that remote is already there. Just
>>>>>> ensure buttons are same and we are happy.
>>>>>> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in
>>>>>> order
>>>>>> to load correct keytable by default. You could test it easily,
>>>>>> just add
>>>>>> following definition
>>>>>>
>>>>>> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>>>>>>
>>>>>> to em28xx-cards.c board config and it is all.
>>>>>>
>>>>>> regards
>>>>>> Antti
>>>>>>
>>>>> Maybe I'm missing something but these are different key codes and
>>>>> lengths.
>>>>>
>>>>> tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
>>>>> 11
>>>>> tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
>>>>> 9
>>>>
>>>> 0x61d643bc == 0x61d643
>>>> 0x61d601fe == 0x61d601
>>>>
>>>> Those are same codes, other (debug) is just 32bit full format. Last
>>>> byte
>>>> in that case is dropped out as it is used for parity check -
>>>> formula: DD
>>>> == ~DD
>>>>
>>>>> As I understand it, this was the whole reason for the patches that
>>>>> Mauros wrote.
>>>>
>>>> Nope, the reason was it didn't support 32bit at all.
>>>
>>> I looked the patch and it seems like it should store and print 24bit
>>> scancode for your remote. Maybe you didn't set default remote end it
>>> fall back to unknown remote protocol which stores all bytes. Or some
>>> other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if
>>> it does not output numbers there must be a bug. I am too lazy to test it
>>> currently.
>>>
>>> regards
>>> Antti
>>>
>>>
>> I am using the RC_MAP_MSI_DIGIVOX_III mapping
>>
>> + .ir_codes     = RC_MAP_MSI_DIGIVOX_III,
>> http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch
>
>  From this log:
>      http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>
> You clearly have a "standard" NEC-extended IR - e. g. 24 bits per scancode,
> 16 bits for address, 8 bits for command.
>
> Instead of using evtest, I really recomend you to use ir-keytable
> (part of v4l-utils package). You can compile it directly from our
> git tree: http://git.linuxtv.org/v4l-utils.git with:
>      $ autoreconf -vfi
>      $ ./configure
>      $ make
>      # make install
>
> The version there has a few updates to provide a more complete report.
>
> In order to use it in test mode, you can just do:
>      # ir-keycode -t
>
> If your IR is at rc0 (otherwise, you'll need to use the "-s rc1"
> parameter).

Here is the report (I pressed every key on the remote): 
http://pyther.net/a/digivox_atsc/dec17/ir-keytables.txt

>
> It should print all events produced by an input device, including
> the scancodes (EV_MSC) and keystrokes (EV_KEY).
>
> One question: are you compiling a 32 bits or a 64 bits kernel? The is/were
> a bug with gcc and switch() when a 64 bits int is used on switch. Maybe
> we'll need to change the switch at the nec handling by a series of IFs
> due to such bug.

I am compiling a 64 bit kernel.

>
> Regards,
> Mauro
>
>

I can test patches Tue and Wed this week. Afterwards, I probably won't 
be able to test anything until Dec 28th/29th as I will be away from my 
workstation.

In regards to my issue compiling my kernel, it helps if I include 
devtmpfs. :)

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
> I can test patches Tue and Wed this week. Afterwards, I probably won't
> be able to test anything until Dec 28th/29th as I will be away from my
> workstation.
>
> In regards to my issue compiling my kernel, it helps if I include
> devtmpfs. :)

Matthew, test? Both remote and television.

http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/HU345-Q

regards
Antti
-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 01/02/2013 03:59 PM, Antti Palosaari wrote:
> On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
>> I can test patches Tue and Wed this week. Afterwards, I probably won't
>> be able to test anything until Dec 28th/29th as I will be away from my
>> workstation.
>>
>> In regards to my issue compiling my kernel, it helps if I include
>> devtmpfs. :)
>
> Matthew, test? Both remote and television.
>
> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/HU345-Q
>
> regards
> Antti


So using the HU345-Q branch I get the following results

Remote:

Using evtest it looks like all the key codes register correctly. (KEY_1, 
KEY_YELLOW, KEY_VOLUMEUP, etc...)

However, ir_keytable fails

[root@tux bin]# ./ir-keytable -t
Not found device rc0

Tunning:

I did a basic test with mplayer and tunning worked. I'll have to do more 
testing.

Scanning:

Running a scan resulted in a kernel panic.

Scan command: scan -A 2 -t 1 
/usr/share/dvb/atsc/us-Cable-Standard-center-frequencies-QAM256 > 
~/channels_msidigivox.conf

Kernel Messages: http://pyther.net/a/digivox_atsc/jan02/kernel_log.txt

Let me know what additional info I can provide. As always, I appreciate 
the help!

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 01/02/2013 09:53 PM, Matthew Gyurgyik wrote:
> On 01/02/2013 03:59 PM, Antti Palosaari wrote:
>> On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
>>> I can test patches Tue and Wed this week. Afterwards, I probably won't
>>> be able to test anything until Dec 28th/29th as I will be away from my
>>> workstation.
>>>
>>> In regards to my issue compiling my kernel, it helps if I include
>>> devtmpfs. :)
>>
>> Matthew, test? Both remote and television.
>>
>> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/HU345-Q
>>
>> regards
>> Antti
>
>
> So using the HU345-Q branch I get the following results
>
> Remote:
>
> Using evtest it looks like all the key codes register correctly. (KEY_1,
> KEY_YELLOW, KEY_VOLUMEUP, etc...)
>
> However, ir_keytable fails
>
> [root@tux bin]# ./ir-keytable -t
> Not found device rc0
>
> Tunning:
>
> I did a basic test with mplayer and tunning worked. I'll have to do more
> testing.
>
> Scanning:
>
> Running a scan resulted in a kernel panic.
>
> Scan command: scan -A 2 -t 1
> /usr/share/dvb/atsc/us-Cable-Standard-center-frequencies-QAM256 >
> ~/channels_msidigivox.conf
>
> Kernel Messages: http://pyther.net/a/digivox_atsc/jan02/kernel_log.txt
>
> Let me know what additional info I can provide. As always, I appreciate
> the help!
>
> Thanks,
> Matthew
>


Antti,

Is there any follow up testing I could do? Is there any additional 
information you need from me.

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 01/20/2013 04:40 PM, Matthew Gyurgyik wrote:
> On 01/02/2013 09:53 PM, Matthew Gyurgyik wrote:
>> On 01/02/2013 03:59 PM, Antti Palosaari wrote:
>>> On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
>>>> I can test patches Tue and Wed this week. Afterwards, I probably won't
>>>> be able to test anything until Dec 28th/29th as I will be away from my
>>>> workstation.
>>>>
>>>> In regards to my issue compiling my kernel, it helps if I include
>>>> devtmpfs. :)
>>>
>>> Matthew, test? Both remote and television.
>>>
>>> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/HU345-Q
>>>
>>> regards
>>> Antti
>>
>>
>> So using the HU345-Q branch I get the following results
>>
>> Remote:
>>
>> Using evtest it looks like all the key codes register correctly. (KEY_1,
>> KEY_YELLOW, KEY_VOLUMEUP, etc...)
>>
>> However, ir_keytable fails
>>
>> [root@tux bin]# ./ir-keytable -t
>> Not found device rc0
>>
>> Tunning:
>>
>> I did a basic test with mplayer and tunning worked. I'll have to do more
>> testing.
>>
>> Scanning:
>>
>> Running a scan resulted in a kernel panic.
>>
>> Scan command: scan -A 2 -t 1
>> /usr/share/dvb/atsc/us-Cable-Standard-center-frequencies-QAM256 >
>> ~/channels_msidigivox.conf
>>
>> Kernel Messages: http://pyther.net/a/digivox_atsc/jan02/kernel_log.txt
>>
>> Let me know what additional info I can provide. As always, I appreciate
>> the help!
>>
>> Thanks,
>> Matthew
>>
>
>
> Antti,
>
> Is there any follow up testing I could do? Is there any additional
> information you need from me.
>
> Thanks,
> Matthew

Matthew,
Thank you for testing continuously! I looked it and for my eyes it works 
as it should (both television and remote controller as you reported). 
All those bugs you mention has no relations to that certain device. I 
think all are general em28xx driver bugs. There has been recently quite 
much changes done for the em28xx driver and probably some of those 
findings are already fixed. I am not em28xx driver expert, due to that 
it is hard to say what is wrong. I will try to make final patch soon and 
after your test it could be sent to the mainline.

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 01/20/2013 12:46 PM, Antti Palosaari wrote:
> On 01/20/2013 04:40 PM, Matthew Gyurgyik wrote:
>> On 01/02/2013 09:53 PM, Matthew Gyurgyik wrote:
>>> On 01/02/2013 03:59 PM, Antti Palosaari wrote:
>>>> On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
>>>>> I can test patches Tue and Wed this week. Afterwards, I probably won't
>>>>> be able to test anything until Dec 28th/29th as I will be away from my
>>>>> workstation.
>>>>>
>>>>> In regards to my issue compiling my kernel, it helps if I include
>>>>> devtmpfs. :)
>>>>
>>>> Matthew, test? Both remote and television.
>>>>
>>>> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/HU345-Q
>>>>
>>>>
>>>> regards
>>>> Antti
>>>
>>>
>>> So using the HU345-Q branch I get the following results
>>>
>>> Remote:
>>>
>>> Using evtest it looks like all the key codes register correctly. (KEY_1,
>>> KEY_YELLOW, KEY_VOLUMEUP, etc...)
>>>
>>> However, ir_keytable fails
>>>
>>> [root@tux bin]# ./ir-keytable -t
>>> Not found device rc0
>>>
>>> Tunning:
>>>
>>> I did a basic test with mplayer and tunning worked. I'll have to do more
>>> testing.
>>>
>>> Scanning:
>>>
>>> Running a scan resulted in a kernel panic.
>>>
>>> Scan command: scan -A 2 -t 1
>>> /usr/share/dvb/atsc/us-Cable-Standard-center-frequencies-QAM256 >
>>> ~/channels_msidigivox.conf
>>>
>>> Kernel Messages: http://pyther.net/a/digivox_atsc/jan02/kernel_log.txt
>>>
>>> Let me know what additional info I can provide. As always, I appreciate
>>> the help!
>>>
>>> Thanks,
>>> Matthew
>>>
>>
>>
>> Antti,
>>
>> Is there any follow up testing I could do? Is there any additional
>> information you need from me.
>>
>> Thanks,
>> Matthew
>
> Matthew,
> Thank you for testing continuously! I looked it and for my eyes it works
> as it should (both television and remote controller as you reported).
> All those bugs you mention has no relations to that certain device. I
> think all are general em28xx driver bugs. There has been recently quite
> much changes done for the em28xx driver and probably some of those
> findings are already fixed. I am not em28xx driver expert, due to that
> it is hard to say what is wrong. I will try to make final patch soon and
> after your test it could be sent to the mainline.
>
> regards
> Antti
>
Any update on this?

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Antti Palosaari]

On 02/17/2013 01:38 AM, Matthew Gyurgyik wrote:
> On 01/20/2013 12:46 PM, Antti Palosaari wrote:
>> On 01/20/2013 04:40 PM, Matthew Gyurgyik wrote:
>>> On 01/02/2013 09:53 PM, Matthew Gyurgyik wrote:
>>>> On 01/02/2013 03:59 PM, Antti Palosaari wrote:
>>>>> On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
>>>>>> I can test patches Tue and Wed this week. Afterwards, I probably
>>>>>> won't
>>>>>> be able to test anything until Dec 28th/29th as I will be away
>>>>>> from my
>>>>>> workstation.
>>>>>>
>>>>>> In regards to my issue compiling my kernel, it helps if I include
>>>>>> devtmpfs. :)
>>>>>
>>>>> Matthew, test? Both remote and television.
>>>>>
>>>>> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/HU345-Q
>>>>>
>>>>>
>>>>>
>>>>> regards
>>>>> Antti
>>>>
>>>>
>>>> So using the HU345-Q branch I get the following results
>>>>
>>>> Remote:
>>>>
>>>> Using evtest it looks like all the key codes register correctly.
>>>> (KEY_1,
>>>> KEY_YELLOW, KEY_VOLUMEUP, etc...)
>>>>
>>>> However, ir_keytable fails
>>>>
>>>> [root@tux bin]# ./ir-keytable -t
>>>> Not found device rc0
>>>>
>>>> Tunning:
>>>>
>>>> I did a basic test with mplayer and tunning worked. I'll have to do
>>>> more
>>>> testing.
>>>>
>>>> Scanning:
>>>>
>>>> Running a scan resulted in a kernel panic.
>>>>
>>>> Scan command: scan -A 2 -t 1
>>>> /usr/share/dvb/atsc/us-Cable-Standard-center-frequencies-QAM256 >
>>>> ~/channels_msidigivox.conf
>>>>
>>>> Kernel Messages: http://pyther.net/a/digivox_atsc/jan02/kernel_log.txt
>>>>
>>>> Let me know what additional info I can provide. As always, I appreciate
>>>> the help!
>>>>
>>>> Thanks,
>>>> Matthew
>>>>
>>>
>>>
>>> Antti,
>>>
>>> Is there any follow up testing I could do? Is there any additional
>>> information you need from me.
>>>
>>> Thanks,
>>> Matthew
>>
>> Matthew,
>> Thank you for testing continuously! I looked it and for my eyes it works
>> as it should (both television and remote controller as you reported).
>> All those bugs you mention has no relations to that certain device. I
>> think all are general em28xx driver bugs. There has been recently quite
>> much changes done for the em28xx driver and probably some of those
>> findings are already fixed. I am not em28xx driver expert, due to that
>> it is hard to say what is wrong. I will try to make final patch soon and
>> after your test it could be sent to the mainline.
>>
>> regards
>> Antti
>>
> Any update on this?
>
> Thanks,
> Matthew

I rebased it to the latest LinuxTV 3.9. There is quite a lot of changes 
done for em28xx driver so it could work. Please test.

http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/HU345-Q

regards
Antti

-- 
http://palosaari.fi/

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 02/24/2013 05:23 PM, Antti Palosaari wrote:
>
> I rebased it to the latest LinuxTV 3.9. There is quite a lot of changes
> done for em28xx driver so it could work. Please test.
>
> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/HU345-Q
>
> regards
> Antti
>

I checked out the branch and these are my results from some brief testing.

Channel scan: results in INPUT/output error

Tuning and watching a channel. With mplayer when tuning to a specific 
channel it seemed to play without issue. Occasionally when starting 
mplayer, the audio and video was way out of sync. It was if the video 
was only displaying a few frame per second.

Remote: the number keys worked as the inputed their respective value 
into my terminal. I will test the others tomorrow.

http://pyther.net/a/digivox_atsc/feb24/scan.txt
http://pyther.net/a/digivox_atsc/feb24/dmesg.txt

Thanks,
Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[David Härdeman]

On Tue, Dec 11, 2012 at 10:59:06PM +0200, Antti Palosaari wrote:
>Yes, that is. I have said it "million" times I would like to see that
>implemented as a one single 4 byte NEC, but it is currently what it
>is. What I understand David Härdeman has done some work toward that
>too, but it is not ready.

Correct. Still working on it. The main problem is providing it in
a sensibly backwards-compatible manner. I will post patches to the ML
again once it is ready.

-- 
David Härdeman

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Tue, 11 Dec 2012 21:51:34 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 10.12.2012 21:48, schrieb Antti Palosaari:
> > On 12/10/2012 09:24 PM, Frank Schäfer wrote:
> >> Am 10.12.2012 18:57, schrieb Antti Palosaari:
> >>> On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
> >>>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
> >>>>> Adding a new property to the RC profile certainly seems to be the
> >>>>> cleanest solution.
> >>>>> Do all protocols have paritiy checking ? Otherwise we could add a new
> >>>>> type RC_TYPE_NEC_NO_PARITY.
> >>>>> OTOH, introducing a new bitfield in struct rc_map might be usefull
> >>>>> for
> >>>>> other flags, too, in the future...
> >>>>
> >>>> It's probably also worth mentioning that in that mode the device
> >>>> reports four bytes, not two.  I guess perhaps if parity is ignored it
> >>>> reports the data in some other format?  You will probably have to do
> >>>> some experimentation there.
> 
> ...
> 
> >>>
> >>> Uh, current em28xx NEC implementation is locked to traditional 16 bit
> >>> NEC, where is hw checksum used.
> >>>
> >>> Implementation should be changed to more general to support 24 and 32
> >>> bit NEC too. There is multiple drivers doing already that, for example
> >>> AF9015.
> >>>
> >>
> >> Hmm... are there and documents (, links, books, ...) where I can learn
> >> more about all those RC protocols ?
> >
> > Specification comes here:
> > NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
> >
> > 1) 16bit NEC standard, 1 byte address code, 1 byte key code
> > full 4 byte code: AA BB CC DD
> > where:
> > AA = address code
> > BB = ~address code
> > CC = key code
> > DD = ~key code
> >
> > checksum:
> > AA + BB = 0xff
> > CC + DD = 0xff
> >
> > 2) 24bit NEC extended, 2 byte address code, 1 byte key code
> > full 4 byte code: AA BB CC DD
> > where:
> > AA = address code (MSB)
> > BB = address code (LSB)
> > CC = key code
> > DD = ~key code

Actually, on both above, AFAIKT, instead of "key code", the last 8
bits are called as "command code" at the specs.
> >
> > 3) 32bit NEC full, 4 byte key code
> > full 4 byte code: AA BB CC DD
> > where:
> > AA =
> > BB =
> > CC =
> > DD =
> >
> > I am not sure if there is separate parts for address and key code in
> > case of 32bit NEC. See some existing remote keytables if there is any
> > such table. It is very rare protocol. 1) and 2) are much more common.

On all 32-bits NEC IR's I tested, this is mapped as:

address code = AABBCC
command code = DD

Regards,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Thu, 13 Dec 2012 18:07:16 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> Em Tue, 11 Dec 2012 21:51:34 +0100
> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
> 
> > Am 10.12.2012 21:48, schrieb Antti Palosaari:
> > > On 12/10/2012 09:24 PM, Frank Schäfer wrote:
> > >> Am 10.12.2012 18:57, schrieb Antti Palosaari:
> > >>> On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
> > >>>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
> > >>>>> Adding a new property to the RC profile certainly seems to be the
> > >>>>> cleanest solution.
> > >>>>> Do all protocols have paritiy checking ? Otherwise we could add a new
> > >>>>> type RC_TYPE_NEC_NO_PARITY.
> > >>>>> OTOH, introducing a new bitfield in struct rc_map might be usefull
> > >>>>> for
> > >>>>> other flags, too, in the future...
> > >>>>
> > >>>> It's probably also worth mentioning that in that mode the device
> > >>>> reports four bytes, not two.  I guess perhaps if parity is ignored it
> > >>>> reports the data in some other format?  You will probably have to do
> > >>>> some experimentation there.
> > 
> > ...
> > 
> > >>>
> > >>> Uh, current em28xx NEC implementation is locked to traditional 16 bit
> > >>> NEC, where is hw checksum used.
> > >>>
> > >>> Implementation should be changed to more general to support 24 and 32
> > >>> bit NEC too. There is multiple drivers doing already that, for example
> > >>> AF9015.
> > >>>
> > >>
> > >> Hmm... are there and documents (, links, books, ...) where I can learn
> > >> more about all those RC protocols ?
> > >
> > > Specification comes here:
> > > NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
> > >
> > > 1) 16bit NEC standard, 1 byte address code, 1 byte key code
> > > full 4 byte code: AA BB CC DD
> > > where:
> > > AA = address code
> > > BB = ~address code
> > > CC = key code
> > > DD = ~key code
> > >
> > > checksum:
> > > AA + BB = 0xff
> > > CC + DD = 0xff
> > >
> > > 2) 24bit NEC extended, 2 byte address code, 1 byte key code
> > > full 4 byte code: AA BB CC DD
> > > where:
> > > AA = address code (MSB)
> > > BB = address code (LSB)
> > > CC = key code
> > > DD = ~key code
> 
> Actually, on both above, AFAIKT, instead of "key code", the last 8
> bits are called as "command code" at the specs.
> > >
> > > 3) 32bit NEC full, 4 byte key code
> > > full 4 byte code: AA BB CC DD
> > > where:
> > > AA =
> > > BB =
> > > CC =
> > > DD =
> > >
> > > I am not sure if there is separate parts for address and key code in
> > > case of 32bit NEC. See some existing remote keytables if there is any
> > > such table. It is very rare protocol. 1) and 2) are much more common.
> 
> On all 32-bits NEC IR's I tested, this is mapped as:
> 
> address code = AABBCC
> command code = DD

Hmm... actually, tivo NEC IR seems to be, instead:

address code = AABB
command code = CCDD

       	{ 0xa10c900f, KEY_MEDIA },      /* TiVo Button */
        { 0xa10c0807, KEY_POWER2 },     /* TV Power */
       	{ 0xa10c8807, KEY_TV },         /* Live TV/Swap */
        { 0xa10c2c03, KEY_VIDEO_NEXT }, /* TV Input */
        { 0xa10cc807, KEY_INFO },
        { 0xa10cfa05, KEY_CYCLEWINDOWS }, /* Window */
        { 0x0085305f, KEY_CYCLEWINDOWS },
        { 0xa10c6c03, KEY_EPG },        /* Guide */

(I guess that the second KEY_CYCLEWINDOWS is likely due to some different
IR device - the same 0x0085 pattern with duplicated keycode also happens
on key '8' on this table).

It should be noticed that those 24/32 bit "extended-NEC" aren't part of the
NEC protocol specs, AFAIKT. It is just some manufacturer's decision to use
a NEC chip to produce non-parity scancodes.

The manufacturer can obviously do whatever it wants with the protocol 
keycode, either using some standard, or to inventing their own way.
That's one of the reasons why we don't split the code into address/command
inside the RC core. Tthe other one is that a table lookup is simpler than
if this were broken into two separate fields.

Regards,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Mon, 10 Dec 2012 20:24:23 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 10.12.2012 18:57, schrieb Antti Palosaari:
> > On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
> >> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
> >>> Adding a new property to the RC profile certainly seems to be the
> >>> cleanest solution.
> >>> Do all protocols have paritiy checking ? Otherwise we could add a new
> >>> type RC_TYPE_NEC_NO_PARITY.
> >>> OTOH, introducing a new bitfield in struct rc_map might be usefull for
> >>> other flags, too, in the future...
> >>
> >> It's probably also worth mentioning that in that mode the device
> >> reports four bytes, not two.  I guess perhaps if parity is ignored it
> >> reports the data in some other format?  You will probably have to do
> >> some experimentation there.
> >
> > Uh, current em28xx NEC implementation is locked to traditional 16 bit
> > NEC, where is hw checksum used.

It is not the current NEC implementation at the driver; it is, instead,
a hardware issue. At least on the tests I did in the past with em28xx
and remote controllers capable of producing 32 bit keycodes, the NEC
hardware decoder inside em28xx were only providing 16 bits.

Regards,
Mauro

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab]

Em Mon, 10 Dec 2012 11:13:07 -0500
Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:

> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
> > Adding a new property to the RC profile certainly seems to be the
> > cleanest solution.
> > Do all protocols have paritiy checking ? Otherwise we could add a new
> > type RC_TYPE_NEC_NO_PARITY.
> > OTOH, introducing a new bitfield in struct rc_map might be usefull for
> > other flags, too, in the future...
> 
> It's probably also worth mentioning that in that mode the device
> reports four bytes, not two.  I guess perhaps if parity is ignored it
> reports the data in some other format?  You will probably have to do
> some experimentation there.

Hmm... that explains why em28xx weren't working properly with NEC extended
codes ;)

IMO, the better is to set it for NEC, and let the driver to do the parity
check, in order to properly handle the variants of the NEC protocol (16, 24
or 32 bits).

Due to the way the RC keycode is stored, there's no risk on keeping it
disabled, as a keycode generated by a 16-bit NEC remote with a parity
error will produce a 24 or 32 bits keycode. Such keycode will be discarded
for a keytable with 16 bits keycodes.

Regards,
Mauro.

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 2012-12-10 10:39, Frank Schäfer wrote:
> Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
>> On 12/09/2012 12:06 PM, Frank Schäfer wrote:
>>> Forget this sh... (never do multiple things at the same time ;) )
>>>
>>> Reg 0x50 is set to according to rc_type specified in the selected 
>>> remote
>>> control map.
>>> So if the correct map is selected, everything should be fine (as 
>>> long as
>>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others 
>>> yet).
>>>
>>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, 
>>> so
>>> the stick seems to use no NEC protocol.
>>>
>>> Matthew, insert a line
>>>
>>>          ir_config = 0x01;
>>>
>>> before
>>>
>>> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 
>>> 1);
>>>
>>> in em28xx-input.c and see if something shows up in the dmesg 
>>> output.
>>>
>>> Regards,
>>> Frank
>>
>> That seems to be a bit more successful!
>>
>> Here is the dmesg output:
>>
>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep 
>>> handle
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 
>>> 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 
>>> 2,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 
>>> 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 
>>> 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 
>>> 2,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 
>>> 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 
>>> 2,
>>> key 0x61d6
>>
>> I pressed all the buttons on the remote (40 buttons).
>
> Did you cut the dmesg output ? Or do you really get these messages 
> for
> key 0x61d6 only ?
>

Correct, I got these messages for key 0x61d6 regardless of the physical 
key pressed.

> It seems like things are working different with reg 0x50 = 0x01. 
> Taking
> a look into the datasheet might help, but I don't have it. ;)
>
> Regards,
> Frank
>
>>
>> Thanks,
>> Matthew

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Matthew Gyurgyik]

On 12/04/2012 04:06 PM, Frank Schäfer wrote:
>
> I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
> but LGDT3305_TPCLK_FALLING_EDGE is used instead of
> LGDT3305_TPCLK_RISING_EDGE.
> OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
>
> Matthew, could you please test V3 of the patch ? It is written against
> the media_tree staging/for_v3.8 (see http://git.linuxtv.org/media_tree.git).
> You could also already test the remote control key map (e.g. with evtest)
I tested the remote using evtest. However, no events are generated in 
evtest. I verified the remote works in windows.
> Regards,
> Frank
>

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Frank Schäfer]

Am 06.12.2012 03:32, schrieb Matthew Gyurgyik:
> On 12/04/2012 04:06 PM, Frank Schäfer wrote:
>>
>> I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
>> but LGDT3305_TPCLK_FALLING_EDGE is used instead of
>> LGDT3305_TPCLK_RISING_EDGE.
>> OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
>>
>> Matthew, could you please test V3 of the patch ? It is written against
>> the media_tree staging/for_v3.8 (see
>> http://git.linuxtv.org/media_tree.git).
>> You could also already test the remote control key map (e.g. with
>> evtest)
> I tested the remote using evtest. However, no events are generated in
> evtest. I verified the remote works in windows.

Ok :(
I'm not sure if it makes sense to test other maps at the moment.

>> Regards,
>> Frank
>>
>