Skip to content

Fix broken colors and partial flush for ILI9488 display #2976

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
oddbit-io wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Fix broken colors and partial flush for ILI9488 display #2976

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
adac5aa
Fix broken colors and partial flush for ILI9488 display
oddbit-io Jul 3, 2024
0bae92b
Code style fixes
nfbot Jul 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions src/nanoFramework.Graphics/Graphics/Displays/ILI9488_480x320_SPI.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -289,15 +289,17 @@ void DisplayDriver::BitBlt(

g_DisplayInterface.SendCommand(1, Memory_Write);

uint32_t numPixels = width * height;
uint32_t count = 0;

CLR_UINT8 *TransferBuffer = Attributes.TransferBuffer;
CLR_UINT32 TransferBufferSize = Attributes.TransferBufferSize;

// only 18/24 bit is supported on SPI
for (uint32_t i = 0; i < numPixels; i++)
for (uint32_t y = srcY; y < srcY + height; y++)
for (uint32_t x = srcX; x < srcX + width; x++)
Comment thread
oddbit-io marked this conversation as resolved.
Outdated
{
uint32_t i = y * Attributes.Width + x;

uint32_t element = data[i / 2]; // Each uint32 stores 2 pixels
uint16_t color = (i % 2 == 0) ? (element & 0xFFFF) : (element >> 16);

Expand All @@ -309,9 +311,9 @@ void DisplayDriver::BitBlt(
g = (g << 2) | (g >> 4);
r = (r << 3) | (r >> 2);

TransferBuffer[count++] = b;
TransferBuffer[count++] = g;
TransferBuffer[count++] = r;
Copy link
Copy Markdown
Member

@Ellerbach Ellerbach Jul 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure about the order? I remember the color order is configurable and depends on the driver.

Copy link
Copy Markdown
Author

@oddbit-io oddbit-io Jul 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The driver only supports SPI and Ili9488 only supports 3-byte color in RGB order in SPI mode. I suppose thats why the order was hardcoded initially.

Copy link
Copy Markdown
Contributor

@alberk8 alberk8 Jul 5, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we expose the RGB and BGR to the managed side so that it can be switched in the hardware which correspond to this in nF .

#define RFLAG_COLOR_RGB       0b00000000     /* RGB */
#define RFLAG_COLOR_BGR       0b00001000     /* BGR */

Copy link
Copy Markdown
Author

@oddbit-io oddbit-io Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, this flag alters the output signal for panels with different order, while the buffer always uses RGB. If this is the case, we should substitute the hardcoded MADCTL_BGR constant in DisplayDriver::ChangeOrientation with a variable that may be either MADCTL_BGR or 0.

Copy link
Copy Markdown
Contributor

@alberk8 alberk8 Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you test it out without flipping the RGB values in code?.

Copy link
Copy Markdown
Author

@oddbit-io oddbit-io Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tested it and it works exactly as I expected. It displays incorrect colors with RGB buffer and 0 value instead of MADCTL_BGR, and correct colors with MADCTL_BGR value. And vice versa with BGR buffer.
So my panel utilizes BGR pixels obviously.
I suppose the buffer should always remain RGB since there is no other option mentioned in the datasheet. See page 122.

Copy link
Copy Markdown
Contributor

@alberk8 alberk8 Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Different manufacturer uses different panel with same controller. As far as I know there are two types RGB and BGR.

Copy link
Copy Markdown
Author

@oddbit-io oddbit-io Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes and controller uses RGB for buffer and flag to alter signal for different panels. I don't see why buffer should not be RGB in any case.

Copy link
Copy Markdown
Contributor

@alberk8 alberk8 Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be you want to check with this change and if that is inline with this driver.

TransferBuffer[count++] = g;
TransferBuffer[count++] = b;

// can't fit another 3 bytes
if (count + 3 > TransferBufferSize - 1)
Expand Down