ok, here's a dilemma...

the imon vfd has a bargraph mode (called equalizer mode using the soundgraph imon software in winblowz) has a certain level of wierdness in it.

i am leaning towards inclucing it's data massaging into the kernel driver, as it's use is a bit touchy.

it has off and sixteen vertical levels 1..f bottom to top. each char column on both lines is used to form a single bar in the graph.

the code to do this in my test program is as follows (he question is should i or should i not include this in the kernel driver, as it is totally undocumented by anyone other than myself. the manufacturer won't even answer questions or provide requested documentation. and given the recent supreme court ruling, i can reverse-engineer the interface to my heart's content legally. i bought hardware, and want to use it):

/* im is a descriptor container structure pointer.

   ib is the input buffer of length 16 containing values of 0..16

dt is a delay to prevent overrun, and may not be in the final code, this is a quick hack without error checking for non-deliverables
*/

int imonSendBargraph(struct imon *im, unsigned char *ib, int dt)
{
 int i, j, odd;
 unsigned char nh, nl, c, ob[16];
unsigned char xt[9] = { 0x00, 0x01, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f };

 bzero(ob, 16);

 j = 8;

 for(i = 0; i < 16; i++)
 {
   if ((c = ib[i]) > 16) return(-1);

   if (c > 8)
   {
     nh = c - 8;
     nl = 8;
   }

   else
   {
     nh = 0;
     nl = c;
   }

   if (i % 2)
   {
     ob[j] |= xt[nl];
     ob[(j++) - 8] |= xt[nh];
   }

   else
   {
     ob[j] |= (xt[nl] << 4);
     ob[j - 8] |= (xt[nh] << 4);
   }

   /*
   int odd;

   ob[j] |= (odd = (i % 2)) ? xt[nl] : (xt[nl] << 4);
   ob[j - 8] |= odd ? xt[nh] : (xt[nh] << 4);

   if (odd)
   {
     ++j;
     odd = 0;
   }
   */
 }

imonSendCommand(im, ob[0x00], ob[0x01], ob[0x02], ob[0x03], ob[0x04], ob[0x05], 0xff, 0x40); delay(dt); imonSendCommand(im, ob[0x06], ob[0x07], ob[0x08], ob[0x09], ob[0x0a], ob[0x0b], 0xff, 0x42); delay(dt); imonSendCommand(im, ob[0x0c], ob[0x0d], ob[0x0e], ob[0x0f], 0x00, 0xff, 0xff, 0x44); delay(dt);

 return(0);
}

after the driver is in place, i might add a plugin for xmms to take advantage of this.

given that all of the marketing photos of this (the antec veris elite) display this "equalizer" bargraph, i'm highly surprised that none of the linux people have bothered to reverse-engineer it and take advantage of it.

oh well, they can port it from freebsd when i'm done.  heh!

is this level of bit-fiddling acceptable in the kernel? this is the most efficient version of doing this that i have come up with so far. the bit with the rval conditionals was just fucking around, and not intended for production code.

jim

_______________________________________________
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"

Reply via email to