| Age | Commit message (Collapse) | Author |
|---|
|
|
|
@cwalther determined that for boards with 2 displays (monster m4sk),
start_terminal would be called for each one, leaking supervisor heap
entries.
Determine, by comparing addresses, whether the display being acted on
is the first display (number zero) and do (or do not) call start_terminal.
stop_terminal can safely be called multiple times, so there's no need
to guard against calling it more than once.
Slight behavioral change: The terminal size would follow the displays[0]
size, not the displays[1] size
|
|
A call to supervisor_start_terminal remained in
common_hal_displayio_display_construct and was copied to other display
_construct functions, even though it was also being done in
displayio_display_core_construct when that was factored out.
Originally, this was harmless, except it created an extra allocation.
When investigating #3482, I found that this bug became harmful,
especially for displays that were created in Python code, because it
caused a supervisor allocation to leak.
I believe that it is safe to merge #3482 after this PR is merged.
|
|
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
|
|
This gives us better granularity when implementing new ports because
PWMOut is commonly implemented before PulseIn and PulseOut.
Fixes #3211
|
|
Co-authored-by: Scott Shawcroft <scott@tannewt.org>
|
|
|
|
|
|
arguments
.. and introduce a convenience macro that helps many of them be required
(if their values match defaults or are inapplicable)
|
|
|
|
|
|
A bit of cheating; we need to add a protocol getter for
reverse_bytes_in_word
|
|
|
|
This avoids the message "Too many displays in use" when they are released
directly, rather than via release_displays().
|
|
|
|
If set_brightness was implemented but get_brightness wasn't, this
would hard fault
|
|
if we don't set the flag via accessor fn the tick enable might become wrong
|
|
This is a step towards restoring the efficiency of the background
tasks
|
|
This can be enforced by pre-commit, but correct it separately to make it easier to review.
|
|
This isn't perfect and needs a bit more testing.
|
|
|
|
|
|
|
|
|
|
|
|
|
