[PATCH weston v11 03/13] compositor-drm: Add DRM property cache

[Pekka Paalanen]

On Tue, 25 Jul 2017 15:13:56 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 25 Jul 2017 11:50:58 +0100
> Daniel Stone <daniel at fooishbar.org> wrote:
> 
> > Hi,
> > 
> > On 25 July 2017 at 11:28, Pekka Paalanen <ppaalanen at gmail.com> wrote:  
> > > On Mon, 24 Jul 2017 18:13:39 +0100
> > > Daniel Stone <daniel at fooishbar.org> wrote:    
> > >> > I believe this should shorten to: "Call this for every DRM object
> > >> > individually once."
> > >> >
> > >> > The language about status changes is probably a remnant of the value
> > >> > caching days.    
> > >>
> > >> When a connector is hotplugged, that can invalidate the enum
> > >> properties, so we still need to re-scan.    
> > >
> > > Does that not mean that a new DRM connector object appears? Or that an
> > > existing DRM connector object magically becomes rewritten in which case
> > > what do we use for triggering the re-scan?
> > >
> > > Do we need to re-scan all DRM connector objects every time we get a
> > > hotplug event?
> > >
> > > I mean, now that you said that, and I have read the doc comment a dozen
> > > times more, I'm getting a feeling of what it's trying to say in a very
> > > very compressed form. Expand a bit, please. :-)    
> > 
> > Well, not every panel is identical. Some are going to have different
> > capabilities to others. None of these apply to EDID/DPMS, but here are
> > a few examples:
> > 
> > There are patches on dri-devel@ for HDCP support at the moment. On a
> > non-HDCP-capable sink, you might want to have a single 'unavailable'
> > enum available, but then when you hotplug to a HDCP-capable sink,
> > suddenly you have 'enabled' and 'disabled' enum.
> > 
> > TV outputs have a surplus of available connector properties, including
> > which connector type to use (e.g. component vs. S-Video), 'flicker
> > reduction' / filtering, overscan, etc.
> > 
> > For scaling, you can control a surprising amount through, e.g., HDMI
> > infoframes. Again, whether or not this is available - and what's
> > variable - depends on your sink. So just plugging in a different
> > device might give you different options for scaling.
> > 
> > Those are just the ones I could find with a quick scan, but they are
> > all examples of enum properties whose values differ depending on the
> > currently-connected device. Which is why we need to rescan on hotplug.  
> 
> Yes, loud and clear now, makes perfect sense. So on every hotplug
> event, one needs to re-scan at least the connectors whose connectivity
> status changed.

I was going to re-review the property cache patch, because I thought it
might be missing some clean-up when operating on an already populated
cache, but then realized that connector connection status change always
causes a property cache to be either built from scratch or released,
never updated. There's my confusion.

If we used it to update, info[i].enum_values would be leaked.


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/20170725/df11b79c/attachment.sig>