mirror of
https://github.com/hyprwm/wlroots-hyprland.git
synced 2024-11-25 22:25:58 +01:00
cc8bc0db20
This is the cause of the spurious "drmHandleEvent failed" messages at exit. restore_drm_outputs calls handle_drm_event in a loop without checking whether the FD is readable, so drmHandleEvent ends up with a short read (0 bytes) and returns an error. The loop's goal is to wait for all queued page-flip events to complete, to allow drmModeSetCrtc calls to succeed without EBUSY. The drmModeSetCrtc calls are supposed to restore whatever KMS state we were started with. But it's not clear from my PoV that restoring the KMS state on exit is desirable. KMS clients are supposed to save and restore the (full) KMS state on VT switch, but not on exit. Leaving our KMS state on exit avoids unnecessary modesets and allows flicker-free transitions between clients. See [1] for more details, and note that with Pekka we've concluded that a new flag to reset some KMS props to their default value on compositor start-up is the best way forward. As a side note, Weston doesn't restore the CRTC by does disable the cursor plane on exit (see drm_output_deinit_planes, I still think disabling the cursor plane shouldn't be necessary on exit). Additionally, restore_drm_outputs only a subset of the KMS state. Gamma and other atomic properties aren't accounted for. If the previous KMS client had some outputs disabled, restore_drm_outputs would restore a garbage mode. [1]: https://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html |
||
|---|---|---|
| .. | ||
| backend | ||
| render | ||
| types | ||
| util | ||
| wlr | ||
| xcursor | ||
| xwayland | ||
| meson.build | ||