The latest BMW 3-Series and 4-Series have a segment LCD climate display.
Whereas the 8 Series GC, X5, X6 and X7 have a much nicer looking graphical TFT. (if you buy the "4 climate zones" option, otherwise they also have the segment LCD)
my project: (in fact 2 projects in 1)
1.) upgrade my climate controls segment LCD to the TFT
2.) use the display as a data display for oil temperature, turbo preasure, etc.
Reverse engeneer the LIN Bus communication between climate control ECU and climate control panel
Done! Fully decoded the protocol.
So I can run the control panel on my bench for further testing.
The protocol of the two panels are identical. In fact, I can even connect the X5 control panel with TFT display to my car and everything works. It just doesn't fit mechanically as the one from the BMW X Series is wider.
So the project will look like this:
My original control panel with no display connected.
ESP32 listening on the LIN Bus for the commands and driving the graphical TFT type display in "full OEM look".
Hidden touch button to switch the display between climate display and data display.
Reverse engeneering the TFT pinout.
Now I was able to make "screenshots" with my logic analyzer, 100% accurate and "pixel perfect".
driving the BMW TFT
Works! But ...
With an altered initialization sequence, I was able to display the image coming from a RA8875.
I don't know why it does not work if I init it with the original sequence.
Perhaps because I cannot make the RA8875 output exactly like the video controller used by BMW, for example only 1 clock cycle wide HSYNC impulse. RA8875's minimum HSYNC width is 8 pixels.
So I'm hoping someone with more experience with displays (and there are some of these people around here in this forum) can identify the controller used.
I had no luck searching on the net.
What I know:
manufacturer: should be Tianma (my guess, as the model number is looking like their other displays)
model number: TM022KDHP01-02
color depth: 16.7M
interface: 24 Bit parallel RGB
initialization via 9-bit SPI
connected to a Yamaha YGV642 video controller (feature sheet, no datasheet publicly available)
(all in HEX, [command] data ...)
 00  00  00  40 28 4C 02 02 11  06 01 05 00 55 00 00 00  1A 7A 00 A5 7A 00 AA 0A 01 0A 00 9A 0A  63 02 00  10  AC 5C 0F 03 04  A5
" A5" activates the display at the end, so looks like "DISPON".
But, as mentioned, when connected to my RA8875, I could not get a picture.
So I put " A5" at the beginning and sent the init sequence very slow, byte by byte and watched, what happens.
Commands ,  and  can be omitted.
With " A5" at the beginning, after " 40 28" the display goes on.
So, the minimum init sequence is:
 40 28
When I continue to send the next bytes, with the last data byte of the  command, 0x11, the screen goes black again.
Later in the sequence, the screen comes back on again, but only plain white and with kinda "shifted" pixels(?) and goes out again in the middle of the  sequence and stays black.
The complete, original init sequence works, if I change the last data byte (0x11) of the  part (which makes the display go dark) to an other value like 0x10 or 0x12!
(sure, in fact I'm sending 0x110 or 0x112 because it's 9 bit SPI without a D/C line and the first bit indicates if it's a command (bit 8=0) or data (bit 8=1).)
Even though I could get it up and running, I'd really like to have a datasheet to control it accurate and not only by guessing and "trial 'n' error".