[PATCH] Add NonDesktop output property and behaviors.

[Keith Packard]

Giuseppe Bilotta <giuseppe.bilotta at gmail.com> writes:

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

Thanks for another example. Is this display driven by the same hardware
as the main display?

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

Yes, we could, but the goal is to remain backward compatible with the
existing protocol, and adding a new value here wouldn't meet that
requirement. If the RROutputChangeNotify event wasn't already 32 bytes
long, we could have added a new field there and reported its presence
with an updated version number. Alas.

The obvious alternative would be to report the connected status in a new
output property. I think the presence of all of the other data on the
disconnected output (in particular, a list of modes), along with the
non-desktop property, should be sufficient to know that it is connected?

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

The current server architecture doesn't provide a mechanism for the user
to override driver-provided values, which pushes against this reasonable
request. It is a policy of sorts, and it's nice to be able to fix things
in user space where necessary. How would you reset it back to 'whatever
the driver thinks' though? Allow it to be set to some other value?

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

We can certainly add more information in additional properties. You do
have access to the EDID data, of course, so you can make choices based
on that. I want to leave the non-desktop property itself a simple
boolean and consider adding more information when we find additional
uses.

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

Well, 'connection' status is entirely informative. X applications need
not respect that and can do modesetting even when the output says it's
disconnected. That means that all of the regular X operations are
available. If you wanted to make it part of the regular X desktop, you
would just set a normal mode and it would appear as a normal part of the
desktop.

If you wanted to 'hide' it from other X applications, you would create a
Monitor that covered the geometry of another active output and assign
that to both the other output and the one to be hidden so that the
geometry of the hidden output was not included in the overall Monitor
geometry visible to applications.

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

It's an entirely normal output -- the position information would reflect
which portion of the root window was being presented in the 'hidden'
output.

> Could an X client (say, something like Gimp or Krita) actually draw over
> it using the existing X protocol and extensions?

Of course; to the core protocol, it's just more root window
space. However, the window manager will generally confine application
windows to the usable desktop area, so application windows *shouldn't*
ever appear in the hidden space.

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

We need to be able to discover these outputs in applications, and the X
server has special permissions from the kernel to enumerate them. So,
there isn't any other API available to us.

> Making them separate X Screens has a number of advantages:

Yes, except that we don't have good support for multiple screens on one
video card. Plus, X really (seriously, really) doesn't support creating
screens on the fly. Adding that ability would be a major piece of
surgery to the X server, along with breaking essentially all existing
clients which have no way to discover the new screen after connection.

As nice as this might be, it's not practical.

> * during autoconfiguration, the X server generates one X Screen per
>   available output

We have outputs that appear *after* the server starts -- MST makes
that fairly common.

> Is this too crazy an idea?

Not at all, it just isn't practical given the assumptions built into the
entire X ecosystem.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20171019/23b4bfd0/attachment-0001.sig>