LCDproc development and user support list

Text archives Help

[Lcdproc] PicoLCD driver for LCDProc

Chronological Thread 
  • From: jack at (Jack Cleaver)
  • Subject: [Lcdproc] PicoLCD driver for LCDProc
  • Date: Tue, 02 Sep 2008 11:24:01 +0100


Yesterday I submitted a patch to the LCDProc mailing list fixing a
memory leak in the picolcd driver. It hasn't been picked up yet -
perhaps I submitted it in the wrong way, or in the wrong place (I
appreciate that 24 hours is not a long time to wait, though). Before
submitting my next patch, I'm seeking guidance on patch submission.

I've now coded an enhancement for this driver to enable it to read the
IR sensor. The reason for doing this is that (as far as I can see) only
one client can "own" the picolcd USB device at once; so if both display
and IR capabilities are required, then the same client software must
manage both. My "itch" is getting picoLCD working with MythTV, and
MythTV requires LCDProc to handle the display. So For MythTV, any IR
handler for the picoLCD must be incorporated into the LCDProc driver, as
far as I can see.

The patch works like this: when a IR event is detected, the event is
transcribed into a LIRC-compatible packet, and passed to LIRC on a
configurable server and port using UDP. "Transcribed" means:

- An initial "sync" space is added, because iTuner apparently
deigns to return this interval in the USB packet (I need to test
this conjecture with more different remotes).
- The arity of the MARK/SPACE signals is inverted, because LIRC
expects active-low signalling.
- The values of the signals are scaled: iTuner returns data
representing microsecond intervals, whereas LIRC expects
intervals denoted in jiffies (1/16384 seconds).

I don't think any other LCDProc driver passes IR events to LIRC; but
perhaps no other supported device restricts IR and display clients to
using the same non-shareable device handle. If this is too hacky for
LCDProc to accept as a patch, no worries; "it works for me" (tm).

P.S. It would be nice if keypad events could also be passed through LIRC
as if they were IR events. However this evidently isn't the LCDProc way;
so I think the proper way to get this functionality would be to write an
LCDProc client that fields keypad events, transforms them into simulated
IR events, and passes them to LIRC using UDP. In this way (and with a
suitable lircd.conf), a program such as MythTV could field events from
the keypad or an IR remote interchangeably. This enhancement would be
independent of the picoLCD; effectively it would amount to a LCDProc
"driver" for LIRC.

Jack Cleaver.

Archive powered by MHonArc 2.6.18.

Top of page