Unusual display configuration behavior after updating to 0.7.8
Closed this issue · 5 comments
Expected Behavior
-
Selecting a button layout in the web config would also let you see it change in real time on the hardware's display.
-
Buttons displayed would take up a sufficient amount of space on the display.
Current Behavior
-
The button layout no longer updates in real time. you must change the layout, save changes, exit the button screen on the hardware and re-enter the button screen.
-
Buttons are now smaller with little options to adjust the size of them well.
Context
This was observed on Haute42 G16 Screen after updating from GP2040-CE_0.7.7_Haute42 to GP2040-CE_0.7.8_Haute42COSMOX
This was also seen on their T16 version as well
The pictures shown bellow have the same display configurations but different firmware versions.
G16 screen on 0.7.8
G16 screen on 0.7.8
Need more details on this one.
- Which layouts are enabled on Left/Right sides?
- Is the Input History addon enabled?
Also, the release version does let you change layouts dynamically on that screen. Perhaps you're using a pre-release version of 0.7.8?
-
Stick for the left and Noir 8 for the right.
-
Input history add-on was enabled in both instances.
Since seeing this I redownloaded the file [GP2040-CE_0.7.8_Haute42COSMOX.uf2], flash nuked the hardware properly and updated the firmware again and it's still not letting me change layouts dynamically. The displayed buttons are also still smaller than they used to be.
I've tested this dynamic changing of layouts on my 3 Haute42/COSMOX (M16,S13,G13) devices with screens using release 0.7.8 and cannot reproduce the issue with Input History both on and off. I've had a few folks confirm that this is also working for them, but I'll include it in my stress testing for the next release.
As for the smallness of the layouts, this is by design. As of 0.7.8, we now scale layouts wholesale to fit between the two lines of text when Input History is enabled. There may be some layouts that could benefit from being larger to accommodate this new scaling, so I'll go through them and see what changes can be made.
Some history: Previously, layouts would use the full size of the display below the top status bar. Once the Input History was added, certain layouts would collide with the history line on the bottom. When the addon was written originally, it would shift the layout upwards a few pixels, but that too isn't optimal for the same reasons. Thus: scaling.
Please confirm if the behavior still exists in PR #974.
Closing due to lack of answer. Resolved from our testing.