Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

> > 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 >

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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 > /

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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,

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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:

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

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