Character handling

[Shenghao Yang]

Hi all, 

I'm trying to give the serialPOS driver a little bit of a facelift, and am trying to add support for other serialPOS displays. 

However, a few things regarding character handling and timeouts aren't really clear, and I was hoping someone could provide some help.

Some background: 

In some POS displays, custom character support requires overriding ASCII character codes with custom glyphs, as there

are no reserved character codes for custom characters. If the server delegates the driver to display a character with an

overridden glyph, it could be *very* confusing for the client. 

The typical approach one uses is to override the control characters, if the display supports them, or character 

codes beyond the normal ASCII character set, to avoid conflicting with the conventional characters. 

This would fall through, though, if the server passes control characters / "high" ASCII characters to the 

driver to display. From a skim of the server source, it seems that it doesn't seem to filter out these characters. 

The portions that aren't really clear:

In a situation where a character conflict does happen, should the driver simply report errors for character conflicts 

and silently substitute conflicting characters / characters it is unable to display? Is there some policy for handling errors like these? 

Is there a constraint on the amount of time a particular driver call must take? Will the whole server simply slow down and miss frames if 

a particular driver takes too long to perform I/O? Should drivers be gracious and abort if they take too long?

Thanks in advance.

Regards,

Shenghao Yang

[Harald Geyer]

"'Shenghao Yang' via LCDproc Mailing List" writes:
> I'm trying to give the serialPOS driver a little bit of a facelift, and am
> trying to add support for other serialPOS displays.

That's great!

> However, a few things regarding character handling and timeouts aren't
> really clear, and I was hoping someone could provide some help.

Well, short answer: ATM there is no proper character encoding support
in lcdproc. LCDd simply treats anything it get's from the clients as
byte stream and forwards it to the driver/display. On top of that some
parts of LCDd assume that each byte is exactly one character.

The last is a bug IMO and should be fixed, the former would be nice to
improve too, but nobody is working on it.

> Some background:
>
> In some POS displays, custom character support requires overriding ASCII
> character codes with custom glyphs, as there
> are no reserved character codes for custom characters. If the server
> delegates the driver to display a character with an
> overridden glyph, it could be *very* confusing for the client.
>
> The typical approach one uses is to override the control characters, if the
> display supports them, or character
> codes beyond the normal ASCII character set, to avoid conflicting with the
> conventional characters.
>
> This would fall through, though, if the server passes control characters /
> "high" ASCII characters to the
> driver to display. From a skim of the server source, it seems that it
> doesn't seem to filter out these characters.
>
> The portions that aren't really clear:
>
> In a situation where a character conflict does happen, should the driver
> simply report errors for character conflicts
> and silently substitute conflicting characters / characters it is unable to
> display? Is there some policy for handling errors like these?

There is no clear policy. The simple solution is of course to just not
support custom characters on these displays at all. The other obvious
solution is to check the frame buffer for needed characters and just
redefine custom characters dynamically to get an optimized result.
Dropping some of the less important (or easy to substitute) ASCII
characters in favor of custom characters would be okay too.

I don't think there is a way in LCDd to report character conflicts.
(Also I don't see which other part of the system should/could react to
such a report, so probably no point in trying?)

> Is there a constraint on the amount of time a particular driver call must
> take?

No. LCDd doesn't care about any realtime guarantees. If the system is
busy with something, LCDd might get suspended for quite a while. (Most
of the code being quite old by now it is written with efficiency in mind,
so usually there are no problems.)

> Will the whole server simply slow down and miss frames if
> a particular driver takes too long to perform I/O?

I don't recall what will happen in detail, but if such a situation causes
serious trouble, it is a bug in LCDd not the driver.

> Should drivers be gracious and abort if they take too long?

This is the decision of the driver. If I/O to the display doesn't
complete, lcdproc is pretty useless anyway, so I think the driver should
try to do I/O as long as there is hope that it will work. However LCDd
in general is single threaded - if a drivers blocks, then no network
communication is performed either and clients might lose their connection.

Some drivers do start threads to be able to use blocking I/O, but I
personally am not a big fan of that and would like to get rid of it if
possible.

I think that for the future it might be nice to use some event loop
implementation like libev for LCDd, but at the moment that's just idle
thought. Generally I'm a big fan of "keep it simple and stupid": Not adding
any code (or complex API) when it doesn't solve an actual problem.

HTH,
Harald

--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

[Shenghao Yang]

Hi, 

Thanks for the help! I think I probably should just follow convention and simply forward received bytes to the display. 

Maybe when someone gets adventurous enough to work on character encoding support and comes up with a new driver API to instruct drivers to send *characters* instead of raw codes... we can then all refactor our drivers

...

Regards, 

Shenghao Yang