On 29.08.2018 13:00, Liviu Dudau wrote: > On Wed, Aug 29, 2018 at 12:23:18PM +0200, Andrzej Hajda wrote: >> On 29.08.2018 12:01, Liviu Dudau wrote: >>> On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote: >>>> On 28.08.2018 15:45, Linus Walleij wrote: >>>>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote: >>>>> >>>>>> On 24.08.2018 14:23, Linus Walleij wrote: >>>>>>> This adds bindings for a virtual display to be used with displays >>>>>>> inside entirely virtual environments which do not emulate things >>>>>>> like monitors but just need timing information to be supplied to >>>>>>> its display controller. >>>>>>> >>>>>>> This is inspired by earlier work by Liviu Dudau. >>>>>> If this is pure virtual then it should be connected to other pure >>>>>> virtual components. >>>>> OK it's a bit of half-half but outside of my grasp, I am just trying >>>>> to support legacy systems. >>>>> >>>>> The device tree is there: >>>>> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts >>>>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi >>>>> >>>>> The latter contains the CLCD which is the display driver. >>>>> >>>>> In RTSM, which is an ARM product I do not develop and >>>>> cannot make changes to, there is an emulated CLCD. So >>>>> that part appear as if it was real hardware. Like in QEMU. >>>>> >>>>> But the display does not have any emulation. The raw >>>>> output from the CLCD is latched out to the screen. >>>>> >>>>> I do not know exactly know how the RTSM emulator >>>>> actually works, but I suspect that the little graphic window >>>>> on the screeen adapts to what gets written into the >>>>> CLCD control registers, so anything goes, more or less. >>>>> >>>>> To satisfy the CLCD with some timings and resolution, >>>>> this bridge gives it that, from the device tree, in a way >>>>> that clearly conveys that "this is not a real thing". >>>>> >>>>> The old code uses DPI. This is not DPI, not even close >>>>> to it. It worked simply because all the DPI really does is >>>>> what this patch does: provide timings. >>>>> >>>>> By contrast on QEMU I have patches the emulator to >>>>> properly represent the I2C DDC link and provide EDID >>>>> so that is all fine. >>>>> >>>>> I cannot patch RTSM to emulate I2C and DDC. It's not >>>>> open source. But the device tree in the kernel supports >>>>> this "machine" and so, I have to maintain it when modernizng >>>>> the fbdev driver to a DRM driver. >>>>> >>>>> I'm sorry RTSM is half/half. Not my fault. I can't fix... >>>> I do not know the platform, so I I have dug little bit, but I wan't >>>> call it thorough research. Just please be kind if I wrote sth stupid. >>>> What I have found: >>>> 1. DTS shows CLCD is pl111. >>>> 2. pl111 documentation says it's output interface supports STN and TFT >>>> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with >>>> DPI. >>>> >>>> If it is correct, dpi panel seems to be OK. And I think it is less >>>> important how the emulator works, more important is that it should >>>> emulate pl111, including it's output interfaces. >>> Yeah, unfortunately that ship has sailed a long time ago. The emulator >>> people thought emulating the register interface is good enough and took >>> liberties on how the behaviour was "emulated". End result: output >>> interfaces are not the same. >> So what is wrong/missing with dpi panel? > Linus explained in the links he quoted below. I'll let him add more if > he has additional information. In links below Linus proposed VGA, for me it seems incorrect pl111, does not produce analog VGA signal. Why do you (or Linus) want to use it. It does not make sense. SVGA and XGA are worse, they do not identify video signal standard, they identify only resolution. My question still stands: what is wrong/missing with dpi panel? I did not analyze details, but pl111 output seems to be DPI compatible. Please note that DPI standard (unlike DSI) is a kind of post-implementation standard - it was created to describe existing display parallel interfaces, which are identified using different names: RGB, parallel, TFT(?), LCD, panel,... So even if documentation says nothing about DPI it does not mean it is not DPI 'compliant'. Usually most digital interfaces with 24-lines for RGB data, VSYNC, HSYNC, PCLK and DE signals can be treated as DPI interfaces. Regards Andrzej > > Best regards, > Liviu > >> Regards >> Andrzej >> >>> Best regards, >>> Liviu >>> >>>> Regards >>>> Andrzej >>>>>> And one more thing, you are defining virtual panel but you are using >>>>>> drm_bridge framework, why not drm_panel? >>>>> This was discussed before in the previous patch set: >>>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html >>>>> >>>>> Essentially, it's because the display driver is just connected >>>>> to "something" not a panel and a bridge is likely the best I >>>>> can come up with - a bridge over to a virtual display. >>>>> >>>>> A patch to add "VGA", "SGA" and "XGA" to the simple panels >>>>> was NACKed (sort of, politely): >>>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html >>>>> >>>>> Also it was noted that it would be nice to have something that >>>>> would make it easy to change resolutions on these virtual >>>>> display things. Voila. >>>> >>>>> Yours, >>>>> Linus Walleij >>>>> >>>>> _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
