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

[Pekka Paalanen]

On Thu, 24 Aug 2017 09:34:33 -0500
Matt Hoosier <matt.hoosier at gmail.com> wrote:

> On Thu, Aug 24, 2017 at 2:49 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> >
> >         drm_kms_helper.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>]

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

Hi,

oh, nice.

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

It probably works when you are in control of the system design, but
strictly thinking it is still a bit of a hack.

The output identification issue is still completely unsolved. Desktop
systems will likely get something added to xdg_output. There have been
ideas about connector names, compositor-determined and user modifiable
names, persistent machine-readable standardizes names vs. custom
descriptive names, output types (monitor/projector/video wall/...),
properties like internal/external, etc. Or it could be even done the
opposite way: clients do not pick an output but say this window is a
presentation, put it somewhere suitable by default. There are many
different ways of thinking about it.

In IVI systems, *if* clients actually have a say in choosing their
output, one might want a specialized extension aimed specifically at
IVI use cases.

But yeah, what works for you and is future-proof enough, I can't say
you'd be doing it wrong. ;-)

OTOH, if the system has display ports where a user could plug any
device, relying on make/model will probably not be enough.


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/20170825/decb43f1/attachment.sig>