On Tue, Jul 17, 2018 at 1:47 AM Linus Walleij linus.walleij@linaro.org wrote:
On Tue, Jul 17, 2018 at 12:50 AM Rob Herring robh@kernel.org wrote:
On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij linus.walleij@linaro.org wrote:
+Video Graphics Array
VGA is more a controller interface than a panel...
I don't know what else to call it though, other than formulating someting bureaucratic like "Video Graphics Array Display Resolutions"
Or should I use the abbreviation: "VGA Display Resolutions" rather?
The Wikipedia article "display resolution" https://en.wikipedia.org/wiki/Display_resolution just calls these three resolutions "VGA", "SVGA " and "XGA".
+static const struct drm_display_mode video_graphics_array_modes[] = {
{/** This is the most standardized "vanilla" VGA mode there is:* 640x480 @ 60 HzDon't we have standard VESA timings already defined as well as timings that can be calculated based on resolution and refresh rate (called CVT IIRC). Why duplicate here?
They are inside drivers/gpu/drm/drm_edid.c all in static const arrays and enumerated by the index in the DMT spec taken out of XFree86. (drm_dmt_modes[])
I don't know. It is quite encapsulated into that EDID driver and doesn't seem very reusable. To pick out a few from inside EDID seems pretty daunting. I'd like to hear what the DRM folks think about that.
Why don't you just define a 'vga-connector' node
Because this is not a VGA connector, it is just the VGA resolution. In other circumstances I do use it.
It's not a panel either. A connector is something with variable resolution. A panel is fixed resolution. Which do you want?
I think you most often have to use that connector with the dumb VGA DAC bridge though, as the VGA connector is analog and what comes out of a display controller is digital. So it needs to make some kind of sense here.
In a way (as we discussed before) the whole panel-simple.c thing is a bit bogus, as it is probably in most cases hiding a bridge or a dumb DAC or at least a VGA connector or similar that should've been properly modeled, but in this case I am more certain that it is actually the right choice.
I guess I could try to use the dumb VGA bridge and the VGA connector, and it indeed falls back to VGA resolutions if no DDC channel is available but if I go in and say there is a DAC bridge and VGA connector I am essentially lying.
and IIRC, you can just force the standard modes from userspace with DRM.
I guess you mean the kernel command line arguments, lest there will be no boot console.
Yes, the kernel command line is another way. But if you aren't using fbcon, then userspace is the way.
Apart from being a user experience horror story, that requires a VGA connector bridge, as per above. (It's the EDID code that does that command line parsing.) And that requires lying about having a VGA connector bridge.
Because you have to set the resolution on the kernel command line? I'm open to having a default resolution for the connector in DT.
But I can surely lie if everyone thinks that is the best idea :D
Maybe you need some flag to force a connection in the emulator and perhaps some fake EDID data to set a default mode.
This device tree I'm creating is for ARM RTSM which is a proprietary ARM tool.
Sudeep at ARM says it does not emulate any DAC bridge such as found in the Versatile Express machine family. It just expects to have the right resolution parameters written into the registers of the PL111, which in turn of course can only get it from a panel or bridge driver of some sort.
So putting *anything* in DT is a lie...
The way those emulators work (AFAICT) is that they simply monitor register writes to the resolutions parameters to scale the emulator display window and then they read out the RGB data into that window, pixel by pixel, from the indicated memory area. It works for them.
In QEMU, we had the same problem. It didn't support proper reporting of fake EDID on these platforms either, because of not properly modeling the hardware it was emulating, instead relying on the register reads as above. Since it is open source I could simply fix it: https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04651.html https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04652.html https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04653.html
Having a way to set the default display resolution in QEMU would be nice. I've hacked around that when using virgl.
After this, the QEMU for Versatile Express can properly use the bridge.
I do try to be gritty and thorough! :D
I don't really know what RTSM is and I can't run it myself. I just have to support it in the refactoring to use DRM for the ARM Versatile Express machines. I cannot change its source code.
There's also some other cases of "transparent" bridges which don't have any driver.
Yeah I think they mostly use panel-simple.c in the DRM case don't they? We come full circle.
LVDS does. VGA doesn't.
Rob