Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 3/3] drm/i915: Deprecated UMS support
Date: Wed, 13 Nov 2013 21:01:48 +0200	[thread overview]
Message-ID: <20131113190148.GH7819@intel.com> (raw)
In-Reply-To: <1384158919-30592-4-git-send-email-daniel.vetter@ffwll.ch>

On Mon, Nov 11, 2013 at 09:35:19AM +0100, Daniel Vetter wrote:
> 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.
> 
> Cc: Dave Airlie <airlied@gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/i915/Kconfig | 24 +++++++++++++++++++-----
>  1 file changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index b0f61679c598..b0fa4c4055ee 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -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

Was there supposed to be some user for this config option?

> +	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".
> -- 
> 1.8.4.rc3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2013-11-13 19:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11  8:35 [PATCH 0/3] Deprecate legacy crap Daniel Vetter
2013-11-11  8:35 ` [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 Daniel Vetter
2013-11-13 18:59   ` Ville Syrjälä
2013-11-13 20:21     ` Daniel Vetter
2013-11-13 23:24       ` Ville Syrjälä
2013-11-14  0:43         ` Daniel Vetter
2013-11-11  8:35 ` [PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms Daniel Vetter
2013-11-13 19:00   ` Ville Syrjälä
2013-11-13 21:14   ` [PATCH] " Daniel Vetter
2013-11-13 23:20     ` Ville Syrjälä
2013-11-11  8:35 ` [PATCH 3/3] drm/i915: Deprecated UMS support Daniel Vetter
2013-11-13 19:01   ` Ville Syrjälä [this message]
2013-11-13 21:11   ` [PATCH] " Daniel Vetter
2013-11-13 23:18     ` Ville Syrjälä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131113190148.GH7819@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox