Date: Fri, 27 Aug 2010 05:04:02 -0500 From: Jim Bryant <kc5vdj.freebsd@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: writing usb drivers under 8.x Message-ID: <4C778D92.5030003@gmail.com> In-Reply-To: <4C777D12.3040900@gmail.com> References: <4C76AB76.4070806@gmail.com> <201008262232.44775.hselasky@c2i.net> <4C76DCBF.3080904@gmail.com> <201008270856.43512.hselasky@c2i.net> <4C777D12.3040900@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C778D92.5030003>