[PATCH] dvb-usb-af9035: load HID table
Automatically load sniffed HID table from Windows driver if USB_VID_ITETECH:USB_PID_ITETECH_IT9135_9006 device is present (e.g. Evolveo Mars) or if module parameter force_hid_tab_load is set. Signed-off-by: Jaroslav Škarvada --- drivers/media/usb/dvb-usb-v2/af9035.c | 266 ++ 1 file changed, 266 insertions(+) diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c b/drivers/media/usb/dvb-usb-v2/af9035.c index 4df9486..5bbcc1e 100644 --- a/drivers/media/usb/dvb-usb-v2/af9035.c +++ b/drivers/media/usb/dvb-usb-v2/af9035.c @@ -24,6 +24,10 @@ /* Max transfer size done by I2C transfer functions */ #define MAX_XFER_SIZE 64 +static bool force_hid_tab_load; +module_param(force_hid_tab_load, bool, 0644); +MODULE_PARM_DESC(force_hid_tab_load, "force HID table loading"); + DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr); static u16 af9035_checksum(const u8 *buf, size_t len) @@ -1693,6 +1697,263 @@ static int af9035_tuner_detach(struct dvb_usb_adapter *adap) return 0; } +static int ite9135_load_hid_tab(struct dvb_usb_device *d) +{ + struct usb_interface *intf = d->intf; + int ret, i; + struct reg_val hid_tab[] = { + { 0x4a97, 0x02 }, + { 0x4a98, 0xbd }, + { 0x4a99, 0x0c }, + { 0x4a9a, 0xf3 }, + { 0x4a9b, 0x3d }, + { 0x4a9c, 0x00 }, + { 0x4a9d, 0x00 }, + { 0x4a9e, 0x02 }, + { 0x4a9f, 0xbd }, + { 0x4aa0, 0x00 }, + { 0x4aa1, 0xff }, + { 0x4aa2, 0x1e }, + { 0x4aa3, 0x00 }, + { 0x4aa4, 0x00 }, + { 0x4aa5, 0x02 }, + { 0x4aa6, 0xbd }, + { 0x4aa7, 0x01 }, + { 0x4aa8, 0xfe }, + { 0x4aa9, 0x1f }, + { 0x4aaa, 0x00 }, + { 0x4aab, 0x00 }, + { 0x4aac, 0x02 }, + { 0x4aad, 0xbd }, + { 0x4aae, 0x02 }, + { 0x4aaf, 0xfd }, + { 0x4ab0, 0x20 }, + { 0x4ab1, 0x00 }, + { 0x4ab2, 0x00 }, + { 0x4ab3, 0x02 }, + { 0x4ab4, 0xbd }, + { 0x4ab5, 0x03 }, + { 0x4ab6, 0xfc }, + { 0x4ab7, 0x21 }, + { 0x4ab8, 0x00 }, + { 0x4ab9, 0x00 }, + { 0x4aba, 0x02 }, + { 0x4abb, 0xbd }, + { 0x4abc, 0x04 }, + { 0x4abd, 0xfb }, + { 0x4abe, 0x22 }, + { 0x4abf, 0x00 }, + { 0x4ac0, 0x00 }, + { 0x4ac1, 0x02 }, + { 0x4ac2, 0xbd }, + { 0x4ac3, 0x05 }, + { 0x4ac4, 0xfa }, + { 0x4ac5, 0x23 }, + { 0x4ac6, 0x00 }, + { 0x4ac7, 0x00 }, + { 0x4ac8, 0x02 }, + { 0x4ac9, 0xbd }, + { 0x4aca, 0x06 }, + { 0x4acb, 0xf9 }, + { 0x4acc, 0x24 }, + { 0x4acd, 0x00 }, + { 0x4ace, 0x00 }, + { 0x4acf, 0x02 }, + { 0x4ad0, 0xbd }, + { 0x4ad1, 0x07 }, + { 0x4ad2, 0xf8 }, + { 0x4ad3, 0x25 }, + { 0x4ad4, 0x00 }, + { 0x4ad5, 0x00 }, + { 0x4ad6, 0x02 }, + { 0x4ad7, 0xbd }, + { 0x4ad8, 0x08 }, + { 0x4ad9, 0xf7 }, + { 0x4ada, 0x26 }, + { 0x4adb, 0x00 }, + { 0x4adc, 0x00 }, + { 0x4add, 0x02 }, + { 0x4ade, 0xbd }, + { 0x4adf, 0x09 }, + { 0x4ae0, 0xf6 }, + { 0x4ae1, 0x27 }, + { 0x4ae2, 0x00 }, + { 0x4ae3, 0x00 }, + { 0x4ae4, 0x02 }, + { 0x4ae5, 0xbd }, + { 0x4ae6, 0x0a }, + { 0x4ae7, 0xf5 }, + { 0x4ae8, 0x41 }, + { 0x4ae9, 0x00 }, + { 0x4aea, 0x00 }, + { 0x4aeb, 0x02 }, + { 0x4aec, 0xbd }, + { 0x4aed, 0x1c }, + { 0x4aee, 0xe3 }, + { 0x4aef, 0x2a }, + { 0x4af0, 0x00 }, + { 0x4af1, 0x00 }, + { 0x4af2, 0x02 }, + { 0x4af3, 0xbd }, + { 0x4af4, 0x1f }, + { 0x4af5, 0xe0 }, + { 0x4af6, 0x43 }, + { 0x4af7, 0x00 }, + { 0x4af8, 0x00 }, + { 0x4af9, 0x02 }, + { 0x4afa, 0xbd }, + { 0x4afb, 0x12 }, + { 0x4afc, 0xed }, + { 0x4afd, 0x52 }, + { 0x4afe, 0x00 }, + { 0x4aff, 0x00 }, + { 0x4b00, 0x02 }, + { 0x4b01, 0xbd }, + { 0x4b02, 0x11 }, + { 0x4b03, 0xee }, + { 0x4b04, 0x50 }, + { 0x4b05, 0x00 }, + { 0x4b06, 0x00 }, +
Re: [PATCH] dvb-usb-af9035: load HID table
Hello Jaroslav Škarvada kirjoitti 2017-06-09 20:46: Automatically load sniffed HID table from Windows driver if USB_VID_ITETECH:USB_PID_ITETECH_IT9135_9006 device is present (e.g. Evolveo Mars) or if module parameter force_hid_tab_load is set. There is few issues I don't like this approach. Mostly that module parameter to select HID table. There is existing solution to select remote controller, it is ir-keytable and it should be used rather than defining device specific module parameter. If you look that HID table you could see there is 4 bytes NEC code and 3 bytes HID code. Remote controller seems to have 34 keys. Remote controller address bytes are 0x02bd, grepping existing remote controller keytables it could be Total Media In Hand remote controller (rc-total-media-in-hand.c). If not, then defining new keytable is needed. I did some research about issue and found 2 better solutions. 1) Configure HID table dynamically. Remote controller keytable has some needed information, but those KEY_* events needed to be translated to HID codes somehow. 2) Kill HID and then use CMD_IR_GET to get remote controller scancodes by polling. Solution 1 sounds most correct. No need to poll and decode by sw as hw does all the job. But it is most hardest to implement, I am not aware if anyone has done it yet. regards Antti -- http://palosaari.fi/
Re: [PATCH] dvb-usb-af9035: load HID table
Hi Jaroslav, [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.12-rc4 next-20170609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jaroslav-karvada/dvb-usb-af9035-load-HID-table/20170611-142004 base: git://linuxtv.org/media_tree.git master config: xtensa-allmodconfig (attached as .config) compiler: xtensa-linux-gcc (GCC) 4.9.0 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=xtensa All warnings (new ones prefixed by >>): drivers/media/usb/dvb-usb-v2/af9035.c: In function 'ite9135_load_hid_tab': >> drivers/media/usb/dvb-usb-v2/af9035.c:1955:1: warning: the frame size of >> 1936 bytes is larger than 1024 bytes [-Wframe-larger-than=] } ^ vim +1955 drivers/media/usb/dvb-usb-v2/af9035.c 1939 { 0x4b81, 0xeb }, 1940 { 0x4b82, 0x45 }, 1941 { 0x4b83, 0x03 }, 1942 { 0x4b84, 0x00 }, 1943 }; 1944 1945 for (i = 0; i < ARRAY_SIZE(hid_tab); i++) { 1946 ret = af9035_wr_reg(d, hid_tab[i].reg, hid_tab[i].val); 1947 if (ret < 0) 1948 goto err; 1949 } 1950 dev_info(&intf->dev, "HID table successfully loaded\n"); 1951 return 0; 1952 err: 1953 dev_info(&intf->dev, "loading HID table failed, item=%d, ret=%d\n", i, ret); 1954 return ret; > 1955 } 1956 1957 static int af9035_init(struct dvb_usb_device *d) 1958 { 1959 struct state *state = d_to_priv(d); 1960 struct usb_interface *intf = d->intf; 1961 int ret, i; 1962 u16 frame_size = (d->udev->speed == USB_SPEED_FULL ? 5 : 87) * 188 / 4; 1963 u8 packet_size = (d->udev->speed == USB_SPEED_FULL ? 64 : 512) / 4; --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] dvb-usb-af9035: load HID table
- Original Message - > Hello > > Jaroslav Škarvada kirjoitti 2017-06-09 20:46: > > Automatically load sniffed HID table from Windows driver if > > USB_VID_ITETECH:USB_PID_ITETECH_IT9135_9006 device is present (e.g. > > Evolveo > > Mars) or if module parameter force_hid_tab_load is set. > > There is few issues I don't like this approach. Mostly that module > parameter to select HID table. There is existing solution to select > remote controller, it is ir-keytable and it should be used rather than > defining device specific module parameter. > > If you look that HID table you could see there is 4 bytes NEC code and 3 > bytes HID code. Remote controller seems to have 34 keys. Remote > controller address bytes are 0x02bd, grepping existing remote controller > keytables it could be Total Media In Hand remote controller > (rc-total-media-in-hand.c). If not, then defining new keytable is > needed. > > I did some research about issue and found 2 better solutions. > 1) Configure HID table dynamically. Remote controller keytable has some > needed information, but those KEY_* events needed to be translated to > HID codes somehow. > 2) Kill HID and then use CMD_IR_GET to get remote controller scancodes > by polling. > > Solution 1 sounds most correct. No need to poll and decode by sw as hw > does all the job. But it is most hardest to implement, I am not aware if > anyone has done it yet. > > regards > Antti > > > -- > http://palosaari.fi/ > Hi, thanks for info. General approach is usually better than device specific hacks, but it looks like longer run. Unfortunately I returned the device to the original owner, so I will be probably unable to help with it more. But the problem needs to be addressed, the state when the remote isn't working isn't good thanks & regards Jaroslav