I did compress Ubuntu-Light.ttf with 4x4, although this makes the binary pretty huge without benefit.
I also saw this huge "layout width" but it just worked for me.

Very strange.

Ok, I went back and converted Ubuntu-Light.ttf with exactly your settings.
The output is the same, only my "Font Preview" is showing the font at perhaps half the size than in your screen shot.
My .map file has the .xfont at 113536.

I almost copied your code:

    if (E_OK == EVE_init_flash())
    {
        EVE_cmd_flashread(MEM_FONT1, 113536, (309|3)+1); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */
    }

    EVE_cmd_dl( CMD_DLSTART );
    EVE_cmd_dl(CLEAR_COLOR_RGB(51,51,51));
    EVE_cmd_dl( CLEAR( 1, 1, 1 ) );
    EVE_cmd_dl( VERTEX_FORMAT(0) );
    EVE_cmd_setfont2( 12, MEM_FONT1,       0 );
    EVE_cmd_dl( DL_END ); // does not do anything here
    EVE_cmd_dl( DL_DISPLAY );
    EVE_cmd_dl( CMD_SWAP );
    EVE_execute_cmd();

    EVE_cmd_dl( CMD_DLSTART );
    EVE_cmd_dl(CLEAR_COLOR_RGB(0,0,18));
    EVE_cmd_dl( CLEAR( 1, 1, 1 ) );
    EVE_cmd_text( 10,  10, 12, 0, "Quick fox at 120°C ");
    EVE_cmd_dl( DL_END ); // does not do anything here
    EVE_cmd_dl( DL_DISPLAY );
    EVE_cmd_dl( CMD_SWAP );
    EVE_execute_cmd();

And it still works, I get the line displayed at the top of the screen.

I am re-installing EAB now, I may have changed something before.
I redid it all, looks like I either modified EAB or previously did not install from scratch, or both.
The new .glyph file is different for some reason.
But the result is still the same, the line is printed just fine.

As I just got a new company style guide to comply with I went thru a number of different fonts and font-sizes today using EAB 2.10.2.
I am using the fourth flash image now with only Roboto font in sizes 12/14/16/18/20/22/24/26/28.
I also tried Ubunto-Light, a couple of other fonts and using odd sizes 19/21/23/25/27.

And well, it just works in all sizes.
My input character file is this:
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~©«°±²³´µ¹»¼½¾ÄÖ×Üßäëö÷øü"
So only "Basic Latin" and a selection from "Latin-1 Supplement".


I encountered three "issues".
First one was that EAB 2.10.2 is using the correct size for the .xfont files now and adds a meta-file .pad in between the entries.
And at first I just copied the size for the .xfont file from the .map and used it with CMD_FLASHREAD - but the number of bytes read must be a multiple of 4.
In earlier versions of EAB there was no .pad and the .xfont ended up beeing shown with a size of 320 bytes.

My second issue was that I tried to use bitmap handle 15 for one of the fonts, just counting up from 12, which does not work by default as this is the scratch bitmap handle.

And my third issue was that the bandwith of the external flash is of course limited, even more so with random access, so I can not use the six fonts I set up for display from the external flash at the same time.
Well, I could use the font-cache for at least the largest font and copy all 9 fonts to RAM_G as the flash image is only 275kiB (copying the .glyph to RAM-G also requires to adapt the .xfont file to use the new memory location).
But this is not a real project anyways.

Edit: I tried a couple of things including over-clocking (looked stable at 96MHz but I went back to 72MHz)
I set REG_AH_HCYCLE_MAX to 4000 and now I have the line "Quick fox at 120°C" printed out in six different sizes: 18/20/22/24/26/28 and reading REG_FRAMES once per second and calculating the delta to the previous value shows rather stable 58 to 59.
So that really makes the last point a non-issue as well, even without copying any of the .glyph files to RAM_G.



In regards of EAB 2.10.2 I found a couple of things a bit odd.
- why is "Reserve Space" not set as default?
- why is "L8" selected by default for "Extended Format"?
- why is the ASTC set to 4x4 by default instead of a more reasonable 8x8?
- why is this SampleApp generated every single time? can we please have a switch for that which defaults to off?

cmd_text( 10,  10, 1, 0, "\u00D6sterreicher \u00E4rgern sich \u00FCber \u00E4gypter");

Besides the issue, that is an odd way to work with strings.
I just use UTF-8 encoding for my source files, so in this case I would have "Österreicher ärgern sich über Ägypter" in the text.

That is interesting, I converted that code to work with my library to see if your library is at fault.

