raspberrypi
Support for RZW T101P136CQ in ili9881c
Note: this is in draft because I need to test it, and possibly deal with some other driver shenanigans of a similar nature to do so.
This adds support for the above-mentioned model of panel from RZW. This panel is found in certain industrial HMIs manufactured by EDATEC (e.g. the ED3010-*). Unfortunately, these enclosures are (currently) only usable with a modified build of Linux 6.6 that EDATEC have not released any source code for. Among other changes, that kernel image includes additional ili9881c device profiles for the display found in the enclosures I wish to use. Notably, where ili9881c would turn on the reset pin to reset the device, the modified ili9881c found in that image turns off the reset pin. I have added functionality to invert reset polarity as such.
Releasing a kernel image without offering the source code is in breach of the GPLv2 licence the Linux kernel is released under. You could point them to term 3 of https://www.gnu.org/licenses/old-licenses/gpl-2.0.html and ask them which of the 3 options they comply. We do work with EDATEC, so I can give them a nudge if you get no joy.
The extra init sequences, display modes, and compatible lookups I have no issue with.
Inverting the reset line should be done via the overlay. If it were our V2 panels that use ILI9881 with the vc4-kms-dsi-ili9881-7inch overlay, changing line 56 from:
reset-gpio = <&display_mcu 0 GPIO_ACTIVE_LOW>;
to
reset-gpio = <&display_mcu 0 GPIO_ACTIVE_HIGH>;
would do the same as your code change.
The state requested in the driver is meant to be the logical state for the signal, hence gpiod_set_value_cansleep(ctx->reset, 0); to deassert reset and become active. Physical state is conveyed via the ACTIVE_[HIGH|LOW] option.
That's nice to know WRT the overlay. I'll make that change.
I did send them the usual GPL email and have not heard back, nor have I received a response to an earlier contact of similar nature. It would save some time reverse engineering their more involved (and more inscrutable) changes to the attiny regulator driver for the panel backlight if they could be compelled via some other more effective channel.
<3 This is exactly what I was looking for! Thank you! <3
I will test this out and let you know if it works for me. I also need to port this to an android kernel.
@6by9 I have been preoccupied with work and so haven't drilled down on the BL regulator stuff; however, I did reach out again and am still receiving the silent treatment from EDATEC.
@xxxajk let me know how it goes - I hadn't tested just the panel init changes on their own based on the assumption that it would be fairly uneventful without the added backlight regulator driver.
@6by9 I have been preoccupied with work and so haven't drilled down on the BL regulator stuff; however, I did reach out again and am still receiving the silent treatment from EDATEC.
I can poke at them from my client's corporate email. They will want to be using this display, and would order 1k-2k of these per year... Think that'd get their attention?
@xxxajk that might attract a more favorable response. If you get kernel/module sources, do share here of course.
@RomanHargrave of course I will! I'm surprised that they don't just have it posted to their repos collection over here:
https://github.com/edatec
At least it seems they are trying, or tried at some point.
I'm an old skool kernel hacker from the 90's btw, seen this happen so many times. One of the worse ever thing I ran into was cdrom drives that had bad firmware, and the fix was to slow down from 2x speed to 1x speed for a few sectors until the laser got past the bad area. Thing is that it wouldn't really give you an honest error reply, and just spill trash.
@RomanHargrave @6by9 Sent out a request for the sources, from my client's corporate account, with explanation. Basically we wish to move to this display instead of the crappy plastic ones that are on hdmi and use usb hacks. Since we use Android, and not raspi os, we totally need the sources for a port. Let's see what happens...
Super. Yeah, I was pretty stoked to see these given the alternatives. Needless to say, I was quite disappointed at the total miss on software support...
Good news is that I got a good solid reply. They also some-how plan on an opensource release to rpi foundation mid January, however I'm not so sure they understand the submission process at all. I should have something soon as far as sources.
Tell EdaTec to email [email protected] for help (It's Ltd, not Foundation btw) if they are having problems submitting code to us. I can talk to the boss and get things moving.
