On Thu, Oct 08, 2026 at 10:27:05AM +0200, Neil Armstrong wrote: > On 10/5/26 13:15, Dmitry Baryshkov wrote: > > 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. > > > > This is highly improbable, and I don't think it's the priority right now > anyway.
Yes. But if we are trying to define the ABI (and DT is an ABI). I'm using this usecase as an example of what needs to be defined as a part of the enclosure. Otherwise the case becomes a bit strange: we are defining XR enclosure, but only for the sake of defining that there are two panels and one of them is the left one. From my point of view, if we are defining the enclosure, it should be a (more or less) complete definition. If we say that we know all the details for now (because the whole system is the XR headset), then we also don't seem to require defining the panels setup. Having that in mind, I'd still ask you to try the following experiment: Add two separate panels, each describing one eye. Add msm-specific connector driver, proxying both panels. If possible proxy bridges instead of panels. The primary goal would be to handle get_modes() in a consistent way. I still suggest using a DRM_MODE_FLAG_3D_foo to describe the mode. Maybe we need to a new 3D_XR flag for the cases where the panels don't provide an L-R picture without significant additional processing on the host side. I'd still suggest having a single-eye resolution mode too, just to let non-XR compositors to display _something_ on the screen (even if it will be mostly unusable). Use this connector instead of drm_bridge_connector. This should let MSM DSI driver to clearly use the dimensions of the panel for DSC calculation instead of depending on extra flags to derive them from the CRTC mode. One of the ideas that was briefly discussed during LPC would be to define ROI for the connector and use two connectors for a single CRTC (each specifying its own region to be displayed). I think, this might clean up a lot of the hacky code. For example, each of the connectors would have its own backlight, each of them will have its own mode and its own bridge chain. The major drawback is that from the userspace point of view both connectors are independent. It would be a big question, how the kernel should behave if the userspace would try lighting up only a single connector out of two. -- With best wishes Dmitry
