On Tue, Jul 17, 2018 at 08:02:46AM -0600, Rob Herring wrote: > On Tue, Jul 17, 2018 at 1:47 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > > > On Tue, Jul 17, 2018 at 12:50 AM Rob Herring <robh@xxxxxxxxxx> wrote: > > > On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij <linus.walleij@xxxxxxxxxx> 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 Hz > > > > > > Don'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... A long time ago I've tried to sorted this problem by creating a virtual DRM encoder/connector that read the OF data to provide the EDID info. Linaro has adopted the patches for a while, but it has never made it into mainline because there was not enough interest for this "fake" encoder/connector. If interested in this solution I can try to revive the patches and make another attempt at upstreaming them https://git.linaro.org/landing-teams/working/arm/kernel-release.git/commit/?h=latest-armlt&id=9a93df172b2987c5a8e0efcefb2abdfebd1a3d68 https://git.linaro.org/landing-teams/working/arm/kernel-release.git/commit/?h=latest-armlt&id=15283f7be4b1e586702551e85b4caf06531ac2fc Best regards, Liviu > > > 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 -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
