Re: Kernel 3.17.0 broke xc4000-based DTV1800h
2014-12-01 15:15 GMT+01:00 Devin Heitmueller dheitmuel...@kernellabs.com: If somebody wants to send me an updated blob, I'm happy to host a copy at kernellabs.com alongside the file that is currently there (please make sure it has a different filename though). It would probably be the least confusing to users if the updated firmware was simply named dvb-fe-xc4000-1.4.2.fw, as it is a fixed/more complete version built from the same Xceive 1.4 source files. -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
2014-12-01 13:52 GMT+01:00 Mauro Carvalho Chehab mche...@osg.samsung.com: Em Mon, 01 Dec 2014 13:24:50 +0100 István, Varga istva...@mailbox.hu escreveu: I am not sure if those are responsible for the I2C errors, or simply the lack of the analog firmwares. Perhaps the latter if the errors do not occur with the (currently DVB-only) PCTV 340e. Maybe. The driver searches for the firmware image that matches the selected analog TV standard the best, and if the firmware file does not include any, then it currently attempts to load whatever else is found (for example, the base firmware). This problem should perhaps be fixed, although the ideal solution is to provide a complete firmware file. -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
Hi István, Em Sun, 30 Nov 2014 18:38:24 +0100 István, Varga istva...@mailbox.hu escreveu: On 16 Oct 2014, at 17:33, Rodney Baker rodney.baker at iinet.net.au wrote: Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my xc4000/zl10353/cx88 based DTV card has failed to initialise on boot. Apparently, the default firmware file name has been changed to dvb-fe-xc4000-1.4.1.fw, Actually, changeset da7bfa2c5df3 added support for both names. It tries first dvb-fe-xc4000-1.4.1.fw. If not found, it falls back to dvb-fe-xc4000-1.4.fw. and the firmware package for the kernel now includes this file from kernellabs.com. Yeah, Xceive granted a license to redistribute such firmware file via Hauppauge. The firmware we sent to linux-firmware is this one with the proper license. However, this firmware file is incomplete (only includes minimal DVB-T support for the PCTV 340e), and also incompatible with the driver. That is why trying to load it results in i2c errors. Hmm... I remember I did some tests with PCTV 340e using that firmware and it works for me. There were a bug at xc4000 that were causing PCTV 340e to not work, that got fixed on changeset 4c07e32884ab6957. Basically, get_frequency() were returning the wrong frequency, with caused dib7000p to adjust IF to a wrong value. With that change, at least for pctv 340e, xc4000 driver is working fine. Such change shouldn't affect devices with zl10153, as this demod doesn't call tuner's get_frequency(). To get a firmware file that actually works, download this package, and build it: http://juropnet.hu/~istvan_v/xc4000_firmware.tar.gz Actually, it was posted to the linux-media list in the past, but the file did not end up being included with the kernel firmware packages for some reason. For a firmware to be added at the Kernel firmware, the manufacturer has to grant a license to redistribute the binaries. I was not aware that there are actually two different versions of the xc4000 firmware with the same name. This is a really bad idea. What we should do is to name those versions differently, and pass the firmware name as a parameter to the xc4000 attach function. On a quick look, it seems that those are the devices that use the xc4000 tuner: cx23885: Leadtek Winfast PxDVR3200 H XC4000 cx88: Leadtek WinFast DTV1800 H (XC4000) Leadtek WinFast DTV2000 H PLUS dib0700: PCTV 340e Do you know if the firmware that works with Leadtek devices also work without any regressions with PCTV 340e? If so, then if Leadtek could get a license from Xceive to redistribute the firmwares at the Kernel, we could update the firmware file at the linux-firmware tree. However, if the firmware doesn't work properly with PCTV 340e and/or Leadtek/Xceive cannot grant a license to redistribute the other version of the firmware, the best would be to rename the firmware file used by Leadtek devices to dvb-fe-xc4000-leadtek-1.4.fw, in order to avoid confusion. I won't doubt that the version that works with dib0700 would be different than the ones that work with other devices, as the IF used on dib0700 could be different (I think most dib0700 devices use a zero-IF tuner). The include path to tuner-xc2028-types.h needs to be changed in build_fw.c, since the tuners subdirectory is now in drivers/media, rather than drivers/media/common. After that, running make will produce a correct firmware file named dvb-fe-xc4000-1.4.fw. Some distributions include older firmware files from this page: http://istvanv.users.sourceforge.net/v4l/xc4000.html These are slightly different from the newer one, and are extracted from the Windows drivers, rather than from the xc4000_firmwares.h file provided by Xceive, but should still work nevertheless. -- 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 -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
2014-12-01 10:20 GMT+01:00 Mauro Carvalho Chehab mche...@osg.samsung.com: Hi István, Yeah, Xceive granted a license to redistribute such firmware file via Hauppauge. The firmware we sent to linux-firmware is this one with the proper license. Hi, does the license apply specifically to the kernellabs.com firmware file, or the header files released by Xceive (xc4000_firmwares.h, xc4000_scodes.h) ? In the latter case, it should cover my firmware file (dvb-fe-xc4000-1.4.fw) as well, because it is generated from the same headers. Also, it is no longer generated from the Leadtek Windows drivers (like it was in the past before I had access to the Xceive header files), so it should in theory only be licensed by Xceive, rather than Leadtek. Hmm... I remember I did some tests with PCTV 340e using that firmware and it works for me. From a quick look at the contents of dvb-fe-xc4000-1.4.1.fw (the kernellabs.com file), it appears to be missing all the firmware data related to analog TV and radio standards, and all scodes are (incorrectly) a copy of the one needed for int_freq = 5400. Therefore, it only works with the demodulator used on the PCTV 340e, which is using that frequency, but not with the Leadtek cards with zl10153, since those require 4560 instead. It also seems to be missing some standard and firmware type flags. I am not sure if those are responsible for the I2C errors, or simply the lack of the analog firmwares. Perhaps the latter if the errors do not occur with the (currently DVB-only) PCTV 340e. Such change shouldn't affect devices with zl10153, as this demod doesn't call tuner's get_frequency(). The get_frequency() change is not an issue, the kernellabs.com firmware that is now the default and part of the kernel packages does not include data that is required for the Leadtek cards to work. However, if the firmware doesn't work properly with PCTV 340e and/or Leadtek/Xceive cannot grant a license to redistribute the other version of the firmware, the best would be to rename the firmware file used by Leadtek devices to dvb-fe-xc4000-leadtek-1.4.fw, in order to avoid confusion. Although I did not test it, the firmware should work with the PCTV 340e as well. It definitely does with the Leadtek devices in DVB-T mode, and on the PCTV 340e the only difference is the IF (5400 vs. 4560). -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
Em Mon, 01 Dec 2014 13:24:50 +0100 István, Varga istva...@mailbox.hu escreveu: 2014-12-01 10:20 GMT+01:00 Mauro Carvalho Chehab mche...@osg.samsung.com: Hi István, Yeah, Xceive granted a license to redistribute such firmware file via Hauppauge. The firmware we sent to linux-firmware is this one with the proper license. Hi, does the license apply specifically to the kernellabs.com firmware file, or the header files released by Xceive (xc4000_firmwares.h, xc4000_scodes.h) ? My understanding is that it covers that specific firmware file. In the latter case, it should cover my firmware file (dvb-fe-xc4000-1.4.fw) as well, because it is generated from the same headers. Also, it is no longer generated from the Leadtek Windows drivers (like it was in the past before I had access to the Xceive header files), so it should in theory only be licensed by Xceive, rather than Leadtek. True, just Xceive's SOB would be enough, but in general, it is easier to get chipset manufacturer's license via the hardware manufacturer (Leadtek, in this case). So, we need either someone at Xceive to SOB the patch or someone at Leadtek that has internally some authorization to release the firmware files in their behalf. Hmm... I remember I did some tests with PCTV 340e using that firmware and it works for me. From a quick look at the contents of dvb-fe-xc4000-1.4.1.fw (the kernellabs.com file), it appears to be missing all the firmware data related to analog TV and radio standards, and all scodes are (incorrectly) a copy of the one needed for int_freq = 5400. Maybe the scodes are patched for some specific interworking scenario with dib0700. Therefore, it only works with the demodulator used on the PCTV 340e, which is using that frequency, but not with the Leadtek cards with zl10153, since those require 4560 instead. It also seems to be missing some standard and firmware type flags. I see. I am not sure if those are responsible for the I2C errors, or simply the lack of the analog firmwares. Perhaps the latter if the errors do not occur with the (currently DVB-only) PCTV 340e. Maybe. Such change shouldn't affect devices with zl10153, as this demod doesn't call tuner's get_frequency(). The get_frequency() change is not an issue, It used to be for PCTV 340e before the fixup patch, after some changes that happened at dib0700 driver. the kernellabs.com firmware that is now the default and part of the kernel packages does not include data that is required for the Leadtek cards to work. I see. However, if the firmware doesn't work properly with PCTV 340e and/or Leadtek/Xceive cannot grant a license to redistribute the other version of the firmware, the best would be to rename the firmware file used by Leadtek devices to dvb-fe-xc4000-leadtek-1.4.fw, in order to avoid confusion. Although I did not test it, the firmware should work with the PCTV 340e as well. It definitely does with the Leadtek devices in DVB-T mode, and on the PCTV 340e the only difference is the IF (5400 vs. 4560). -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
My understanding is that it covers that specific firmware file. In this case the license was actually against the header file. I was responsible for generating the binary blob based on the header files in the Xceive sources (and got the appropriate permission). There should be no licensing issue generating a second blob that includes the analog standards (I just never got around to it because I didn't analog support and hence couldn't test the result). If somebody wants to send me an updated blob, I'm happy to host a copy at kernellabs.com alongside the file that is currently there (please make sure it has a different filename though). 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: Kernel 3.17.0 broke xc4000-based DTV1800h
2014-12-01 15:15 GMT+01:00 Devin Heitmueller dheitmuel...@kernellabs.com: If somebody wants to send me an updated blob, I'm happy to host a copy at kernellabs.com alongside the file that is currently there (please make sure it has a different filename though). My firmware package is available here: http://juropnet.hu/~istvan_v/xc4000_firmware.tar.gz The only relevant files are build_fw.c and the two original headers from Xceive (xc4000_*.h). Although other programs for extracting the firmware from the Windows drivers are also included, they are no longer needed. To compile build_fw.c on current kernels without errors, the include path to tuner-xc2028-types.h needs to be fixed at line 11. Other than that, it should work without problems. It takes one optional command line argument, which is the name of the output file. -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
On 16 Oct 2014, at 17:33, Rodney Baker rodney.baker at iinet.net.au wrote: Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my xc4000/zl10353/cx88 based DTV card has failed to initialise on boot. Apparently, the default firmware file name has been changed to dvb-fe-xc4000-1.4.1.fw, and the firmware package for the kernel now includes this file from kernellabs.com. However, this firmware file is incomplete (only includes minimal DVB-T support for the PCTV 340e), and also incompatible with the driver. That is why trying to load it results in i2c errors. To get a firmware file that actually works, download this package, and build it: http://juropnet.hu/~istvan_v/xc4000_firmware.tar.gz Actually, it was posted to the linux-media list in the past, but the file did not end up being included with the kernel firmware packages for some reason. The include path to tuner-xc2028-types.h needs to be changed in build_fw.c, since the tuners subdirectory is now in drivers/media, rather than drivers/media/common. After that, running make will produce a correct firmware file named dvb-fe-xc4000-1.4.fw. Some distributions include older firmware files from this page: http://istvanv.users.sourceforge.net/v4l/xc4000.html These are slightly different from the newer one, and are extracted from the Windows drivers, rather than from the xc4000_firmwares.h file provided by Xceive, but should still work nevertheless. -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
By the way, from the xc4000_firmware.tar.gz package, the only files that are actually needed are: build_fw.c (source code of simple program to write the firmware file) xc4000_firmwares.h (header file from Xceive) xc4000_scodes.h (also from Xceive) Everything else is related to extracting the firmware from Windows drivers, and was included only for completeness. The license for the Xceive header files can be found here: http://www.kernellabs.com/firmware/xc4000/README.xc4000 -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
Ping? Does anybody have any idea where to star digging on this? Sent from my iPad On 16 Oct 2014, at 17:33, Rodney Baker rodney.ba...@iinet.net.au wrote: Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my xc4000/zl10353/cx88 based DTV card has failed to initialise on boot. The following messages are from dmesg; [ 78.468221] xc4000: I2C read failed [ 80.074604] xc4000: I2C read failed [ 80.074605] Unable to read tuner registers. [ 82.622062] Selecting best matching firmware (7 bits differ) for type=(0), id 0020b700: [ 82.626375] i2c i2c-0: sendbytes: NAK bailout. [ 148.063594] xc4000: I2C read failed [ 149.669994] xc4000: I2C read failed [ 149.669995] Unable to read tuner registers. [ 149.670198] cx88[0]/0: registered device video1 [v4l2] [ 149.670287] cx88[0]/0: registered device vbi0 [ 149.670338] cx88[0]/0: registered device radio0 [ 149.670340] cx88[0]/0: failed to create cx88 audio thread, err=-4 [ 149.670382] cx88[0]/2: cx2388x based DVB/ATSC card [ 149.670384] cx8802_alloc_frontends() allocating 1 frontend(s) [ 149.670515] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards [ 151.305364] zl10353_read_register: readreg error (reg=127, ret==-6) [ 151.305367] cx88[0]/2: frontend initialization failed [ 151.305369] cx88[0]/2: dvb_register failed (err = -22) [ 151.305370] cx88[0]/2: cx8802 probe failed, err = -22 It worked with 3.16.3-1.gd2bbe7f-desktop on the same machine. Regards, Rodney. -- == Rodney Baker VK5ZTV rodney.ba...@iinet.net.au == -- 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 -- 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
Kernel 3.17.0 broke xc4000-based DTV1800h
Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my xc4000/zl10353/cx88 based DTV card has failed to initialise on boot. The following messages are from dmesg; [ 78.468221] xc4000: I2C read failed [ 80.074604] xc4000: I2C read failed [ 80.074605] Unable to read tuner registers. [ 82.622062] Selecting best matching firmware (7 bits differ) for type=(0), id 0020b700: [ 82.626375] i2c i2c-0: sendbytes: NAK bailout. [ 148.063594] xc4000: I2C read failed [ 149.669994] xc4000: I2C read failed [ 149.669995] Unable to read tuner registers. [ 149.670198] cx88[0]/0: registered device video1 [v4l2] [ 149.670287] cx88[0]/0: registered device vbi0 [ 149.670338] cx88[0]/0: registered device radio0 [ 149.670340] cx88[0]/0: failed to create cx88 audio thread, err=-4 [ 149.670382] cx88[0]/2: cx2388x based DVB/ATSC card [ 149.670384] cx8802_alloc_frontends() allocating 1 frontend(s) [ 149.670515] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards [ 151.305364] zl10353_read_register: readreg error (reg=127, ret==-6) [ 151.305367] cx88[0]/2: frontend initialization failed [ 151.305369] cx88[0]/2: dvb_register failed (err = -22) [ 151.305370] cx88[0]/2: cx8802 probe failed, err = -22 It worked with 3.16.3-1.gd2bbe7f-desktop on the same machine. Regards, Rodney. -- == Rodney Baker VK5ZTV rodney.ba...@iinet.net.au == -- 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
