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

[Pekka Paalanen]

On Wed, 23 Aug 2017 20:50:02 -0500
Matt Hoosier <matt.hoosier at gmail.com> wrote:

> On embedded systems, EDID is typically unavailble for connectors on buses
> such as LVDS or DSI. This change enhances the original opportunistic
> naming done in 2b2092adb499d8cdc10390cf19876706bcfe69cb to report the
> make and model of an output according to the KMS connector (e.g., "DSI-1")
> if no dynamic information about an attached monitor is available for
> the connector.
> ---
>  libweston/compositor-drm.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 

Hi,

using connector name to describe the connected monitor doesn't sound
right to me.

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?

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


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170824/ae1eb420/attachment.sig>