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. 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 > > > > > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯
