drm/i915: Deprecated UMS support

It's been 5 years since kms support was merged and roughly 4 years
since UMS support was ripped out from userspace drivers.

Thus far it's not been a big burden to keep the ums paths alive, and
we've made some good progress in better separating it from the kms
code by sprinkling DRIVER_MODESET checks all over the place.

But now that the drm demidlayering is within reach this changes. I
want to make the driver loading code more robust using devres.c and
other cool tricks. But that doesn't work with ums due to the
shadow-attach trick. Which means we either
a) need to split out a complete ums codebase like radeon has
b) kill it for good.

The 2nd option is obviously much less work than the first, so I think
it's time to test the waters and see how many people out there still
use ums.

I've decided that silently failing to initialize the driver (and not
e.g. failing to load the module) is the right thing. That way we
should only get reports from users that actually care about some ums
features (like accelerated gl or support for secondary outputs).
Everyone else will just fall back to the vesa X driver.

For developers there's a small info level dmesg output.

The plan is to drop this Kconfig option after 3.16 (so gives us 2 full
releases) and then start killing code for real 2-3 releases
afterwards. That should be more than enough time for users to pipe up.

Of course if anyone does we need to revisit this plan and maybe go
with option a) above.

Also enable the KMS support by default in Kconfig and polish the help
texts a bit.

v2: Add the missing hunk of actual code changes. Oops. (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is contained in:
Daniel Vetter 2013-11-13 22:11:25 +01:00
parent 3bb6ce6686
commit b30324adaf
2 changed files with 25 additions and 6 deletions

View File

@ -37,12 +37,11 @@ config DRM_I915
config DRM_I915_KMS
bool "Enable modesetting on intel by default"
depends on DRM_I915
default y
help
Choose this option if you want kernel modesetting enabled by default,
and you have a new enough userspace to support this. Running old
userspaces with this enabled will cause pain. Note that this causes
the driver to bind to PCI devices, which precludes loading things
like intelfb.
Choose this option if you want kernel modesetting enabled by default.
If in doubt, say "Y".
config DRM_I915_FBDEV
bool "Enable legacy fbdev support for the modesettting intel driver"
@ -57,9 +56,12 @@ config DRM_I915_FBDEV
support. Note that this support also provide the linux console
support on top of the intel modesetting driver.
If in doubt, say "Y".
config DRM_I915_PRELIMINARY_HW_SUPPORT
bool "Enable preliminary support for prerelease Intel hardware by default"
depends on DRM_I915
default n
help
Choose this option if you have prerelease Intel hardware and want the
i915 driver to support it by default. You can enable such support at
@ -67,3 +69,15 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
option changes the default for that module option.
If in doubt, say "N".
config DRM_I915_UMS
bool "Enable userspace modesetting on Intel hardware (DEPRECATED)"
depends on DRM_I915
default n
help
Choose this option if you still need userspace modesetting.
Userspace modesetting is deprecated for quite some time now, so
enable this only if you have ancient versions of the DDX drivers.
If in doubt, say "N".

View File

@ -975,8 +975,13 @@ static int __init i915_init(void)
driver.driver_features &= ~DRIVER_MODESET;
#endif
if (!(driver.driver_features & DRIVER_MODESET))
if (!(driver.driver_features & DRIVER_MODESET)) {
driver.get_vblank_timestamp = NULL;
#ifndef CONFIG_DRM_I915_UMS
/* Silently fail loading to not upset userspace. */
return 0;
#endif
}
return drm_pci_init(&driver, &i915_pci_driver);
}