[RFC] compositor-drm: name outputs according to connectors if EDID is unavailable

[Matt Hoosier]

On Thu, Aug 24, 2017 at 2:49 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> Hi,
>
> using connector name to describe the connected monitor doesn't sound
> right to me.

I didn't really like it either. Thanks for the suggestions below.

>
> If you actually need the connector name in clients then let's
> design an extension that gives you exactly that instead of twisting the
> poorly defined semantics of wl_output make/model even further. We have
> long email threads discussing the design of such things already:
> https://lists.freedesktop.org/archives/wayland-devel/2017-May/034083.html
> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034719.html
>
> However, I could imagine weston.ini options to set the make/model
> strings for a DRM connector. Like you say, EDID is not always
> available, but the system administrator or vendor may actually have the
> values and just needs a place to hard-code them. But, this raises a
> question, why not ship and inject an EDID blob through the kernel, so
> that you do not need to go fixing each and every compositor out there
> to pick up the hard-coded values?
>
> You could configure so much more in an EDID blob as well.
>
> From the Linux kernel-parameters.txt:
>
>         drm_kms_helper.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>]
>                         Broken monitors, graphic adapters, KVMs and EDIDless
>                         panels may send no or incorrect EDID data sets.
>                         This parameter allows to specify an EDID data sets
>                         in the /lib/firmware directory that are used instead.
>                         Generic built-in EDID data sets are used, if one of
>                         edid/1024x768.bin, edid/1280x1024.bin,
>                         edid/1680x1050.bin, or edid/1920x1080.bin is given
>                         and no file with the same name exists. Details and
>                         instructions how to build your own EDID data are
>                         available in Documentation/EDID/HOWTO.txt. An EDID
>                         data set will only be used for a particular connector,
>                         if its name and a colon are prepended to the EDID
>                         name. Each connector may use a unique EDID data
>                         set by separating the files with a comma.  An EDID
>                         data set with no connector name will be used for
>                         any connectors not explicitly specified.
>
> Is there a reason why you would not want to use this kernel DRM option?

No, the kernel support for manually supplying EDID information is much
better. I just didn't realize this KMS feature feature existed.

>
> What is the actual use case behind this patch? Why do you absolutely
> have to have a make/model?

The desire is to allow applications to distinguish which output to
select when making set_fullscreen() calls. I mentioned "embedded
devices", which probably gave the impression of something like a phone
or tablet. That's not quite my situation. The devices I'm thinking
about are multiheaded things built into the infrastructure of cars,
boats, etc, where multiple screens are common.

Thanks for the hint about drm_kms_helper.edid_firmware; I think that
does the job I need just fine.

-Matt