Open sudhishu opened 2 weeks ago
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. 🤖💙
@sudhishu can you help submit a PR with your fix
ping @MrMarteng @joelguittet for awareness
@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.
The correct approach to fix the code according to the implementation is :
Add the following command entry into the struct default_init_regs
array.
{
.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.
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:
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.
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):
Additional context