MatrixOrbital displays inverted P for some displays

[ghost]

I don't know how common this is but it seems at least one newer display makes the CG ROM for character 255 (0xFF) an inverted P so it doesn't look right on my LK202-25-USB. I think a workaround will be needed, perhaps using one of the custom character graphics. See here where it appears around page 34 in the manual: https://www.matrixorbital.com/index.php?route=extension/module/product_downloads/get&did=130

[ghost]

After looking into it some more it appears that the displays have several variants of the builtin CG ROM. It impacts more than just this. I'll see if I can I can make it configurable so users can choose the mapping that is correct for their device.

[ethandicks]

I appreciate any contributions. This isn't a new issue in that some HD44780 modules have the European or Cyrilic character set not the Japanese one.

This is a wider issue than just the Matrix Orbital driver and accommodating a couple of new models. Let's start here with an eye for a general solution.

[ghost]

What did you have in mind? From my research it appears the MtxOrb driver was built for a CG ROM that I can only confirm was used in one display. The rest seem to use the same newer CG ROM layout. I'm not sure if this is used by anything else at this point.

[ghost]

It appears that we would need to dynamically select whether to use custom characters or rely on the builtin ROM, which is where the type of CG ROM (assuming there's not too many of them) matters.

[ghost]

Ok... it seems while there's a few CG ROMs that are common, each display vendor is free to choose their own layout. I don't know lcdproc that well but it seems that this is mainly an issue for the icon drawing. I can see an option right now where we have the driver provide a table mapping icons to existing ROM characters. If one isn't provided we could use the custom character feature to provide it instead. This would basically end up with us using a lookup table to determine how to draw the icon.

[ethandicks]

Most of the icons are already soft-drawn (open/closed heart, menu checkboxes, vbars, hbars, bignums). I think the only non-textual character that is expected in ROM is the filled block.

That said, some ROMs do have hbar and vbar chars already. A scheme to allow any icon to be subbed by one in ROM sounds like a good approach.

[ethandicks]

I have a wide assortment of modules. Most have the standard Japanese set in ROM. Some do not. I'll have to see about reviewing the stack for testing.

[ghost]

And being able to use the custom graphics to substitute icons would also be helpful, especially if it's in one place. It seems to be a copy pasta in most HD44780 drivers.

[ethandicks]

There currently isn't a good way to allow totally custom chars from the user without really ripping out and refactoring the entire icon/soft char mechanism. I can think of ways to hack it but it really should be a well-considered change.

Part of what could use some retooling is better tracking of what state the soft chars are in and not just sending the same definitions over and over, but it's safer to just slam in all the chars all the time based on what "mode" (hbar, vbar, bignum, etc). It's not so bad with displays that only have 8 soft chars, but there are some displays with more (I have a bignum set for the jw002 display that needs 28 soft chars). That's a lot of data to be pushing for every frame update.

The icon stuff is independent of the module type (but supported by driver code in each driver for hardware-specifics). Large functional changes will require more than just fiddling one driver.

[ghost]

I was considering a solution where the driver has a table mapping the icon to a character code in the regular ROM. The ones not provided by this can replaced by a fallback value or even a CC entry when in standard mode.

[ghost]

Actually, that problem of redefining characters could be solved by caching the set characters and only sending it if it's different from the slot it is being assigned to. Far simpler than tracking the CG mode.

[ghost]

I think I am going to work on an IconTable from each driver that is combined with a general table to map icons to ROM characters. This table will be used for all icons but CCs can be used for select icons. I suspect the best way to decide whether to use a CC for an icon is going to be configuration related if this is to be a general solution. We could accept a list of icon names to use CCs for, up to the limit of what each driver can take.

[ethandicks]

Sounds like a good approach. Just keep in mind both ends of the feature spectrum (less than 8 soft chars and more than 8 soft chars). It's why we have several bignum types for displays with various capabilities.

[ghost]

@ethandicks I was looking through the drivers and I noticed there's a LOT of code duplication. This code could benefit from a common driver that everything either "inherits" or "extends" from so there's less driver specific code. I think the easiest option without requiring a complete re-factoring of the existing code would be to use template files that include the necessary code so the original files can just be a skeleton that retains the expected structure but common code fragments go into template files to be included where needed. This means that while the code is still duplicated in the compiled output it will only occur once in the actual source code which should help reduce maintenance costs in the future. I'll work on that before this since I'm frustrated by all the copy pasta here.

[ghost]

On second thought, would it make more sense to port drivers like MtxOrb to a HD44780 driver backend? It seems very similar.