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