Most paths that hold both the display_lock and the display_devices_init mutex acquire them in the order just mentioned. However, there are two cases where these are acquired in the opposite order, which with unfortunate thread interactions and timings can lead to a deadlock. Fix these cases to use the same order as the rest of the code.
---
The instance of this deadlock I am seeing happens when enabling the virtual desktop mode with the Wayland driver (with pristine master) with any program. It's a deadlock between two threads calling:
1. `get_display_depth` => first acquires `display_lock` (in `lock_display_devices`) then `display_devices_init` (in `adapter_get_current_settings)` 2. `desktop_update_display_devices` => `add_gpu` => first acquires `display_devices_init` then `display_lock`
The deadlock is not very easy to hit normally, but a sleep like in the attached patch below makes it 100% reproducible for me:
[add_gpu_sleep.patch](/uploads/c08632d7a9dec751840199bdb16fb9a8/add_gpu_sleep.patch)