Skip to content
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

Jump to bottom

Fix broken colors and partial flush for ILI9488 display #2976

Open
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
andreilukichoff 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++)
andreilukichoff marked this conversation as resolved.
Show resolved Hide resolved
{
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
Member

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
Author

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
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
Author

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
Contributor

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
Author

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
Contributor

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
Author

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
Contributor

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
Loading