On Wed, Sep 30, 2026 at 09:18:55PM +0200, Neil Armstrong wrote: > On 9/30/26 21:04, Dmitry Baryshkov wrote: > > On Wed, Sep 30, 2026 at 06:43:47PM +0200, Neil Armstrong wrote: > > > On 9/30/26 09:44, Linus Walleij wrote: > > > > On Tue, Sep 29, 2026 at 3:35 PM Krzysztof Kozlowski <[email protected]> > > > > wrote: > > > > > > > > > This entire binding seems like stitching two devices together, which > > > > > might be fine (I don't even remember this stuff... two months old) or > > > > > might be artificial grouping of separate devices. > > > > > > > > I think that's a good point and fair pushback. > > > > > > > > Neil and Jun talk about it yesterday at XDC (1:15 into the stream): > > > > https://www.youtube.com/watch?v=6tNGW8PoSzw > > > > > > > > The current binding does not reflect the physical topology of the > > > > actual device, and the bindings need improvements. I have a feeling > > > > there is one display controller with two physical panels. > > > > > > No there's really 2 controller and 2 separate panels, but they are not > > > classic panel, they are a pair of panels+lens which are in front of > > > the eyes which forms a single "image" for the brain, so they are > > > technically a single display and requires to be hard synchronized. > > > > Yes. However this approach makes it impossible to share the code between > > the double-panel drivers and single-panel drivers. I think, that the > > panel driver should still reference a single glass+DDIC, while letting > > the DSI host driver to handle the bifurcation. > > Yes, and no, it must really be considered as a "single panel driven by 2 > identical controllers", > and even this is really purely software implementation issue.
[...] > > > Describing both panels into separate nodes would only be possible > > > if we described a "VR display complex" nodes linked to both panels > > > but this would probably be solved by actually describing the "display" > > > linked to a DDIC controller and is out of subject for this serie, > > > and can be added later when we properly define things. > > > > I like the VR complex idea. In the end, you have two modes which you > > most likely might want to support: > > - L+R, having double-width CRTC scanning over a double-width framebuffer > > - Mx2, having a single-width CRTC and a single-width framebuffer > > displaying the same picture to both eyes. I can imaging that knowing > > about L+R might be an explicit opt-in feature of the DRM interface. > > > > This makes no sense to support both modes, and this will never be used, > and anyway this is purely software implementation. > > We're defining bindings here, describing the real reality, not hypothetical > situation that will never happen. Let's ignore software issues. On the hardware side, you have two distinct DSI panels, each having its own set of controls, own DSI link and own backlight control. -- With best wishes Dmitry
