[PATCH] Add NonDesktop output property and behaviors.

Fri Oct 20 18:35:50 UTC 2017

On 10/19/2017 10:52 AM, Keith Packard wrote:
> NonDesktop devices are those to which the normal desktop environment
> should not be extended. Examples are Head-mounted displays and the
> Apple Touch Bar.
> 
> How an output device is set to NonDesktop is not part of this
> proposal; it is expected that the underlying operating system will
> provide this information and have it reflected to X applications
> through this extension.
> 
> Signed-off-by: Keith Packard <keithp at keithp.com>

I think this makes sense. Comments below.

Reviewed-by: Aaron Plattner <aplattner at nvidia.com>

> ---
>   randrproto.txt | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
>   1 file changed, 81 insertions(+), 3 deletions(-)
> 
> diff --git a/randrproto.txt b/randrproto.txt
> index 7312e0b..e717a60 100644
> --- a/randrproto.txt
> +++ b/randrproto.txt
> @@ -186,14 +186,23 @@ from the CRTCs. The Monitor marked as Primary will be listed first.
>   
>   1.6. Introduction to version 1.6 of the extension
>   
> -Version 1.6 adds resource leasing.
> +Version 1.6 adds resource leasing and non desktop output management.
>   
> - • A 'Lease' is a collection of crtcs and outputs which are made
> + • A “Lease” is a collection of crtcs and outputs which are made
>      available to a client for direct access via kernel KMS and DRM
>      APIs. This is done by passing a suitable file descriptor back to
>      the client which has access to those resources. While leased, those
>      resources aren't used by the X server.
>   
> + • A “NonDesktop” output is a device which should not normally be
> +   considered as part of the desktop environment. Head-mounted
> +   displays and the Apple "Touch Bar" are examples of such
> +   devices. A desktop environment should be able to discover which
> +   outputs are connected to such devices and, by default, not present
> +   normal desktop applications on them. This is done by having
> +   RRGetOutputInfo report such devices as Disconnected while reporting
> +   all other information about the device correctly.

I don't think a separate NonDesktop connection state property is needed. 
I agree that you can infer that from the presence of an EDID and modes.

>   1.99 Acknowledgments
>   
>   Our thanks to the contributors to the design found on the xpert mailing
> @@ -764,6 +773,12 @@ dynamic changes in the display environment.
>   	monitor in some way; for fixed-pixel devices, this would generally
>   	indicate which modes match the resolution of the output device.
>   
> +	Changes in version 1.6 of the protocol:
> +
> +	When a “NonDesktop” device is connected, the 'connection'
> +	field will report Disconnected but the remaining fields will
> +	report information about the connected device.
> +
>   ┌───
>       RRListOutputProperties
>   	output:OUTPUT
> @@ -775,6 +790,12 @@ dynamic changes in the display environment.
>   	This request returns the atoms of properties currently defined on
>   	the output.
>   
> +	Changes in version 1.6 of the protocol:
> +
> +	When a “NonDesktop” device is connected, the property list
> +	will be correct for the device, even though RRGetOutputInfo
> +	reports the device as disconnected

Add a period at the end of this sentence (and a couple below), maybe?

