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. > The R63455 is designed for this exact use case and are only supposed > to be use in XR application in pair. yes, but no, but yes, but no. I mean, nothing prevents one from using this DDIC in some other usecase. > See it like a single physical panel with 2 controllers which > shouldn't be used separately. While technically a controller could > be used to driver single panel, it's likely impossible Synaptics > would sell this IC for non XR applications. I think, this was causing an issue with the DSC too. A normal bonded-DSI-panel-with-DSC and this-double-panel require different widths to be programmed. Having a panel report real resolution would drop that quirk from the DSI host driver. > We want the both panels to be seen at a single big panel because > physically the human eye will see it as a single display. That's the CRTC side. > 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. -- With best wishes Dmitry
