VLSystems, MonCaso 312 version 2, FTDI, mplay, linux

[CJ O. <cj...@ct...>]

Hello all, new to lirc, but been doing the linux thing for a long time.
I understand this board/manufacturer is a pain in everyone's side.  I
have everything working with one exception--the volume knob.  Patches to
come for the community if I ever get it working right.

The above mentioned "volume" knob is also a select button.  It sends a
0x84 byte, which lirc correctly interprets.  The problem is that it
tends to double, triple, and even quadruple fire, and doesn't send the
normal 0x7e repeat byte.  The repeat byte doesn't matter so much because
it doesn't make any sense; my question is how do I say "if you get the
same byte within so many milliseconds, call it a single button press"?
Can this be done in the config file or will it require modification of
the driver?  Something I should beat with xbmc instead?

My second question is a little more involved.  The knob can obviously be
turned in either direction, but doesn't send any data over the serial
port.  I don't know enough about the low level aspects of USB, but if
someone can point me in the right direction, I'd be happy to make the
necessary modifications.  Here's what I see:  Cat'ing
/sys/kernel/debug/.../usbmon/Nu, the receiver sends a 0x0160 word
every millisecond.  I don't know if that's the kernel driver polling it
or what exactly, but that's the case.  Normal button presses come after
the 0x0160.  When the volume knob is turned, the first nibble of that
0x0160 changes 0->1->3->2->0 or 0->2->3->1->0 depending on which way
your turning it.  Clearly it's bits getting set/cleared as it enters,
peaks, and leaves the points on the knob which also allows you to
"abort" a turn half way (0 1 3 1 0 means started turning right but then
turned back left).  I should mention that this is all from memory, so it
may not be completely accurate but I do have it all figured out.  The
problem is that there doesn't seem to be a good way to get at this.  I
don't even know if these are the dtr/rts/cts bits or what, nor why it
gets sent (polled?) at 1khz, and only after the 0x96 byte.  In any case,
if someone can point me in the right direction and maybe explain
what/why I'm seeing what I'm seeing, I'll make it work.  Kernel
ftdi_sio?  Something LIRC can get at?  Is this part of the FTDI chip's
bit-banging gpio?  New driver to run the USB directly?

A couple extra questions regarding this:

This receiver only works at 57600, and for the most part (with the above
mentioned exceptions), works wonderfully at 57600.  I've seen some
random traffic on this list's archives (as well as many others) alluding
to this.  I am happy to submit a patch to the mplay driver that allows
the user to override the baud rate.  Has this been done or is anybody
working on it?

Also this receiver requires a 0x96 to be written to it to enable the
receiver--no idea what or why, found that on the web.  I can add this to
the patch as well as long as nobody is working on it either--no need to
reinvent the wheel.

How would the maintainers prefer this sort of modification.  I was
planning on changing the device= arg to accept something like
device=/dev/ttyUSB0,baud=57600,initbyte=0x96, but I'll do it however the
best practice is.

-CJO-

---------------------------------
CJ Oster, IT Manager, cj...@ct...
Champaign Telephone Company, Inc

1300 S. Neil St
Champaign, IL 61820

Main:   217 344 4444
Fax:    217 398 5923