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