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

Wed Jul 18 13:21:46 UTC 2018

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

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!  /
  ---------------
    ¯\_(ツ)_/¯