On Mon, Oct 05, 2026 at 10:54:41AM +0200, Neil Armstrong wrote: > On 10/5/26 04:22, Dmitry Baryshkov wrote: > > 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). > > I mean we could imagine combine any number of panels to form a combined > display, > 2 or 4 DSI links would be handled the same.
I was thinking about 2 combined display example. In this case you can't figure it out in software without extra hint. > > > > > 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. > > The regulators would be in the panel nodes, for the associated peripherals > like sensors & cameras they are not physically tied to the display so > it's only software plumbing. regulators yes, they are described. Think about the 2 XR units being driven by the same "base". I think, you would at least need to link the cameras to the enclosure. Otherwise you will have a 2x number of cameras and no idea which of the enclosures they belong to. -- With best wishes Dmitry
