Closed TG-Techie closed 4 years ago
What happens if you change the rotation via the property setter?
ah! I missed it the first time around. I ended up implementing a universal solution.
description updated^
ah "# pylint: disable=too-many-branches" has to be at the top of the function it's affecting.
I tried out this version of the library with a Feather M4 + 2.4" Featherwing. I am getting this error when I attempt to run the library sample code:
File "/lib/adafruit_rgb_display/ili9341.py", line 94, in __init__
File "/lib/adafruit_rgb_display/rgb.py", line 568, in __init__
File "/lib/adafruit_rgb_display/rgb.py", line 163, in __init__
File "/lib/adafruit_rgb_display/rgb.py", line 618, in rotation
Exception: rotation not currently supported for this display, see datasheet
I tried setting rotation=False
in the ili9341.ILI9341()
constructor and then I end up with this error instead:
File "/lib/adafruit_rgb_display/ili9341.py", line 94, in __init__
File "/lib/adafruit_rgb_display/rgb.py", line 568, in __init__
File "/lib/adafruit_rgb_display/rgb.py", line 163, in __init__
File "/lib/adafruit_rgb_display/rgb.py", line 612, in rotation
ValueError: angle must be an 'int' mulitple of 90
Sure. I will get on it
The updated version no longer throws an exception on Feather M4 + 2.4" Featherwing. I tried with and without rotation=False
parameter and both work. Out of curiousity I tried the possible values for the rotation
parameter. I assume nothing is expected to work since the error before stated this screen does not support. Rotation values of 0
and 180
have no effect. With it set to 90
and 270
the red dot in the simpletest appears normal, but the blue "wipe" does not make it all the way off of the screen about 1/4 of the screen remains blue always. Odd, but perhaps not a big problem since this screen appears unsupported.
I think you need to adjust your x y offsets ?
Adjust them as if rotation is 0 regardless of whether or not the display software supports rotation
On Wed, Feb 12, 2020 at 22:36 foamyguy notifications@github.com wrote:
The updated version no longer throws an exception on Feather M4 + 2.4" Featherwing. I tried with and without rotation=False parameter and both work. Out of curiousity I tried the possible values for the rotation parameter. I assume nothing is expected to work since the error before stated this screen does not support. Rotation values of 0 and 180 have no effect. With it set to 90 and 270 the red dot in the simpletest appears normal, but the blue "wipe" does not make it all the way off of the screen about 1/4 of the screen remains blue always. Odd, but perhaps not a big problem since this screen appears unsupported.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit_CircuitPython_RGB_Display/pull/66?email_source=notifications&email_token=AJLXBDCYDJDA4EZRXCOQ7RDRCS54VA5CNFSM4KICLGEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELTIU3A#issuecomment-585534060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJLXBDBNOBPPDDU7DMTIXC3RCS54VANCNFSM4KICLGEA .
@TG-Techie Sorry I'm not sure which offsets you mean. I am using the "Usage Example" from the readme file. The only thing in that code that seem like offsets to me are the x,y coordinates of the red dot. I did tweak those a bit to push it off to one side instead of being in the center and that seems to work fine under all rotation values. The fill()
function draws the black before the red pixel, and the blue after it. I don't see any offsets associated with fill()
. About 1/4 of my screen is staying blue so when it calls display.fill(0)
it is only filling 3/4 of the screen with black, and leaving the other 1/4 blue from before.
@TG-Techie Please let me know if this is something you're still interested in working on. If I don't hear from you, I'll close the PR for now. It can be reopened, and none of your local work is affected by the PR being closed. If at a future time you are interested in picking it up again and it has been closed, let me know and I can reopen it.
Closing for now.
add hardware rotation support across all board (if enabled and configured in subclasses) also, add rotation (with offsets there too) to the simplest so make sure people know it exists
the additions auto re-configure the x/y offsets based on their initial inputs, relative to the 0-degree rotation. Adding rotation to all the boards should be "relatively easy". only one function needs to be implemented. (the above statement is dependent on hardware complexity / ease)
has been tested on hardware but some extra testing wouldn’t hurt. especially if there are st7789 with non-square ratios.