[PATCH] drm/panel: simple: Support simple VGA panels

[Rob Herring]

On Tue, Jul 17, 2018 at 1:47 AM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> On Tue, Jul 17, 2018 at 12:50 AM Rob Herring <robh at kernel.org> wrote:
> > On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij <linus.walleij at 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 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