>
> Just please make sure that one (user configurable/opt-in if necessary)
> policy from the beginning is to allow leasing out any output to
> applications, not just HMDs. My type of scientific/medical applications
> would benefit as soon as it has the option to get a drm lease for a given
>
On Mon, 08 May 2017 08:29:30 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
>
> > Thinking again, I believe we have to have a way to override
> > database entries somehow. If we ship catch-all entries for, say,
> > all Sony TVs, we are bound to get
Pekka Paalanen writes:
> I forget if I mentioned this to you personally yet:
> https://gist.github.com/ppaalanen/e0d2744ff71188e9a294726a37ca83c2
Thanks, that's a helpful bit of thinking. It looks like most of that is
still relevant, the only piece we'd swap out is how the
On Fri, 05 May 2017 07:25:14 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
>
> > I disagree on the details, more below.
>
> > Such a RandR request is something I would not like to have to replicate
> > on Wayland. The display server contains the
On Sat, 6 May 2017 13:34:44 +0200
Mario Kleiner wrote:
> Just please make sure that one (user configurable/opt-in if necessary)
> policy from the beginning is to allow leasing out any output to
> applications, not just HMDs. My type of scientific/medical
Mario Kleiner writes:
> Just please make sure that one (user configurable/opt-in if necessary)
> policy from the beginning is to allow leasing out any output to
> applications, not just HMDs.
That's entirely a given -- the leasing API is under the control of the
On 05/05/2017 04:25 PM, Keith Packard wrote:
Pekka Paalanen writes:
I disagree on the details, more below.
Such a RandR request is something I would not like to have to replicate
on Wayland. The display server contains the policy, it should not just
expose everything
Pekka Paalanen writes:
> I disagree on the details, more below.
> Such a RandR request is something I would not like to have to replicate
> on Wayland. The display server contains the policy, it should not just
> expose everything up for grabs. This is a fundamental
On Thu, 04 May 2017 11:02:44 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
>
> > That means you need an explicit key to denote HMDs. More below.
>
> I don't think so. Presumably the VR system will have a known list of
> HMDs it works with, and
Pekka Paalanen writes:
> Ooh, a much much larger scope than I assumed. Nice.
Well, it's more out of a sense of fear than future planning. If all we
ever use it for is as a list of monitors that the desktop should ignore,
that'd be fine.
> That means you need an explicit
On Wed, 03 May 2017 19:04:38 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
>
> > do you mean to list all kinds of display devices in the database? I was
> > assuming it would list only HMDs, so not in database would imply it's a
> > normal display
Pekka Paalanen writes:
> do you mean to list all kinds of display devices in the database? I was
> assuming it would list only HMDs, so not in database would imply it's a
> normal display and good for extending the desktop to.
I intended for it to be a general database to
On Tue, 02 May 2017 07:45:25 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
> > I presume that if "desktop" is set to "true", it implies that the HMD
> > is capable of showing a simple 2D canvas in stereo without any special
> > rendering and with
Pekka Paalanen writes:
> I was under the impression that if you have a VR application running on
> the HMD, it necessarily also implies that you have a VR compositor
> running, which means that there is always some process providing a valid
> image to the HMD. (At least in
On Fri, 28 Apr 2017 15:03:17 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
>
> > IMHO, if nothing is providing a picture intended for the HMD, the HMD
> > should be off. There is no use in showing an arbitrary image that does
> > not look right, is
Pekka Paalanen writes:
> IMHO, if nothing is providing a picture intended for the HMD, the HMD
> should be off. There is no use in showing an arbitrary image that does
> not look right, is there?
Well, if the HMD is being worn and the application crashes, then
what you want
Mario Kleiner writes:
> Great! Haven't looked at your patches yet, only at this thread and your
> blog, but this sounds all very promising.
I'll write up another blog post when I finish with the first round of
review. That should describe the kernel API at least. I
On 04/10/2017 08:11 PM, Keith Packard wrote:
Mario Kleiner writes:
as input from a highly interested future user of such api's:
Thanks much for taking a look at this.
My use cases run about 98% of the time in fullscreen
exclusive mode and want as little
Alex Deucher writes:
> I think there is a definite use case there.
I agree. What we're missing right now is someone interested in driving
an implementation of that use case to help define the right
interfaces. Lacking that, we're not likely to come up with a good
solution
On Tue, Apr 4, 2017 at 3:02 AM, Daniel Vetter wrote:
> On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote:
>> Daniel Vetter writes:
>>
>> > Also if this confuses VR, then another reason why we want to make leases
>> > invariant and only allow pure
Mario Kleiner writes:
> as input from a highly interested future user of such api's:
Thanks much for taking a look at this.
> My use cases run about 98% of the time in fullscreen
> exclusive mode and want as little interference from the windowing system
> /
On 04/04/2017 06:48 PM, Keith Packard wrote:
Daniel Vetter writes:
Yeah I think that's a pretty neat idea to reduce the lease complexity even
more. If the VR compositor is unhappy and wants a different mode, it can
simply nuke the lease and as for a new one. Forgot to say
On Sun, 09 Apr 2017 10:27:31 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
>
> > we need some kind of a database to recognize HMDs in any case, right?
> > It would be best if the database was shared, so that everyone could
> > recognize all HMDs,
Pekka Paalanen writes:
> we need some kind of a database to recognize HMDs in any case, right?
> It would be best if the database was shared, so that everyone could
> recognize all HMDs, at least as far as one can do that based on EDID.
Yeah, I think you've got some good
Michel Dänzer writes:
> When no such special client (Steam?) is running, the desktop environment
> will try to use the HMD anyway, right? So the expected use case would be
> for the user to start a special client first and only plug in the HMD
> afterwards? That seems a bit
On Thu, 06 Apr 2017 20:02:23 -0700
Keith Packard wrote:
> Michel Dänzer writes:
>
> > When no such special client (Steam?) is running, the desktop environment
> > will try to use the HMD anyway, right? So the expected use case would be
> > for the user to
On 02/04/17 07:58 AM, Keith Packard wrote:
>
> 2. Provide a way to hide some monitors from other clients using EDID
> manufacturer ids and product codes. Outputs with EDID properties
> matching the grab will report 'disconnected' to all clients other
> than the grabbing client. This
Daniel Vetter writes:
> Yeah I think that's a pretty neat idea to reduce the lease complexity even
> more. If the VR compositor is unhappy and wants a different mode, it can
> simply nuke the lease and as for a new one. Forgot to say that :-)
Not sure it changes the lease
Daniel Vetter writes:
> On that, I think we could just unconditionally hand leases all encoders.
> Encoders turned out to be a bit an uapi mistake.
Well, given the complexity of hardware these days, even crtcs would
probably best have been hidden...
> Neither setcrtc nor
Daniel Vetter writes:
> Also if this confuses VR, then another reason why we want to make leases
> invariant and only allow pure revoke, not changing the list.
I'm not sure why you want this to be asymmetrical, nor why you would
expect lessees to be any more competent at
Daniel Vetter writes:
> Hm, if you restrict getresources and getplanes, you'll get your leased
> objects query api. Iirc that part was missing in your kernel patch. And it
> gives you exaclty what you want: per-type list of object ids.
Hrm. I think that's one Dave didn't want
Daniel Vetter writes:
> The multi-seat thing sounds like vapourware, I think we should care about
> the vr use-case for now, and only that one.
Ok, I can live with that, even if I like the idea of a slightly more
general solution.
> For VR itself I'd go as far as saying that
On Tue, Apr 04, 2017 at 08:53:45AM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > The multi-seat thing sounds like vapourware, I think we should care about
> > the vr use-case for now, and only that one.
>
> Ok, I can live with that, even if I like the idea of a
On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > Also if this confuses VR, then another reason why we want to make leases
> > invariant and only allow pure revoke, not changing the list.
>
> I'm not sure why you want this to be
On Mon, Apr 03, 2017 at 09:41:34AM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > Hm, if you restrict getresources and getplanes, you'll get your leased
> > objects query api. Iirc that part was missing in your kernel patch. And it
> > gives you exaclty what you want:
On Sun, Apr 02, 2017 at 12:58:33PM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > On that, I think we could just unconditionally hand leases all encoders.
> > Encoders turned out to be a bit an uapi mistake.
>
> Well, given the complexity of hardware these days, even
On Sat, Apr 01, 2017 at 03:58:58PM -0700, "Keith Packard" wrote:
>
> As a part of the DRM leasing work, we need a way to have the X server
> create a lease and pass it back to an X client. Here's a proposal for
> the RandR specification changes necessary for that. The basic plan is
> pretty
As a part of the DRM leasing work, we need a way to have the X server
create a lease and pass it back to an X client. Here's a proposal for
the RandR specification changes necessary for that. The basic plan is
pretty simple:
1. Expose the ability to create a lease for a set of CRTCs and
38 matches
Mail list logo