[PATCH] Add NonDesktop output property and behaviors.

[Giuseppe Bilotta]

Hello,

> NonDesktop devices are those to which the normal desktop environment
> should not be extended. Examples are Head-mounted displays and the
> Apple Touch Bar.

FWIW, some Razer laptop models have a touchpad that doubles as a
secondary display. Not sure if it's worth mentioning (it does predate
the Apple Touch Bar, has some very patchy support under Linux, none that
I know of under Xorg).

[snip]

> + • 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.

Would it make sense to have a distinct connection status instead? This
would make it possible to differentiate between actual disconnection and
“connected, but not really a standard output to be used for desktop”.
(Would it possible to differentiate otherwise?)

> +    “NonDesktop”		aka RR_PROPERTY_NON_DESKTOP
> +	Type:			INTEGER
> +	Format:			8
> +	Num items:		1
> +	Flags			Immutable

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.

> +	Range/List:		0-1

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

> +
> +	Indicates whether the the device attached to this output should not

(double the)               ^   ^

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

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

My understanding from the way this is presented is that the output
properties can be queried as with a traditional output, with the only
difference that it would claim to be disconnected. So this means in
particular that this output has a geometry, some size and offset: is the
offset always zero, even though this doesn't actually relate to the root
window? Or is the nondesktop output placed in reference to the root
window, but inaccessible? (e.g. with a gap between the “main” root
window and the nondesktop area of the framebufer)?

Could an X client (say, something like Gimp or Krita) actually draw over
it using the existing X protocol and extensions? Or should we assume
that clients should have specific support for this kind of hardware, and
therefore only access it via their own specific interfaces? In this
case, wouldn't it be better to just avoid listing the output in RANDR at
all?

A curious thing about these pieces of hardware is that in some sense
they fit relatively well with the “good old” X Screen concept: they
could be separate X Screens, with the additional caveat that the core
pointer wouldn't be able to move to them, but in the case of hardware
such as the TouchBar or Razer touchpad display, they would still allow
input via the built-in touchscreen interface).

Making them separate X Screens has a number of advantages:

* unless directed otherwise, the vast majority of clients only deal with
  the default X Screen (or the one they were started on);
* you are guaranteed to not get unexpected “bleeds” when a window gets
  repositioned, because the root windows are completely separate from
  each other;
* clients can still access the other X Screens if they really want to.

This would probably work reasonable well for the TouchThings (since they
probably need different drivers anyway), but I'm not sure how well it
fits with HMD (last time I tried getting separate X Screens with
separate outputs on the same GPU I had to give, it seemed an essentially
impossible task).

I'm probably overengineering this in my head, but I wonder if something
like this would be possible:

* during autoconfiguration, the X server generates one X Screen per
  available output (this is necessary because IIRC the protocol doesn't
  really contemplate the possibility to add X Screens dynamically; but
  maybe it's not actually necessary either);
* all outputs are assigned to the default X Screen on startup, but the
  RANDR protocol is extended to allow “moving” outputs between X
  Screens (X Screens with no assigned output might have e.g. a DUMMY
  connector or something like that, to avoid silly crashes in some
  clients);
* if a non-desktop device is attached (e.g. HMD), the corresponding
  output is redirected to the first available (i.e. no-output) X Screen.

Is this too crazy an idea?

Best regards,

Giuseppe Bilotta