Display driver GC9X01X - Color inversion enabled by default on GC9A01A.

[sudhishu]

Describe the bug

While using display driver display_gc9x01x with Waveshare GC9A01A round display module, the color inversion is set on by default. Absence or explicit deletion of "display_inversion" node to set it false from device-tree overlay did not give desired result.

Setup:

• HDK = nRF7002-DK + Waveshare GC9A01A round display module.
• SDK = nRF Connect SDK version 2.7.0 and LVGL library for screen.
• Zephyr OS = Version 3.6.99 , build v3.6.99-ncs2
• IDE = Visual Studio Code with Nordic nRF connect plugin installed.

Workaround or attempted fix:

Modified the driver implementation in Zephyr/drivers/display/display_gc9x01x.c
Explicitly set the GC9X01X_CMD_INVON (0x21U) register to 0 during device and register init calls. Proper colors were displayed after applying the fix.

ret = gc9x01x_transmit(dev, GC9X01X_CMD_INVON, 0, 1);
if (ret < 0) {
return ret;
}


To Reproduce

Possibly this is the case with any development board which is using Galaxycore GC9x01x driver. This looks like a registry initialization requirement for the display chip. In this case, the 240x240 px round LCD display using GC9A01A chip is provided by Waveshare.

1. prj.conf
   • Enable CONFIG_DISPLAY and CONFIG_GC9X01X at prj.conf
2. Device tree overlay:

chosen { zephyr,display = &gc9a01a_lcd; }; ... ... ... &spi2 { status = "okay"; compatible = "nordic,nrf-spim"; pinctrl-0 = <&spi2_default>; pinctrl-1 = <&spi2_sleep>; pinctrl-names = "default", "sleep"; cs-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;

gc9a01a_lcd: gc9a01a_lcd@0 {
    compatible = "galaxycore,gc9x01x";
    status = "okay";
    reg     = <0>;
    width  = <240>;
    height = <240>;
    pixel-format      = <(0x1 << 4)>;
    spi-max-frequency = <100000000>;
    cmd-data-gpios     = <&gpio1 11 GPIO_ACTIVE_HIGH>;
    reset-gpios          = <&gpio0 25 GPIO_ACTIVE_LOW>;
    /delete-property/ display-inversion;
  };

};

Note that the /delete-property/ display-inversion was an attempt to set the node explicitly false in the device configuration, but that did not work. Hence not necessary.

Expected behavior

The display should show the desired colors on the screen as set using the LVGL library.
Impact

The entire color scheme on the display was inverted. Failed to create the desired screen.
Logs and console output

None.
Environment (please complete the following information):

• OS = Fedora Linux - 6.5.10-200.fc38.x86_64
• HDK = nRF7002-DK + Waveshare GC9A01A round display module.
• SDK = nRF Connect SDK version 2.7.0 and LVGL library for screen.
• Zephyr OS = Version 3.6.99 , build v3.6.99-ncs2
• IDE = Visual Studio Code with Nordic nRF connect plugin installed.

Additional context

[github-actions]

Hi @sudhishu! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[mmahadevan108]

@sudhishu can you help submit a PR with your fix

[kartben]

ping @MrMarteng @joelguittet for awareness

[sudhishu]

@sudhishu can you help submit a PR with your fix

1. Did you mean "pull-request" by PR ? I am new to the process of Zephyr development. Need time to go through the contribution guidelines doc. I welcome any additional guidance, how-to pointers etc.

2. The fix I attempted was a straight code-insertion according to my understanding of the problem. I see a "default init sequence" looping over a set of commands inside the gc9x01x_regs_init() function. May be, including the GC9X01X_CMD_INVON register value into that command-set (struct default_init_regs array) could be the correct approach to comply with the design of the current implementation. I would like to verify and confirm that first.

[sudhishu]

The correct approach to fix the code according to the implementation is :
Add the following command entry into the struct default_init_regs array.

• Ref: zephyr/drivers/display/display_gc9x01x.c - line 63

{ .cmd = 0x21U, .len = 1U, .data = {0x00U} } This value will be picked by gc9x01x_regs_init() and the color-inversion register will be initialized accordingly. This fix is tested successfully on Waveshare GC9A01A 240x240 px round lcd implementation. Note that the datasheet says that this registry is set to 0 by default, hence the source of problem could be the chip's internal default settings and by this fix, the driver is compensating it.

[fabiobaltieri]

@danieldegrasse could you take a look by any chance?

[danieldegrasse]

I don't have a module with this display controller to test on, but I'm unclear why sending the INVON command like this would work:

ret = gc9x01x_transmit(dev, GC9X01X_CMD_INVON, 0, 1);
if (ret < 0) {
    return ret;
}

The signature of the gc9x01x_transmit function looks like so:

static int gc9x01x_transmit(const struct device *dev, uint8_t cmd, const void *tx_data, size_t tx_len)

So the call you make would try to write 1 byte from 0x0. This may work without causing a fault on some platforms, but it isn't a stable fix- effectively what you are doing is writing a dummy byte of data after the INVON command. This should not be required, as the INVON command should not need a parameter:

Could you possibly look at the data being sent on a signal analyzer? Perhaps there is some odd behavior on your system when transmitting single byte commands to the display