LCDproc development and user support list

Text archives Help


Fwd: Re: [Lcdproc] Re: VLSYS L.I.S 2005 Driver written


Chronological Thread 
  • From: peter AT adpm.de (Peter Marschall)
  • Subject: Fwd: Re: [Lcdproc] Re: VLSYS L.I.S 2005 Driver written
  • Date: Sat May 26 19:49:03 2007

Hi Daryl,

On Thursday, 24. May 2007 03:29, Daryl F wrote:
> I analyzed the CFontPacket and IOWarrior code's use of the helper
> functions. They won't work well with lis because the device won't let me
> write to specific columns and only has eight customizable characters.

The exact same is true for the two drivers I mentioned.
They only support 8 custom chars.

Contrary to the lis driver they support defining custom characters
to different symbols at different times. I.e. they do not define
custom characters once but change them to what is needed for the
specific situation.

In order to avoid having to use more than 7/8 characters at a time,
they use perform mode setting and checking: see the p->ccmode
variable for that.
It makes sure that hbars, vbars and big nums cannot be together on a
screen. Most of the drivers have this limitation due to the restriction
custom characters available (which BTW is 8 for most displays ;-)

> The problem occurs when the lib_hbar function writes on the left side of
> the display and uses custom characters to do it. Later, if a client
> writes on the right side of the display, also using say bignums, the
> custom characters for the horizontal bar are no longer present in the
> device when lis is forced to rewrite the line starting at column 1.
> Garbage results. Too bad VLSystem wouldn't release more information on
> the device.

This is also no problem. Defining a widget (num, hbar, vbar, ...)
in the client dies not affect the order in which the things are written
to the display.
LCDd converts the client's widget definition into calls to the driver
functions (hbar, string, chr, icon, ...) which - for most drivers -
no nothing more than filling a frame buffer with the contents of the
display and - in the case of hbar(), vbar() and sometimes icon()
sets one or more custom characters.
At the end of each update cycle LCDd's rendering core calls the
flsuh() function of the driver which draws the contents of the
frame buffer to the display (with/without all the optimisations
that the display allows).

So, believe me, it is possible.

It is also possible to convert the function defining characters to use
one bit per pixel instead of one byte per pixel as the other drivers do.
(the b___XX_ definitions are nothing more than byte constants defining
which bits in a pixel row are set to one: X = 1 and _ = 0.
Please try to convert the driver to this style.
All current drivers use it.

The result will be even shorter and easier to understand than the current
one and saves a lot of space in the driver.

Having then changed the definition for new custom characters to this
style at "run time" (as described above) in a standard set_char()
function from the ABI gives you the hbar, vbar and bignum functions
almost for free: they should be almost bit for bit identical to the ones
in the drivers I mentioned above.
.

> I can't believe I managed to lose my updates to the docbook files. But
> it turned out for the best. In thoroughly documenting it I found I'd
> left support in for Device= in the config file from an earlier attempt
> to use libusb. It should be VendorID= and ProductID= now that I'm using
> libftdi.

I am not so sure if it is a good idea to force the user to find out the
Product- and VendorID of his display. I guess they are always the same
values for all users anyway.
If possible I prefer the "Display" setting as I hope [with the help of
interested users] to convert all drivers to use this setting to indicate
the device in the future (especially the parport drivers).


> I documented the requirement to have libftdi installed when building
> lcdproc with the lis driver.
>
> I also cleaned up the lis.c source file a bit, moving some constants to
> lis.h where they belong, getting rid of some spaces that should have
> been tabs to make the code format better. And removing some unreachable
> code, namely a test function I'd used in the past.
>
> Cleaned unneeded function prototypes out of lis.h
>
> Also changed the default Brightness= in lis.c to 1000 as that is what
> the comments in LCDd.conf actually said. Update the comments in
> LCDd.conf as Brightness= can only control four different settings on the
> actual device.

Patch committed to CVS.

Thanks
Peter

--
Peter Marschall
peter AT adpm.de




Archive powered by MHonArc 2.6.18.

Top of page