Re: [ivtv-devel] cheapi2c/lmilk

[Mark W. <mar...@np...>]

Further progress:

All stuff under http://www.blushingpenguin.com/mark/lmilk/

- I extracted all of the keypresses in the Hauppauge "database" [1]. 
These are in IRcodesets.xml which includes their region/device/vendor 
mappings.  This amounts to 9,170 blocks of data of which I have just 
included the values of the register writes 01-63 (all the other writes 
appear to be common).

- I extracted a boot up log ("boot") -- the driver does something 
special on boot.  This looks mostly like a normal code block write 
except that it ends up reading the what the windows driver reports as 
the firmware version (1.3.0 in my case, latest IR driver from Hauppauge 
website).  The hardware does not behave (i.e. respond properly to send 
requests -- it reports 0x00 not 0xA0 on the first read) if you do not do 
this.

- I hacked on lirc_i2c a bit to get it to initialise the driver with the 
static boot block and send one random keypress when it gets any write 
command.  This makes the IR sending thing blink away happily.  Dunno if 
it works with a real device, I haven't got anything handy to test it 
with, but at least it's doing something.

I am not at all convinced I will ever be able to understand what's in 
the data blocks.  I consider doing what the windows driver does to be 
fine (despite the maintenance issue, which is a shame) and when I've got 
to that point I'll probably call it a day.  However if anyone else can 
get anywhere with this I am more than happy to dig around a bit more or 
do more captures.

The next step for me is to get the rest of the lirc driver going.  This 
looks like a pain as LIRC isn't really set up for sending random binary 
blocks, I will be asking the LIRC list for help on this (any advice 
appreciated).  I don't really want to build all of the keypresses (about 
64*9170 + overhead ~ 600K) into the driver, it seems like the best way 
at the moment though.  Something like a /lib/modules/IRcodesets, sending 
codeset/keypress to the driver, reading those from a file in the kernel, 
and caching a codeset seems like the best tradeoff to me.  Bear in mind 
that I'm not even a linux programmer by trade so go easy on me if that 
seems insane!

Thanks,

Mark

[1] Hauppauge have a handy OCX control that they use to implement the 
BlasterCfg application.  The VB application in HaupExtract uses this to 
collate all of the region/vendor/device information, and then sends 
every possible keypress in each codeset.  This information is supposed 
to be captured by lmilk (modified to increase the buffer size -- in 
main.cpp -- I used 64Mb up from 512K).  After 45 minutes or so you have 
a big dump file that can then be fed to the perl script parseMilk.pl. 
This fills out the <data> nodes for each key.  (It doesn't deal with the 
bootup code at present so you need to remove that manually if repeating 
this procedure).  (This information is mainly intended for anyone mad 
enough to repeat the procedure).