LCDproc development and user support list

Text archives Help


[Lcdproc] Character set mapping and other API related (was the } issue).


Chronological Thread 
  • From: David GLAUDE Mailing" <dglaudemailing AT gmx.net (David GLAUDE Mailing)
  • Subject: [Lcdproc] Character set mapping and other API related (was the } issue).
  • Date: Mon Dec 3 18:09:01 2001

> Yes that's right. Mark Haemmerling added a charmap for the HD44780
> driver that translates from ISO 8859-1. Is that Latin-1 ? It is not
> the 'DOS' charset.

Let say (need feedback from the list here...) all driver should try to do
their best to provide ISO 8859-1 and the _string(?) API should do the
best possible mapping (without accent if not available).
Also the hardware char should not be display if completely different
from ISO 8859-1.
Alternatively a _stringNative could be add to the API for "hardware"
access???

> I think only chars from 32 to 126 are guaranteed. And the HD44780
> cannot even display a backslash !
No joke here, this is sad.

> Should we not make it as easy as possible for client writers ? If we
> assume _one_ device to be the best supported device I think we'll get
> stuck at some point. If they change the charmap for example, like
> CFontz recently did.

Ok, let's say ISO 8859-1 (whatever it mean).
And we will think about internationalisation as soon as someone ask the
question on this mailing list.

> > A scroller is a bit like a string,
> > except that the string we send is bigger than the space were
> > we want to print it...
> > So something like (x,y,lenght,string) should be OK
> > [No warping please]
>
> What is warping ?
wrapping?? to continue on next line...

> Is the length necesary ? Can we not just place a zero terminated
> string there ? Or do we need to be sure that we're able to use char 0
> in the string ? You cannot transport the 0 char through the widget
> language in a string anyway, isn't it ?
Let say I want to display "Hello, World. Welcome to what is left of it!!!"
on a 10 char "window" on the top left of the LCD.
Then I send (1, 1, 10, "Hello, World. Welcome to what is left of it!!!").

> > Another issue is that the driver need to receave some kind of a "beat"
> > to be able to "move" the scroller on the LCD.
> > This is kind of a silent _heartbeat or IBM PC BIOS ticks interupt.
> > That way driver don't need to implement "alarm" mechanisme.
>
> You can do it in flush. Screen should be flushed every tick...

Guarantee?
Isn't it two different concept?
Otherwise I agree we can do it there.

> > Now for the API, we may want a bit more, like style...
> > Start shifting on the left
> > Start shifting on the right
> > Continuous shifting (bouncing shifting)
> > Or restart from the begining (Left or Right) when we reach the end.
> > Complete char or with custom char to make smoth shifting like
> > CrystalFontz
> > And a speed
> > How many ticks before we move a complete char?
> > And delay
> > When do we start shifting (after how much time to let peaple read
the
> > begining)?
>
> Should we really put all this in the API ? That means that a widget
> is geting stored in the driver, and I don't know if that is good.
> Drivers are also getting quite big like this.

Because CrystalFontz does it in hardware and MatrixOrbital not,
it is obviously something that the driver should take care of.
The driver best know how to do it best on that hardware.

But we can keep that for later.
I don't know if it is really good to add feature simultaniously as we
make the API change (any new driver feature is an API change
but here we are talking about THE api change).

> > What help do you need?
>
> Oh that's great. I've now completed the transition of the API and the
> curses and text drivers (without hbar/vbar, also wid and hgt still
> exist). I will now start with wid/hgt and other drivers. But for the
> hbar/vbar a lot needs to be done. Everything needs to be converted
> from the pixel based stuff that is used in the widget language.
Yep, not easy but.
If the API for the new kind of bar is define (at least in the doc)
then we can start "coding" the driver.
It does not mean those function will be used yet. ;-).
I will give it a try in MtxOrb:
Write the function as I expect it and make the conversion layer inside my
driver.

Typicaly the driver part of the quantum leap change should be
distributed accross multiple peaple.
But if we do it in CVS it could break it for a long time.
So I don't know what is the best way to do it right now.

> Also new features may be supported for the bars.
Like? style, reverse increase, arbitrary start/stop position???

> Should we really do this now ?
Not really.

> Or should we wait with this for the next widget language upgrade...
Well currently all the change we have done are in the back office of LCDd.
But one day or another we will have to change the client/server API.
Driver better have to be ready when we make that change!!!

So I think we should define the "ideal" wanna have API. (how do I read you
SGML stuff?)

Then try to implement those new function in some driver (reference driver
like text/curses are very important since everybody can try/see/understand).
It does not mean we use them.

Then provide somewhere a thin translation layer (in the server side or in
the driver).
We start to use them really.

Then shake every driver writer to tell them about the change we need.

When we reach a critical mass of ready to be "migrated" driver,
then we can try the Widget Language change (and server change to call the
new API).
At that time API and driver should be "freeze" at the maximum.
This reduce the size of the window of time where think could break.
Before making that last step we should release a "STABLE" version
for peaple to play with and complain about bug.
That way nobody not interested in development will get if from CVS
since the stable is stable.

> Can you have a look at it ? Should I send you my current (BIG) diff ?
Yes you can send me the diff.

I could make those change for MtxOrb driver (currently other project
have been put in higher priority but as soon as time permit I can get
back to work on LCDd).

David GLAUDE.





Archive powered by MHonArc 2.6.18.

Top of page