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.
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.
Seriously, no, it's a likely very very improbable situation and
we need to accept to ignore things that will never happen.
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.
This is purely software implementation.
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.
This is purely software implementation.
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.
Neil
