Hi, Am Dienstag, 4. März 2025, 16:23:20 CET schrieb Rob Herring: > On Tue, Mar 04, 2025 at 06:15:28PM +0800, Liu Ying wrote: > > A DPI color encoder, as a simple display bridge, converts input DPI color > > coding to output DPI color coding, like Adafruit Kippah DPI hat[1] which > > converts input 18-bit pixel data to 24-bit pixel data(with 2 low padding > > bits in every color component though). Document the DPI color encoder. > > Why do we need a node for this? Isn't this just wired how it is wired > and there's nothing for s/w to see or do? I suppose if you are trying to > resolve the mode with 24-bit on one end and 18-bit on the other end, you > need to allow that and not require an exact match. You still might need > to figure out which pins the 18-bit data comes out on, but you have that > problem with an 18-bit panel too. IOW, how is this any different if you > have an 18-bit panel versus 24-bit panel? Especially panel-simple.c has a fixed configuration for each display, such as: > .bus_format = MEDIA_BUS_FMT_RGB666_1X18 How would you allow or even know it should be addressed as MEDIA_BUS_FMT_RGB888_1X24 instead? I see different ways: 1. Create a new display setting/compatible 2. Add an overwrite property to the displays 3. Use a (transparent) bridge (this series) Number 1 is IMHO out of question. I personally don't like number 2 as this feels like adding quirks to displays, which they don't have. Number 3 actually describe the hardware connection. The only impact for software is to know which bus format it should use. Best regards Alexander -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider http://www.tq-group.com/
