The expectations of displayio.Display and frambufferio.FramebufferDisplay
are different when it comes to rotation.
In displayio.Display, if you call core_construct with a WxH = 64x32
and rotation=90, you get something that is 32 pixels wide and 64 pixels
tall in the LCD's coordinate system.
This is fine, as the existing definitions were written to work like this.
With framebuffer displays, however, the underlying framebuffer (such as
RGBMatrix) says "I am WxH pixels wide in my coordinate system" and the
constructor is given a rotation; when the rotation indicates a transpose
that means "exchange rows and columns, so that to the Groups displayed
on it, there is an effectively HxW pixel region for use".
Happily, we already have a set_rotation method. Thus (modulo the time
spent debugging things anyway:) the fix is simple: Always request no
rotation from core_construct, then immediately fix up the rotation
to match what was requested.
Testing performed: 32x16 RGBMatrix on Metro M4 Express (but using
the Airlift firmware, as this is the configuration the error was reported
on):
* initially construct display at 0, 90, 180, 270 degrees
* later change angle to 0, 90, 180, 270 degrees
* no garbled display
* no safe mode crashes
e.g., allocating a 192x32x6bpp matrix would be enough to trigger this
reliably on a Metro M4 Express using the "memory hogging" layout.
Allocating 64x32x6bpp could trigger it, but somewhat unreliably.
There are several things going on here:
* we make the failing call with interrupts off
* we were throwing an exception with interrupts off
* protomatter failed badly in _PM_free when it was partially-initialized
Incorporate the fix from protomatter, switch to a non-throwing malloc
variant, and ensure that interrupts get turned back on.
This decreases the quality of the MemoryError (it cannot report the size
of the failed allocation) but allows CircuitPython to survive, rather
than faulting.
Otherwise, out of range writes would occur in tilegrid_set_tile, causing a safe mode reset.
```
Hardware watchpoint 6: -location *stack_alloc->ptr
Old value = 24652061
New value = 24641565
0x000444f2 in common_hal_displayio_tilegrid_set_tile (self=0x200002c8 <supervisor_terminal_text_grid>, x=1, y=1, tile_index=0 '\000')
at ../../shared-module/displayio/TileGrid.c:236
236 if (!self->partial_change) {
(gdb)
```
Builds of the esp32s2 targets frequently fail:
```
-- Found Git: /usr/bin/git (found version "2.28.0")
-- Initialising new submodule components/asio/asio...
warning: could not look up configuration 'remote.origin.url'. Assuming this repository is its own authoritative upstream.
Submodule 'components/asio/asio' (/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git) registered for path 'components/asio/asio'
fatal: repository '/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git' does not exist
fatal: clone of '/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git' into submodule path '/home/runner/work/circuitpython/circuitpython/ports/esp32s2/esp-idf/components/asio/asio' failed
Failed to clone 'components/asio/asio'. Retry scheduled
fatal: repository '/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git' does not exist
fatal: clone of '/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git' into submodule path '/home/runner/work/circuitpython/circuitpython/ports/esp32s2/esp-idf/components/asio/asio' failed
Failed to clone 'components/asio/asio' a second time, aborting
CMake Error at esp-idf/tools/cmake/git_submodules.cmake:48 (message):
Git submodule init failed for components/asio/asio
Call Stack (most recent call first):
esp-idf/tools/cmake/build.cmake:78 (git_submodule_check)
esp-idf/tools/cmake/build.cmake:160 (__build_get_idf_git_revision)
esp-idf/tools/cmake/idf.cmake:49 (__build_init)
esp-idf/tools/cmake/project.cmake:7 (include)
CMakeLists.txt:8 (include)
```
It's not clear how/why this happens--is it something to do with our
multithreaded build?. Attempt to clear it up by manually checking out these
submodules ourselves.
A crash like the following occurs in the unix port:
```
Program received signal SIGSEGV, Segmentation fault.
0x00005555555a2d7a in mp_obj_module_set_globals (self_in=0x55555562c860 <ulab_user_cmodule>, globals=0x55555562c840 <mp_module_ulab_globals>) at ../../py/objmodule.c:145
145 self->globals = globals;
(gdb) up
#1 0x00005555555b2781 in mp_builtin___import__ (n_args=5, args=0x7fffffffdbb0) at ../../py/builtinimport.c:496
496 mp_obj_module_set_globals(outer_module_obj,
(gdb)
#2 0x00005555555940c9 in mp_import_name (name=824, fromlist=0x555555621f10 <mp_const_none_obj>, level=0x1) at ../../py/runtime.c:1392
1392 return mp_builtin___import__(5, args);
```
I don't understand how it doesn't happen on the embedded ports, because
the module object should reside in ROM and the assignment of self->globals
should trigger a Hard Fault.
By checking VERIFY_PTR, we know that the pointed-to data is on the heap
so we can do things like mutate it.
Scott Shawcroft
Jeff Epler
Kevin Matocha
Jeff Epler
Jeff Epler
Hosted Weblate
Taku Fukada
Wellington Terumi Uemura
Dan Halbert
Dan Halbert
Jonny Bergdahl
Limor "Ladyada" Fried
Scott Shawcroft