Full-frame updates send ABGR instead of BGRA
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- python
- Domain
- embedded-iot
Research direction
Start in tinyturing/display.py and locate both full-refresh paths, then compare their byte order with the partial-update path. Verify that full frames use opaque BGRA for the Rev C display and confirm the result with the eight-color test grid.
Written by the indexing model from the issue text.
Description
Hey — there’s a byte-order/alpha bug in tinyturing/display.py.
Pixels are stored as 0xRRGGBB00, so .tobytes() sends 00 B G R on little-endian machines. Rev C full frames expect opaque BGRA: B G R FF. Partial updates are fine because they explicitly send BGR.
On a 5" Red v2 this made white yellow and pure red/green/blue black. Confirmed with an eight-color test grid.
This fixes both full-refresh paths:
-framebuffer = self.framebuffer.transpose().tobytes()
+framebuffer = ((self.framebuffer.transpose() >> 8) | np.uint32(0xff000000)).tobytes()
- Dominant language
- Python
- Stars
- 50
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from tinygrad/tinyos
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100