On Sun, Dec 17, 2023 at 10:33:24PM +0100, Javier Martinez Canillas wrote: > Conor Dooley <conor@xxxxxxxxxx> writes: > > Hello Connor, > > > On Sun, Dec 17, 2023 at 11:07:03AM +0100, Javier Martinez Canillas wrote: > > [...] > > >> +properties: > >> + compatible: > >> + enum: > >> + - solomon,ssd1331 > >> + > >> +required: > >> + - compatible > >> + - reg > >> + > >> +allOf: > >> + - $ref: solomon,ssd-common.yaml# > >> + > >> + - if: > >> + properties: > >> + compatible: > >> + contains: > >> + const: solomon,ssd1331 > >> + then: > >> + properties: > >> + width: > >> + default: 96 > >> + height: > >> + default: 64 > > > > Do you envisage a rake of devices that are going to end up in this > > binding? Otherwise, why not unconditionally set the constraints? > > > > Because these are only for the default width and height, there can be > panels using the same controller but that have a different resolution. > > For example, there are panels using the SSD1306 controller that have > 128x32 [0], 64x32 [1] or 128x64 [2] resolutions. This, as you know, does not matter here. > But answering your question, yes I think that more devices for this > SSD133x family are going to be added later. Looking at [3], there is > at least SSD1333 that has a different default resolutions (176x176). That's fair enough though. I'd probably err on the side of introducing this complexity when the other users actually show up though. > > I think that even the SSD135x family could be supported by the same > modsetting pipeline, but I need to get one to figure it out. > > [0]: https://es.aliexpress.com/item/1005003648174074.html > [1]: https://www.buydisplay.com/white-0-49-inch-oled-display-64x32-iic-i2c-ssd1306-connector-fpc > [2]: https://es.aliexpress.com/item/1005001582340858.html?gatewayAdapt=glo2esp > [3]: https://www.solomon-systech.com/product-search/?technology=oled-display > > > Cheers, > > Conor. > > -- > Best regards, > > Javier Martinez Canillas > Core Platforms > Red Hat >
Attachment:
signature.asc
Description: PGP signature
