Skip to content

kms/connector: Don't query the kernel twice when updating

On hotplug, the events we receive from the kernel are async, and connectors in the kernel come and go as they please. In practice, this means that calling drmModeGetConnector() twice more or less directly after each other, there is no guarantee that the latter call will return anything if the former did.

When updating the connector in response to hotplugs, we'd first update the list of existing connectors, and following that, query each and every one again for their current state, to update our internal representation; only the former handled drmModeGetConnector() returning NULL, meaning if unlucky, we'd end up doing a null pointer dereference when trying to update the state.

Handle this by querying the kernel for the current connector state only once per connector, updating the list of connectors and their corresponding state at the same time.

#0 meta_kms_connector_read_state at ../src/backends/native/meta-kms-connector.c:684
#1 meta_kms_connector_update_state at ../src/backends/native/meta-kms-connector.c:767
#2 meta_kms_impl_device_update_states at ../src/backends/native/meta-kms-impl-device.c:916
#3 meta_kms_device_update_states_in_impl at ../src/backends/native/meta-kms-device.c:267
#4 meta_kms_update_states_in_impl at ../src/backends/native/meta-kms.c:604
#5 update_states_in_impl at ../src/backends/native/meta-kms.c:620
#6 meta_kms_run_impl_task_sync at ../src/backends/native/meta-kms.c:435
#7 meta_kms_update_states_sync at ../src/backends/native/meta-kms.c:641
#8 handle_hotplug_event at ../src/backends/native/meta-kms.c:651
#9 on_udev_hotplug at ../src/backends/native/meta-kms.c:668

Marked as draft as I haven't tested actually hotplugging anything yet.

Merge request reports