diff options
| author | Daniel Vetter <daniel.vetter@ffwll.ch> | 2013-08-08 15:41:14 +0200 |
|---|---|---|
| committer | Dave Airlie <airlied@redhat.com> | 2013-08-19 14:28:07 +1000 |
| commit | 0faa4a877765a4855dd570d6d391f77c5c37abc3 (patch) | |
| tree | 2d76482b7f491d65e4a6950c354ad0b598e0f61d /drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | |
| parent | b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 (diff) | |
drm/vmwgfx: remove ->firstopen callback
So if we survey kms drivers there's a bunch of things they commonly do
in ->lastclose
- delayed processing of vga switcheroo requests (i915, nouveau,
radeon)
- force-restoring the fbcon (most)
- resetting a bunch properties to make fbcon work better (omap)
- disabling all outputs (vmwgfx)
In short besides the semantically important vga switcheroo stuff they
all try very hard to keep fbcon working in case X dies.
But none of them try to not do this at driver unload time safe for
vmwgfx, and digging through logs I couldn't find any reason for why
vmwgfx is special.
Since ->firstopen has lots of potential for abuse with kms drivers
(like delaying driver setup to pamper over races in the load sequence)
it's imo very much worth it to remove this logic so that we can
stop using the ->firstopen callback for kms drivers.
Also module unloading is rather a debug feature and developers should
know how to restore the display to a sane configuration.
Cc: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'drivers/gpu/drm/vmwgfx/vmwgfx_drv.h')
| -rw-r--r-- | drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h index 13aeda71280..150ec64af61 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -324,7 +324,6 @@ struct vmw_private { */ bool stealth; - bool is_opened; bool enable_fb; /** |