Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 380em28xx_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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 297dprintk(%s: toggle: %d, count: %d, key 0x%02x%02x\n, __func__, Change it to 297printk(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_core12193 3 rc_msi_digivox_iii,em28xx_rc dvb_core 86050 2 em28xx_dvb,lgdt3305 tveeprom 13658 1 em28xx videobuf_vmalloc4136 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? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 380em28xx_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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/06/2012 10:21 PM, Devin Heitmueller wrote: On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik matt...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 52500 Hz
video pid 0x07c0, audio pid 0x07c1
status 00 | signal 4b11 | snr 0066 | ber | unc |
status 1f | signal | snr 01d8 | ber | unc | 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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/03/2012 09:29 PM, Devin Heitmueller wrote: On Mon, Dec 3, 2012 at 9:15 PM, Matthew Gyurgyik matt...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
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: 06 ms 000990 ms c0 00 00 00 80 00 01 00 ff 000256: 04 ms 000994 ms 40 00 00 00 80 00 01 00 fe 000257: 06 ms 001000 ms c0 00 00 00 80 00 01 00 fe 000258: 04 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: 05 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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx: msi Digivox ATSC board id [0db0:8810]
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
