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

Daniel Stone daniel at fooishbar.org
Mon Jul 24 17:13:39 UTC 2017


Hi Pekka,
I've made a mental note to make as careful passes over the
documentation as the code before I send for review ...

On 19 July 2017 at 15:43, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 18 Jul 2017 14:14:25 +0100
> Daniel Stone <daniels at collabora.com> wrote:
>> +             /* Map from raw value to enum value */
>> +             for (j = 0; j < info->num_enum_values; j++) {
>> +                     if (!info->enum_values[j].valid)
>> +                             continue;
>> +                     if (info->enum_values[j].value != props->prop_values[i])
>> +                             continue;
>> +
>> +                     return j;
>> +             }
>> +
>> +             /* We don't have a mapping for this enum; return default. */
>> +             break;
>
> When we have an enum property whose value we cannot interpret, would
> this be a place for an assert(0) or an scream in the Weston log? It is
> either a bug in Weston, libdrm, or in the kernel, right?

Not really, it's just a new value. Consider, e.g., the 'scaling mode'
property: if someone wanted to add a new scaling mode, doing so would
instantly break Weston if it was started when that scaling mode is
set.

I'm not really sure if there's a better way to communicate that we've
got an enum we don't properly handle. I think the behaviour is OK for
now, but we can definitely revisit it if we start adding support for
more and varied plane types.

>> +/**
>> + * Cache DRM property values
>> + *
>> + * Update a per-object-type array of drm_property_info structures, given the
>> + * current property values for a particular object.
>
> I think that should instead say:
>
> * Cache DRM property IDs
> *
> * Update a per-object array of drm_property_info structures, given the
> * DRM properties of the object.
>
> The original implementation I had actually cached the current values as
> well rather than only property IDs and enum value IDs, but we do not do
> that anymore.
>
>> + *
>> + * Call this every time an object newly appears (note that only connectors
>> + * can be hotplugged), the first time it is seen, or when its status changes
>> + * in a way which invalidates the potential property values (currently, the
>> + * only case for this is connector hotplug).
>
> 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.

>> +                     drmModeFreeProperty(prop);
>> +                     continue;
>> +             }
>> +
>> +             if (!(prop->flags & DRM_MODE_PROP_ENUM)) {
>> +                     weston_log("DRM: expected property %s to be an enum,"
>> +                                " but it is not; ignoring\n", prop->name);
>> +                     drmModeFreeProperty(prop);
>> +                     info[j].prop_id = 0;
>> +                     continue;
>> +             }
>> +
>> +             for (k = 0; k < info[j].num_enum_values; k++) {
>> +                     int l;
>> +
>> +                     if (info[j].enum_values[k].valid)
>
> This should never be true, should it?
> If it was, it would seem odd to skip updating it, when we happily
> update everything else.

As above, it'll be true when running on, e.g., hotplug.

Cheers,
Daniel


More information about the wayland-devel mailing list