From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/6] drm: Let userspace check if driver supports modeset
Date: Wed, 15 Aug 2018 14:15:44 -0700 [thread overview]
Message-ID: <20180815211544.GC4070@intel.com> (raw)
In-Reply-To: <153185788508.10359.12007207256270098536@skylake-alporthouse-com>
On Tue, Jul 17, 2018 at 09:04:45PM +0100, Chris Wilson wrote:
> Quoting Souza, Jose (2018-07-17 18:02:17)
> > On Tue, 2018-07-17 at 08:28 +0100, Chris Wilson wrote:
> > > Quoting José Roberto de Souza (2018-07-16 23:38:36)
> > > > GPU accelerators usually don't have display block or the display
> > > > driver part can be disable when building driver(for servers it save
> > > > some resources) so it is important let userspace check this
> > > > capability too.
> > >
> > > We currently communicate that by having no modeset resources. What
> > > does
> > > another cap bit accomplish that we don't already know?
> >
> > This is a hackish way to check if driver support modeset,
> > drmModeGetResources()/drm_mode_getresources() can fail and return null
> > by other reasons and just check for the errno value can be misleading
> > too.
>
> Do not confuse libdrm with the ioctl. You do not need to allocate
> anything for such a check, and it is being used directly without
> allocations as a has-kms check.
>
> More to the point existing userspace determines modeset capability
> through the reported resources. Your changelog needs to explain why they
> are inadequate and how you plan to coordinate your fix with userspace.
> As it stands you are introducing uABI with no user...
I agree with Chris here. There is no indication on how this will
affect userspace here and this so far is just a uABI without user
that is a big blocker.
And I also got confused because that modeset capability check
got introduced in a block that is for
"/* Only some caps make sense with UMS/render-only drivers. */"
> -Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-08-15 21:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-16 22:38 [PATCH 1/6] drm: Let userspace check if driver supports modeset José Roberto de Souza
2018-07-16 22:38 ` [PATCH 2/6] drm/i915: Set PCH as NOP if display is disabled José Roberto de Souza
2018-07-16 22:38 ` [PATCH 3/6] drm/i915: Move out non-modeset calls from modeset init and cleanup José Roberto de Souza
2018-07-17 7:27 ` [Intel-gfx] " Chris Wilson
2018-07-16 22:38 ` [PATCH 4/6] drm/i915: Move drm_vblank_init() to i915_load_modeset_init() José Roberto de Souza
2018-07-16 22:38 ` [PATCH 5/6] drm/i915: Do not call modeset related functions when display is disabled José Roberto de Souza
2018-07-16 22:38 ` [PATCH 6/6] drm/i915: Remove redundante checks for num_pipes == 0 José Roberto de Souza
2018-07-17 7:28 ` [Intel-gfx] [PATCH 1/6] drm: Let userspace check if driver supports modeset Chris Wilson
2018-07-17 17:02 ` Souza, Jose
2018-07-17 20:04 ` Chris Wilson
2018-08-15 21:15 ` Rodrigo Vivi [this message]
2018-08-15 21:46 ` [Intel-gfx] " Souza, Jose
2018-07-17 8:05 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] " Patchwork
2018-07-17 8:08 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-07-17 8:27 ` ✗ Fi.CI.BAT: failure " Patchwork
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=20180815211544.GC4070@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=chris@chris-wilson.co.uk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.