>
> 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
> output
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 some assignment wrong for
> > someone who
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 bits actually
get to t
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 policy, it should not just
> > expose ev
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 applications
> would benefit as soon as
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
application which can lease any
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 up for grabs. This is
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 difference
> between X11 and
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 so it will probably have a list of EDID
>
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 key to denote HMDs. More
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 and good for extending the desktop to.
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 which we could add almo
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 the default video mode. That is, creating
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 end-user setups.)
Yes,
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 there?
>
> Well, if the HMD is being
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 is something that kee
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 think the X API
will be prett
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 interference from the windowing syst
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 our own. I think tha
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 revoke, not changing the list.
>>
>> I
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
> / desktop environment as possible, wi
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 that :-)
Not sure i
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, at least as far as one can do that based o
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 ideas here. Here are som
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 inconvenient.
I'd lov
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 start a special client first and only p
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 w
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 complexity, but it redu
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 atomic use it, the kern
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 dealing with hotplug tha
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 to restrict so that
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 probably our "creat
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 slightly more
> genera
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 asymmetrical, nor why yo
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: per-type list of
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 crtcs would
> pro
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 simple
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
OUTP
38 matches
Mail list logo
