Open bench2012 opened 1 year ago
Thanks for reporting.
So the kernel version should contain the patch already. A comment in the issue you linked
Armbian has just accepted to apply this patch when building any kernel version.
I hope that Armbian does not have this (no obsolete) patch anymore, or that it does not somehow invalidate the upstream Linux patch so that colours are double-inverted 😄.
... at least they still have the patch: https://github.com/armbian/build/blob/master/patch/misc/fbtft-st7789v-invert-color.patch ... but it is only applied on kernel versions <5.8: https://github.com/armbian/build/blob/b120dda/lib/functions/compilation/patch/kernel-bootsplash-and-drivers.sh#L279-L282
Where did you get the DTS from? It is assured to be correct or NEO2?
Hi,
I extracted the dtbo from Friendlyarm's ubuntu dist. (20.04 lts with 4,14 kernel) and decompile it so it work with Dietpi. The DTS is quite simple with no special init. code, just GPIO definitions and SPI enabling. As I have tested the LCD on a Neo Plus 2 with Friendlyarm's ubuntu dist and it is working correctly, the only different I see is the kernel version (ubuntu is just a soup up debian really) and both board uses the same H5 CPU, they are more or less the same board with added bell and whistle (the Plus2). As I say before, everything works apart from the funny colour. BTW, the shield is from Friendlyarm as well:
https://wiki.friendlyelec.com/wiki/index.php/Matrix_-_2%278_SPI_Key_TFT
Interesting issue.:-)
Probably the DTS works correctly on the legacy vendor kernel only, while it does not work correctly on mainline kernel. To test this properly, you need to test on NEO Plus2 with mainline kernel (like our image), but I know there is this kernel panic issue currently, which makes this difficult, I guess.
There are some DTS posted on the issue you linked, which is about usage with mainline kernel. So those could be tested instead.
I just found this thread after searching for hours for a working dts-file for my 2.0" IPS Panel and now tried yours on a NanoPi Neo. I've exactly the same issue. inverted colors. But at least its working :) Well for me it's not inverted but the color doesn't match. green is more yellow, blue is red...
I use the latest version of Armbian (22.11.1 Jammy Kernel 5.15). Hopefully we find a solution for this...
Okay I think it's working now.
just removed the line
bgr = <0>;
in the dts file. Now the color seems to be okay. Don't know how to use these property right...
Aweaome @bench2012 this works for you as well?
@MaikB85 I guess you needed to adjust the compatible
property to work with NanoPi NEO (Allwinner H3)? We could add this to dietpi-config
, I'm just wondering whether this basically works with all SBCs with SPI and GPIO pins exposed (and kernel with mentioned fix applied) or e.g. on Allwinner or even FriendlyELEC Allwinner SBCs only :thinking:.
Hi,
Unfortunately no. I remove the bgr line and it still displaying funny colour. @MaikB85 mind sharing your dts. I am sure is some stupid that I did. Glad I am not alone with this issue and thanks for your help in advance.
Bench2012
@MaikB85 I guess you needed to adjust the
compatible
property to work with NanoPi NEO (Allwinner H3)? We could add this todietpi-config
, I'm just wondering whether this basically works with all SBCs with SPI and GPIO pins exposed (and kernel with mentioned fix applied) or e.g. on Allwinner or even FriendlyELEC Allwinner SBCs only 🤔.
sure I used
compatible = "allwinner,sun8i-h3";
instead
I tried to get this working with current dietpi version and it shows console output, but have some other issues getting a desktop running for now. But that's another topic.
@bench2012 finally my dts is nearly the same than yours:
/* DTS for 2.0 IPS TFT with SPI Interface */
/dts-v1/;
/plugin/;
/ {
compatible = "allwinner,sun8i-h3";
fragment@0 {
target = <&spi0>;
__overlay__ {
status = "okay";
};
};
fragment@1 {
target = <&pio>;
__overlay__ {
spi0_cs_pins: spi0_cs_pins {
pins = "PC3";
function = "gpio_out";
};
};
};
fragment@2 {
target = <&spi0>;
__overlay__ {
/* needed to avoid dtc warning */
#address-cells = <1>;
#size-cells = <0>;
pinctrl-0 = <&spi0_pins &spi0_cs_pins>;
cs-gpios = <&pio 2 3 1>; /* PC3 */
NanoTFT:NanoTFT@0 {
compatible = "sitronix,st7789v";
reg = <0>;
pinctrl-names = "default";
spi-max-frequency = <32000000>;
txbuflen = <16384>;
fps = <30>;
/* bgr = <0>; */
buswidth = <8>;
rotate = <90>;
width = <240>;
height = <320>;
reset-gpios = <&pio 6 11 1>; /* PG11 */
dc-gpios = <&pio 0 1 0>; /* PA1 */
led-gpios = <&pio 0 0 0>; /* PA0 */
debug = <0>;
status = "okay";
};
};
};
};
I also use the same pins on my nanopi Neo but I'm not using pin PA6. At the moment I'm wondering why this is in the DTS-File. I will do some testings with my working armbian image.
[EDIT] on DietPi it is also working fine for me. so it's not a problem of DietPi. [EDIT2] Config cleanup
HI,
MaikB85, indeed it looks very similar, but I suppose the devil is in the detail. Will compare and try and see it make any different. Will report back later.
Again many thanks,
Bench2012
Hi,
Bad news, it makes no different if I have the bgr = <0>; or not, I even try bgr = <2>; the colour is still wired. I have to call it a day for now, since I have other things to do on this project (I am making a some SqueezeBox with display, figure the NanoPi Neo is small and powerful enough for a streamer). I got a ili9341 lcd working so have to call it a day.
Thanks for the support.
Bench2012
@MaikB85 I guess you needed to adjust the
compatible
property to work with NanoPi NEO (Allwinner H3)? We could add this todietpi-config
, I'm just wondering whether this basically works with all SBCs with SPI and GPIO pins exposed (and kernel with mentioned fix applied) or e.g. on Allwinner or even FriendlyELEC Allwinner SBCs only thinking.sure I used
compatible = "allwinner,sun8i-h3";
insteadI tried to get this working with current dietpi version and it shows console output, but have some other issues getting a desktop running for now. But that's another topic.
@bench2012 finally my dts is nearly the same than yours:
/* DTS for 2.0 IPS TFT with SPI Interface */ /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&spi0>; __overlay__ { status = "okay"; }; }; fragment@1 { target = <&pio>; __overlay__ { spi0_cs_pins: spi0_cs_pins { pins = "PC3"; function = "gpio_out"; }; }; }; fragment@2 { target = <&spi0>; __overlay__ { /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; pinctrl-0 = <&spi0_pins &spi0_cs_pins>; cs-gpios = <&pio 2 3 1>; /* PC3 */ NanoTFT:NanoTFT@0 { compatible = "sitronix,st7789v"; reg = <0>; pinctrl-names = "default"; spi-max-frequency = <32000000>; txbuflen = <16384>; fps = <30>; /* bgr = <0>; */ buswidth = <8>; rotate = <90>; width = <240>; height = <320>; reset-gpios = <&pio 6 11 1>; /* PG11 */ dc-gpios = <&pio 0 1 0>; /* PA1 */ led-gpios = <&pio 0 0 0>; /* PA0 */ debug = <0>; status = "okay"; }; }; }; };
I also use the same pins on my nanopi Neo but I'm not using pin PA6. At the moment I'm wondering why this is in the DTS-File. I will do some testings with my working armbian image.
[EDIT] on DietPi it is also working fine for me. so it's not a problem of DietPi. [EDIT2] Config cleanup
Hi,
Sorry to bother you again, one thing I notice with the Friendlyarm ubuntu is the module may be pre-compile into the kernel, since lsmod doesn't show up any fb__st7789v module, but dietpi does (even with blacklisting the module). Could you check if dietpi did load the fb_st7789v module for you too?
Many thx,
bench2012
Oops, I try a "fake" module install and it truly not load the module and there is no display. So this remains a mystery. Thanks anyway.
Bench2012
Hi all,
Fixed it ! It turns out the latest module source has a flag call HSD20_IPS, which I suppose is for IPS display, which mine isn't. This was define as default, which doesn't help.
So I end up change this to 0:
Recompile the module and it work correctly. I suspected it was gamma related, since gbr=1 in dts file does swap the blue and green around, but the colour is still wrong, ie. all the RGB colour was right, but CMYK colour was wrong.
Another funny thing is the default gamma is for IPS display, but if I change it to default, the colour is still wrong. So I left it as it was and it works.
The only things is now I have to be careful with upgrade and not overwrite the hacked module.
Again this is for Friendlyarm's own 2.8" TFT Touch Shield and YMMV with other ST7789V display.
Now to the next thing is to get the touch panel working.
Anyway, thanks for all the help.
Bench2012
Ah I see, ST7789V is the chip which can be used with different panel types.
YMMV ... https://dictionary.cambridge.org/dictionary/english/ymmv ... ah okay 😅.
What do you think, is this HAT/Shield sufficiently widely used to have this as a request for adding to dietpi-config
for NanoPis? For RPi and older Odroids we have a section there for LCD displays (including touch) setup.
Hi,
Sorry for taking such a ling time to reply. Yes, certainly, since this is display is the official display from Friendlyarm. It would be a shame if it is not supported. Still the module issue might show stopper, unless somehow included into the mainline kernel. I have no idea how to make this configurable within the module without recompiling it.
Anyway hope this is useful for everyone to know.
Bench
Creating a bug report/issue
Required Information
DietPi version |
cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=12 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master' G_GITOWNER='MichaIng' G_LIVE_PATCH_STATUS[0]='applied'Distro version |
echo $G_DISTRO_NAME $G_RASPBIAN
bullseyeKernel version |
uname -a
Linux squeeze-nano 5.15.80-sunxi64 #22.11.1 SMP Wed Nov 30 11:23:00 UTC 2022 aarch64 GNU/Linux
SBC model |
echo $G_HW_MODEL_NAME
or (EG: RPi3) NanoPi NEO2 (aarch64)Power supply used | (EG: 5V 1A RAVpower) 5V 2A (Apple Ipad charger)
SD card used | (EG: SanDisk ultra) Kingston 8G
Additional Information (if applicable)
Software title ST7789V Device Driver
Was the software title installed freshly or updated/migrated? New install
Can this issue be replicated on a fresh installation of DietPi? N/A
Bug report ID |
echo $G_HW_UUID
Steps to reproduce
lcd_st7789_fa.dts:
Expected behaviour
Normal colour?
Actual behaviour
Colour inverted ie. black is white and all the colour wrong
Extra details