Re: [PATCH v2 3/3] drm: Call vga_switcheroo_process_delayed_switch() in drm_lastclose

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux