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 <[email protected]>
I think this makes sense. Comments below.
Reviewed-by: Aaron Plattner <[email protected]>
---
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.
❧❧❧❧❧❧❧❧❧❧❧
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
