On Sun, Oct 04, 2026 at 05:51:44PM +0200, Neil Armstrong wrote: > On 10/1/26 02:43, Dmitry Baryshkov wrote: > > 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. > > > > OK so let's see the problem in another angle, if we had 2 DS links 2 physical > controllers, 2 physically distinct panels but forms an unique display.
Imaging the case: through the time the backlight LEDs on the right eye age faster than the ones on the left eye, so we need to apply dynamic correction to the backlight, dynamically calibrating the coefficient to be applied to the LED brightness (or even worse, dynamically applieing the _curve_ to compensate for the brightness difference). Note, I don't have any information here, if such a difference can exist or if it can appear through the time, or if the xR DDICs can handle it on its own via a pre-programmed LUT, so you can totally say that the argument is moot and I won't even argue here. > > Describing it in separate distincts nodes is wrong since it doesn't reflect > that it's an unified display, so either we define : > - a "combined-display" bridge defined as: > - a separate top node in / like connectors with a graph from the DSI links > to each panel > - a DSI subnode with 2 panels as subnode, port graph from both dsi to both > sub-panels > - a "R63455" panel bindings with 2 subpanels as Linus shared in > https://lore.kernel.org/all/CAD++jLkyEPY5cFg_pHb71yG52iLwS9tQDpcHu=ttbknqmef...@mail.gmail.com/ > > I think it would be interesting to have the "combined-display", with a > connector-like node, > which will do all the split-dsi dual-panel logic for us and leave use > implementing simple panel > drivers. > > The outline would be: > > =====><======================================= > / { > > xr-display { > compatible = "combined-display"; > > ports { > port@0 { > combined_dsi0: endpoint { > remote-endpoint = <&dsi0_out>; > }; > }; > port@1 { > combined_dsi1: endpoint { > remote-endpoint = <&dsi1_out>; > }; > }; > port@2 { > combined_panel0: endpoint { > remote-endpoint = <&r63455_right_in>; > }; > }; > port@3 { > combined_panel1: endpoint { > remote-endpoint = <&r63455_left_in>; > }; > }; > }; > }; > }; This is an interesting approach and it would be a requirement, if we ever have a device with 4 DSI hosts which can driver two sets of XR panels (there would be no other way to understand, which pairs of panels are bundled together). I am not sure if it needs to be an OF graph device or if it can simply reference the DSI devices. Or if it can reference panels (which is not the same). Another question, do we need to list any other devices here? regulators? sensors? maybe proximity sensor? cameras? I'm thinking from the 4-host-2-xr point of view, because if we don't have 4 DSI hosts, we don't need to describe anything. We already know all the hardware properies and connections, the rest is really just a software plumbing. -- With best wishes Dmitry
