@agillis waveshare-s3-touch-7b git pull broken

Using @agillis configuration file for the waveshare-s3-touch-7b (improved version) the custom component for the i/o expander is mis-named in the git pull (dunno if I am using the right terminology). The yaml calls out “waveshare_io” but the git pull has “waveshare_io_ch32v003”

I’m not that familiar with github, but it looks like Andrew might have forgotten to commit the component, leaving his development code in place. In any case, pointing the yaml to the pulled name compiled. We’ll see if it works after I get my display tomorrow :slight_smile:

I’m not including the error messages because I am sure Mr. Gillis will instantly understand the issue. BTW. super thanks for the configuration file! Your repository is a fountain of great ideas and code.

You may be better off reporting it in GitHub where the developer will see it.

Done. Thanks.

It’s not broken and I have not made any changes to that code since August It seems to be working fine here. Try this demo file on your screen.

This will get you some a boot screen, info screen and some basic buttons plus allow you to use the backlight control.

Andrew, I have been using your driver with some issues.

I rotate the display and touch stops working. I solved this by setting rotation to 90, then swapping xy and mirroring y

The colors are all wrong. I kind-of solved this by using “BGR” instead of “RGB”. Now they are sort-of correct, but muted and muddy.

  • white is a greyish green
  • Blue is greenish-blue
  • Red is blood-red

My digital-overlord tells me that the observed behavior suggests the panel is in RGB666 mode vs. RGB888 (or maybe the reverse) and some MSBs are being truncated.

Any hints/suggestions what is going on? I have not tried to compile your demo code. I simply copied your hardware file and built on top of that (rotate and transform for display and touch respectively)

Thanks

I would say try the full demo. It should work much better and give you a working starting point.

I finally figured out my issues: The driver works fine. Somewhere I got “byte_order: little_endian” in my LVGL section. I finally noticed byte_order in the top level of your sample code, but I notice it is missing from the current source in Github. You must have deleted it recently.

Anyway, it might be nice to annotate the hardware yaml that the required byte order, even though “big_endian” is default, in case someone else sneaks a “little_endian” into their yaml (some AI hallucination in my case) and can’t figure out why the colors are so whacky.

Yes esp32-p4 chips require byte_order: little_endian and most other ESP32 chips require big.

I have code that takes care of all of this in my repo. Each hardware files has the correct setting.

I also have a code that fixes all your images. They also need to be big or little. See how that works in my demos as well.