On Tue, 25 Jul 2017 15:13:56 +0300 Pekka Paalanen <[email protected]> wrote:
> On Tue, 25 Jul 2017 11:50:58 +0100 > Daniel Stone <[email protected]> wrote: > > > Hi, > > > > On 25 July 2017 at 11:28, Pekka Paalanen <[email protected]> wrote: > > > On Mon, 24 Jul 2017 18:13:39 +0100 > > > Daniel Stone <[email protected]> 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
pgpiuZUwpW21Z.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
