Hi Am 17.01.23 um 10:44 schrieb Lukas Wunner:
On Thu, Jan 12, 2023 at 09:11:56PM +0100, Thomas Zimmermann wrote:Several lastclose helpers call vga_switcheroo_process_delayed_switch(). It's better to call the helper from drm_lastclose() after the kernel client's screen has been restored. This way, all drivers can benefit without having to implement their own lastclose helper. For drivers without vga-switcheroo, vga_switcheroo_process_delayed_switch() does nothing.[...]--- a/drivers/gpu/drm/drm_file.c +++ b/drivers/gpu/drm/drm_file.c @@ -38,6 +38,7 @@ #include <linux/pci.h> #include <linux/poll.h> #include <linux/slab.h> +#include <linux/vga_switcheroo.h>#include <drm/drm_client.h>#include <drm/drm_drv.h> @@ -460,6 +461,8 @@ void drm_lastclose(struct drm_device * dev) drm_legacy_dev_reinit(dev);drm_client_dev_restore(dev);+ + vga_switcheroo_process_delayed_switch(); }Hm, this looks like a case of midlayer fallacy: https://blog.ffwll.ch/2016/12/midlayers-once-more-with-feeling.html It is a departure from the opt-in library approach we've had so far. For switcheroo-aware EDID retrieval, there's a drm_get_edid_switcheroo() helper. How about introducing a switcheroo-aware lastclose helper which drivers can reference?
Console emulation is a mess. I'm working on it, but it takes time. Therefore a nice solution is probably not possible ATM.
We could have something like drm_fb_helper_lastclose_switcheroo(), which does drm_fb_helper_lastclose() + vga_switcheroo_process_delayed_switch(). i915 and radeon could use that as-is. amdgpu and nouveau have already switched to generic fbdev emulation. We could use drm_fb_helper_lastclose_switcheroo() from the generic code as well, but it will still be somewhat midlayerish.
But with all that, it's probably better to not land patch 3 at all. The hook drm_driver.lastclose is just for the old fbdev emulation. For the new fbdev emulation, we have better data structures (see drm_client_dev).
The correct design would be to switch amdgpu and nouveau back to their own fbdev emulation and handle switcheroo there. But their old fbdev code needed an overhaul, so just reverting isn't an option.
Best regards Thomas
Thanks, Lukas
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
