I am currently in the process of attempting to add support for this
device to LIRC, but am running into some difficulties with how best to
do it.
Some background:
This device appears on the I2C bus of the PVR-150 at address 0x70 (the
receiver appears at 0x71). The method of controlling this device is
largely unknown (search for cheapi2/lmilk on the ivtv-devel list for the
full story), however I have got this to a stage where I can reproduce
what the windows driver does from I2C captures.
The windows driver only appears have the ability to send specific IR
codes from a database provided by hauppauge. These consist of 63 byte
blocks sent to the device to prepare it, some waiting around, and then
the device actually getting around to sending the signal.
Because the format of these blocks is not at all obvious to me I have
taken the approach of capturing every key press in the hauppauge
database. This allows me to at least do what the windows driver can do,
although it's not very elegant. (They have a half-finished 'learn'
interface, but it simply doesn't work at present).
Thus I have taken the line that the simplest method is to use the
captured database and to make the driver use this. Obviously if anyone
can work out how to do something better then I will go in that
direction, but in the interim this should be better than nothing!
My questions:
- I need somehow to have this database of random 63 byte blocks
available. Currently the best way seems to me to have a database (works
out at something like 600K) in a file and to have the driver load the
appropriate codeset, then have the write ioctl read/cache a codeset. I
would then use "raw" codes (e.g. codeset 100, key 5) in lircd.conf to
map to appropriate button presses. The advantage of this approach is
that it makes a codeset scanning application easy to write for initial
setup. If there's a better approach then please do let me know!
- LIRC doesn't seem to like raw codes of even length, can I simply
remove this restriction to support the above? If not, adding a dummy
value is OK I guess or I could map it into one 32-bit value.
- If I send the key code data directly rather than reading a file (which
makes the initial scanning harder, the way LIRC works) is there any
elegant way of sending a block of bytes? Currently it looks really
messy as everything is done with (an odd number of) 32-bit integers.
- To support sending, it appears that I need to use a
file_operations/file. There doesn't currently seem to be any way of
mapping context (in my case I need the i2c structure available) to
these. Obviously I don't want to use a static i2c structure as this
prevents using multiple capture cards/IR blasters. Is there an easy way
to map context data to a file? My only method currently is to provide a
different file_operations for each attached device, store a list of
these, and scan them when I need the i2c context.
- The driver will be send only, but it appears that I need poll/read/etc
to be available (otherwise I can get interesting oopses). Is it ok to
simply implement stubs for these that return failure codes?
Thanks,
Mark
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