void TFT_display(void)
{
    if(tft_active != 0U)
    {
        EVE_cmd_dl(CMD_DLSTART); /* start the display list */
        EVE_cmd_dl(DL_CLEAR_COLOR_RGB | BLACK); /* set the default clear color to black */
        EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);

        for(uint32_t i = 0; i < SENDNOPS; i++)
        {
           EVE_cmd_dl(DL_NOP);
        }

        EVE_color_rgb(0x600060);
        EVE_cmd_dl(VERTEX_FORMAT(3));
        EVE_cmd_dl(DL_BEGIN | EVE_LINE_STRIP);
        EVE_cmd_dl(LINE_WIDTH(5 * 16));
        EVE_cmd_dl(VERTEX2F(10 * 8, 10 * 8));
        EVE_cmd_dl(VERTEX2F(500 * 8, 500 * 8));
        EVE_cmd_dl(DL_END);
       
        EVE_cmd_button(250, 100, 100, 100, 28, 0, "Button");
        EVE_cmd_button(400, 100, 100, 100, 28, 0, "Button");
        EVE_cmd_button(550, 100, 100, 100, 28, 0, "Button");

        EVE_color_rgb(WHITE);
        EVE_cmd_number(100, EVE_VSIZE - 50, 26, EVE_OPT_RIGHTX, display_list_size); /* number of bytes written to the display-list by the command co-pro */

        EVE_cmd_dl(DL_DISPLAY); /* instruct the co-processor to show the list */
        EVE_cmd_dl(CMD_SWAP); /* make this list active */
       
        EVE_execute_cmd(); /* wait for the display list to be processed */
    }
}

And like this I can set SENDNOPS to 1003 with a resulting display list of 4784 bytes before the display glitches out.
Commenting out the three buttons I can set SENDNOPS to 1334 which is a display list of 5432 bytes.
So I can go higher, but I can not use the full 8kiB of the display list either.

One thing that could go wrong is that the CMD-FIFO is getting full since it only has 4kiB.
But that is not the issue, I am using individual commands in this example, no DMA, chip-select low, address, command, chip-select high.
It should not be possible to throw in more in the FIFO like this than the co-processor can handle.
But to make sure I slowed down the SPI and also added a busy-wait for the FIFO to be empty in the loop - makes no difference.

In a different project that really is putting stress on the BT817 with thousands of line-strip segments, I am using DMA and fill the FIFO with 3676 bytes with a resulting display list of 6108 bytes - but it glitches out after a minute or less.
When I put in less it runs longer without issue - and by less I mean less iterations, like "only" using 36 points per line strip instead of 64.
It looks like my BT817 is overheating, pretty sure it is not, but it looks like it is.

Oh, another observation out of a hunch, updating the display list less often seems to help as well, I am at 20Hz / 50ms now with 5672 bytes in the display list.

This does not help with the program above though, the limit is still 1334 NOPs with a display list of 5432 bytes.

Also, I want to express my gratitude to Rudolph for his amazing work. Big thanks for that!

Thank you!


This made me realize that I probably never tried to calibrate my RVT101HVBNWC00-B. :-)
The touch worked ok as is.

TransMatrix1 = 65536;
TransMatrix2 = 0;
TransMatrix3 = 0;
TransMatrix4 = 0;
TransMatrix5 = 65536;
TransMatrix6 = 0;

These are the reset values for the registers, I am getting the same values here with no calibration.

The values I am getting after calibration are all over the place:
REG_TOUCH_TRANSFORM_A : 0x0000FF2F
REG_TOUCH_TRANSFORM_B : 0xFFFFFEAB
REG_TOUCH_TRANSFORM_C : 0x0005CACE
REG_TOUCH_TRANSFORM_D : 0xFFFFFCAA
REG_TOUCH_TRANSFORM_E : 0x00010116
REG_TOUCH_TRANSFORM_F : 0x00044696


And now I know again why I usually keep the RVT101HVBNWC00-B up on the shelf. :-)
It is big.
It is bright.
It is big.

My code usually checks for touch events every 5ms and that function does three reads now.
Reading REG_CMDB_SPACE to check if EVE is still busy from the display refresh or if there was a co-processor fault.
Reading REG_CMD_DL as a debug measure to get the size of the last generated display-list.
Reading REG_TOUCH_TAG.

I just did an experiment with a Teensy 4.1 under Arduino as this was wired up to the logic analyzer.
The SPI clock is 16MHz.
I moved out the function call to check for touch events that I placed in the loop() function to outside
the code that checks that 5ms passed.
And all that happens is that I can see with the logic analyzer that the SPI is flooded.
The REG_TOUCH_TAG is read every 12µs.

Now I commented out the reading of REG_CMD_DL which means that REG_TOUCH_TAG is read every 8µs.

Ok, I can get away with not reading REG_CMDB_SPACE since I have an internal flag for the DMA transfer of the display update.
And reading REG_TOUCH_TAG does not interfere with the co-processor.
Now the logic-analyzer traces shows reads of REG_TOUCH_TAG about every 3.6µs.

And the EVE3-50G module which has a BT815 and a GT911 is just fine.
No crash and the touch still works fine.

So no, there does not appear to be a limit on how often REG_TOUCH_TAG can be read.
My display update is every 20ms though, so it really does not help to read the register >5400 times in between. :-)

My main loop does this now, 5ms per step:
read read read display read read read display

And there probably would not be a noticeable difference if I changed that to >read / display< with 10ms steps.

Hmm, I wonder now how long touch events actually are, or rather how short these can get.
I went back to reading REG_TOUCH_TAG every 12µs and added a counter that is set to 1 on registering the touch of a button and gets increased as long as the button is touched.
And I can not get this time realiably below 3000.
Right now the number is 1142 which meant I managed to touch the button for only 13ms.
2161 - 28ms
976 - 12ms
2138
3298
4417
3275
3304
2156

Going back to 5ms timeslots I can not get the counter lower than 3.
And not trying to touch as fast as possible I get closer to 20.

So I guess it is ok to assume that the duration of touch events is at least 10ms.