[PATCH] Add NonDesktop output property and behaviors.

[Giuseppe Bilotta]

On Fri, Oct 20, 2017 at 8:35 PM, Aaron Plattner <aplattner at nvidia.com> wrote:
>
> From Giuseppe:
>>
>> For the aforementioned touchpad/display, for example, one could envision
>> a “detached” mode where it acts like, say, the Apple Touch Bar, and an
>> “attached” mode where it's used like a standard display, for example to
>> show a zoomed area around the cursor. Achieving this would require this
>> properly to be mutable though.
>
> Giuseppe, I'm not sure I understand your suggestion about "attached" and
> "detached" modes here. I.e. what exactly would a driver do in response to a
> client writing this property? If you just want to switch between being part
> of the desktop and not, you can do that by attaching or detaching it from a
> crtc.

As I mentioned in my reply to Keith, the driver might change operating
mode. For example, something like the Razer touchpad display would
work in absolute mode (mapped to that specific output) in detached,
and in relative mode otherwise. I'm not sure if the display can be
turned off entirely, but if this is the case one effectively needs
some kind of tri-state (off, external, part of the default X Screen).

> From Giuseppe:
>>
>> It would be interesting to make this an enum allowing
>> different values, so that clients could differentiate between, say, an
>> HMD and a TouchBar. (Maybe instead of RR_PROPERTY_NON_DESKTOP make it a
>> RR_PROPERTY_OUTPUT_USAGE and have values 0 for Desktop, 1 for HMD, 2 for
>> TouchSomething (could be the Apple thing or the Razer thing)?
>
> I agree with Keith that this should remain a simple boolean since you can
> infer the type of the device from the EDID. Trying to specify an enum here
> just opens the door to being inconsistent, and the list always being out of
> date and too restrictive when new types of devices show up.

That's a pretty solid reason. The only downside is that getting the
EDID isn't trivial in scripts (but that can be solved extending the
xrandr tool, for example).

> From Giuseppe:
>>
>> I'm having troubles wrapping my mind around how exactly this works,
>> particularly in relation to the root window framebuffer, and about how
>> (or rather if) this can be achieved while still granting X clients
>> access to the output, even if just in an ‘as needed’ use case (i.e. not
>> as part of the “normal” operating mode).
>
>
> The motivation here is that a client would use this output through some
> other non-X API. Specifically Vulkan direct-to-display for virtual reality.
> So X wouldn't be configured to drive this output with a crtc. Instead, it
> would lease the output and a crtc to the client for its direct use.

Ah, I see. The WM/DE doesn't use the output because it's marked
disconnected, then a client that wants to use it uses the X API to get
the lease, but then does NOT use X to render on the leased output.
Yes, I agree that for this specific use case it works perfectly fine.

> You could use a similar model for a touch bar thing, where you either drive
> it directly using Vulkan, or tell X to display the X screen on it using
> RandR to set a mode on it. You don't need to be able to write the NonDesktop
> property for that.

The downside of using the touch bar or whatever by extending the X
screen to it is that this would cause the desktop to extend to it. I
was thinking about the case where you wouldn't want the desktop to
extend to it, but still use the X API to render to the output, hence
the multiple X Screen ideas. (For example, I'm not sure if this is
still the case, but some older versions of GIMP for example supported
multiple X Screens relatively smoothly, and you could e.g. have the
toolbars on an X Screen and the main window in another: adding support
for the touch bar would be much simpler than the lease way).

(Alternatively, one could lease that output and then maybe start an X
server just for it, but that seems a bit … overkill?)

-- 
Giuseppe "Oblomov" Bilotta