> +
>   ┌───
>       RRQueryOutputProperty
>   	output: OUTPUT
> @@ -806,6 +827,12 @@ dynamic changes in the display environment.
>   	changed by clients. Immutable properties are interpreted by the X
>   	server.
>   
> +	Changes in version 1.6 of the protocol:
> +
> +	When a “NonDesktop” device is connected, the property information
> +	will be correct for the device, even though RRGetOutputInfo
> +	reports the device as disconnected
> +
>   ┌───
>       RRConfigureOutputProperty
>   	output: OUTPUT
> @@ -924,6 +951,12 @@ dynamic changes in the display environment.
>   	is True and the bytes-after is zero, the property is also deleted
>   	from the output, and a RROutputPropertyNotify event is generated.
>   
> +	Changes in version 1.6 of the protocol:
> +
> +	When a “NonDesktop” device is connected, the property value
> +	will be correct for the device, even though RRGetOutputInfo
> +	reports the device as disconnected
> +
>   ┌───
>       RRCreateMode
>   	window: WINDOW
> @@ -1816,6 +1849,12 @@ factors, such as re-cabling a monitor, etc.
>   	precise change can be detected by examining the new state of the
>   	system.
>   
> +	Changes in version 1.6 of the protocol:
> +
> +	When a “NonDesktop” device is connected, this event will be
> +	delivered when the connection status of the output changes,
> +	however the 'connection' value will be set to 'Disconnected'.
> +
>   ┌───
>       RROutputPropertyNotify:
>   	window: WINDOW			window requesting notification
> @@ -1955,6 +1994,13 @@ as long as the semantics are not altered.  Clients SHOULD fall back
>   gracefully to lower version functionality, though, if the driver
>   doesn't handle a mandatory property correctly.
>   
> +Changes in version 1.6 of the protocol:
> +
> +When a “NonDesktop” device is connected, the property information
> +will be correct for the device, even though RRGetOutputInfo
> +reports the device as disconnected. The “NonDesktop” property will be
> +set to 1 for such devices and not present on other devices.
> +
>   9.1 Known properties
>   
>       "Backlight"			aka RR_PROPERTY_BACKLIGHT
> @@ -2055,6 +2101,29 @@ doesn't handle a mandatory property correctly.
>   	output. Should include main EDID data and all extension
>   	blocks. Previously known as EdidData.
>   
> +    “NonDesktop”		aka RR_PROPERTY_NON_DESKTOP
> +	Type:			INTEGER
> +	Format:			8
> +	Num items:		1
> +	Flags			Immutable

 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.

> +	Range/List:		0-1

 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.

> +	Indicates whether the the device attached to this output should not
> +	be considered part of the normal desktop. When set to 0 or not
> +	present, the output should be presented as part of the
> +	desktop.
> +
> +	When set to 1, the output should not be presented as part of
> +	the desktop. To not present an output as part of the desktop,
> +	the normal desktop environment should not be shown on this
> +	output, nor should desktop applications be positioned on it.
> +
> +	When set to 1, RRGetOutputInfo will always report connection status
> +	Disconnected, but RROutputChangeNotify events will still be
> +	delivered when the connection status changes and all other
> +	information about the output and connected device will be
> +	reported correctly.
> +

 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.

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.

>       "SignalFormat"		aka RR_PROPERTY_SIGNAL_FORMAT
>   	Type:			ATOM
>   	Format:			32
> @@ -2245,6 +2314,13 @@ GUID				yes		not mandatory
>   Property			Immutable	Mandatory since
>   ────────			─────────	───────────────
>   TILE				yes		not mandatory
> +
> +9.8 Properties introduced with version 1.6 of the RandR extension
> +
> +Property			Immutable	Mandatory since
> +────────			─────────	───────────────
> +NonDesktop			yes		not mandatory
> +
>   			      ❧❧❧❧❧❧❧❧❧❧❧
>   
>   10. Extension Versioning
> @@ -2283,6 +2359,8 @@ list of what each version provided:
>   
>   	1.5: Added Monitors
>   
> +	1.6: Added Leases and NonDesktop output information.
> +
>   Compatibility between 0.0 and 1.0 was *NOT* preserved, and 0.0 clients
>   will fail against 1.0 servers. The wire encoding op-codes were
>   changed for GetScreenInfo to ensure this failure in a relatively
> @@ -2291,7 +2369,7 @@ graceful way. Version 1.1 servers and clients are cross compatible with
>   compatibility from this point. Version 1.2 offers an extended model of the
>   system with multiple output support. Version 1.3 adds a cheap version of
>   GetScreenResources to avoid expensive DDC operations, CRTC transformations,
> -panning, and the primary output concept. Versions 1.2 through 1.4 are
> +panning, and the primary output concept. Versions 1.2 through 1.6 are
>   backward-compatible with 1.1.
>   
>   			      ❧❧❧❧❧❧❧❧❧❧❧
> 