since the display is 16x2, i kind of think a tty device would be gumming
up the works. no sense in cooking the output.
scrolling is done manually. the entire display of both lines has to be
sent in every write. the samsung vfd panel itself has far more features
than soundgraph (the manufacturer of the imon) has put into this (at
least based on what their windows software does.. i'd kind of doubt
that they are holding back features from their own software teams).
i've only witnessed six types of transactions in their software. vfd
text downstream. bargraph downstream. set/display static standby
text. set/display freerunning standby clock/date. knob/button
upstream. remote control upstream. all upstream is interrupt. i have
verified all funtions in small test programs.
bargraph is munged (i'm assuming that the bargraph is partially
obfuscated by the fact that their display buffer seems to be only 16
bytes per line, when the samsung panel itself has 40 byte buffers for
each 16 char line. line 1 left char is address 0 in the panel, and line
2 left char is address 40h, with 40 chars (28h) per line's display ram.
i also suspect some intentional obfuscation involved in their bargraph
scheme in a lame anti-reverse engineering attempt (their windows
software always lags the music, and that's on an intel E8200, with large
disk and 4 gigs of ram (3.9G addressable) the low-speed interface might
also be a factor. personally, i'd do this at no less than 12mbit if i
was the engineer...the chips are cheap enough.
there seems to also be no support for the panel's on/off command
(although i'm willing to bet it's there). there is no apparent support
for the clear screen function (soundgraph's software does this by
writing spaces to the display in five packets, when the vfd display
itself supports a one-byte command to do so). no cursor functions (the
cursor line is only active in bargraph mode). no brightness control
(the panel supports 4 brightness levels). the display's built-in
scrolling only scrolls both lines left or right, not individual lines,
so, i can see why they chose to not use that. the panel supports
blinking text, but that is also unsupported.
some of the information that does not apply to my unit, i will derive
from Alexander Popov's imon-0.1 driver which is not 8.x compat. he
lists several other id's for enumeration, and has a quirk for some older
versions that need a 6th fixed dummy packet for writing text to the
display. the current generation drive-bay version mass-marketed by
antec (veris elite) which i have doesn't require it, but apparently, his
silverstone lc16 chassis does. he also didn't figure out the bargraph,
knob/button, or clock/static standby display, his driver only displayed
text, decoded the remote.
overall, the device is rather simplistic as packaged with the soundgraph
controller board backing the panel. the samsung vfd used seems to be
far more powerful than the soundgraph endpoint supports. again, i'm
using their own software, sniffed, to determine the functionality and
commands. the display is so simplistic, a tty interface would be
overkill. just character devices in this, and due to the multiple
functions, the write() interface will be via variable length typed
packets (type, length, data), the read() interface envisioned will be
similar if i implement buffering of knob input, or single bytes
otherwise, one for each of the three active states.
anyhow. time for bed.
nite.
Jim Bryant wrote:
it'll be a pair of character devices.
the imon vfd is oem'ed to virtually EVERY high-end vfd-equipped htpc
case on the market, all such tend to have the remote control interface
as well built into the unit. the difference exists with the
knob/button, some have it, others don't. the knob/button uses
interrupt packets like the remote, but a totally different kind of
packet, and i don't see support for it in lirc, so, i'll probably
integrate it into the vfd device as the only read, and leave the
remote as a seperate 100% lirc device. if people want to tie the
knob/button to the volume/mute function exclusively, they can do so
outside of the lirc framework. imho, the knob/button has better use
as a function selector associated with menus on the vfd, although it
can be used for volume/mute with little modification to existing
lirc-related code.
another possibility would be to use a function in the vfd driver to
switch it between the vfd device for discrete use, or to switch it to
the /dev/lirc device and have it link directly to the lirc codes for
the remote for the volume up/down/mute buttons, with the capability to
switch it back with another call to the /dev/vfd device. this is the
direction i'm leaning. since the vfd panel, knob/button, and
lirc-compat remote are all going to be in this driver, it's kind of a
no-brainer. the option to use the knob/button for either should be
left to the end-user/programmer. most people would rather use a
remote control for volume/mute anyway.
although there is very rudimentary support in linux under LCDd for the
imon vfd, i'm thinking about not going that route. the end product
may not end up being lcdproc /dev/lcd compat. it has limitations i
don't like, and it wouldn't take advantage of the features the imon has.
lirc compat is a goal of this project though. most of the work is
done on that front, i just need to port that over from linux. the
features of the imon remote control are well-supported in lirc.
/dev/lirc will exist in my driver.
Hans Petter Selasky wrote:
On Thursday 26 August 2010 23:29:35 Jim Bryant wrote:
Actually, all of my test programs (for testing my reverse engineering
efforts) have been done in libusb-1.0.
I would actually like to write kernel-level drivers though for these.
Then you should look at existing drivers in /sys/dev/usb/xxx, which
match your device class. What kind of API do you want to userspace?
tty-device, character device?
--HPS
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
