public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Keith Packard" <keithp@keithp.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-kernel@vger.kernel.org, Dave Airlie <airlied@redhat.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/6] drm: Allow render nodes to query display objects
Date: Thu, 12 Oct 2017 14:02:08 -0700	[thread overview]
Message-ID: <87o9pc5bcf.fsf@keithp.com> (raw)
In-Reply-To: <20171012184117.s6qrcpubd6wfm5wl@phenom.ffwll.local>

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

Daniel Vetter <daniel@ffwll.ch> writes:

> So given the huge possibilities of abuse, do we really, really need all
> this, and is there not any way to create a bit of protocol to pass the
> relevant data from X to clients? From your presentation is sounded like
> current xrandr is (almost) there ...

Yeah, it's the Vulkan EXT_acquire_xlib_display API which is using this
access to discover the set of resources available via the render fd in
preparation for accessing them over the lease fd once the lease has been
created.

I *think* I can get enough information to make a good guess as to what
kernel resources there are from the RandR info. I'll go give that a try
and see if I get stuck.

Thanks for the feedback; the fewer kernel API changes the better.

-- 
-keith

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2017-10-12 21:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-11  0:48 [PATCH 0/6] drm: Add drm mode object leases Keith Packard
2017-10-11  0:48 ` [PATCH 1/6] drm: Pass struct drm_file * to __drm_mode_object_find [v2] Keith Packard
2017-10-11  0:48 ` [PATCH 2/6] drm: Allow render nodes to query display objects Keith Packard
2017-10-12 18:41   ` Daniel Vetter
2017-10-12 19:45     ` Daniel Vetter
2017-10-12 21:04       ` Keith Packard
2017-10-12 21:02     ` Keith Packard [this message]
2017-10-11  0:48 ` [PATCH 3/6] drm: Add new LEASE debug level Keith Packard
2017-10-11  0:48 ` [PATCH 4/6] drm: Add drm_object lease infrastructure [v4] Keith Packard
2017-10-11  0:48 ` [PATCH 5/6] drm: Check mode object lease status in all master ioctl paths [v2] Keith Packard
2017-10-11  0:48 ` [PATCH 6/6] drm: Add four ioctls for managing drm mode object leases [v5] Keith Packard
  -- strict thread matches above, loose matches on Subject: below --
2017-10-05  6:13 [PATCH 0/6] drm: Add leases [v4] Keith Packard
2017-10-05  6:13 ` [PATCH 2/6] drm: Allow render nodes to query display objects Keith Packard
2017-07-05 22:24 [PATCH 0/6] drm: Add mode object leases [v3] Keith Packard
2017-07-05 22:24 ` [PATCH 2/6] drm: Allow render nodes to query display objects Keith Packard

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=87o9pc5bcf.fsf@keithp.com \
    --to=keithp@keithp.com \
    --cc=airlied@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.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