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? 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
