[PATCH] Add NonDesktop output property and behaviors.

[Giuseppe Bilotta]

On Fri, Oct 20, 2017 at 3:25 AM, Keith Packard <keithp at keithp.com> wrote:
> 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?

Nope, it's completely separate. I don't have the HW, so all I know I
gathered from these sources:

https://github.com/FxChiP/rzswitchblade
http://fxchip.net/RazerBlade/

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

I see. I don't suppose that making the new value correspond to pre-1.6
RR_UnknownConnection would help?
Older clients would still recognize it, but still not know what do
with it. (But I'm guessing recycling values this way wouldn't really
be very client friendly.)

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

That would work, although it's definitely more work on the client
side, rather than just checking a single field.

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

I was thinking along the lines of letting user change the value _when
possible_, e.g. when the driver itself might support multiple modes of
operation. There would need to be some kind of integration with the
input side of things though. Consider for example the aforementioned
Razer touchpad display: in “detached” mode the touchpad would work as
an absolute pointing device for its own display, in “attached” mode it
would work as a standard touchpad. Client setting the value would make
the driver switch both the nondesktop property _and_ the input device
M.O. —assuming that makes sense at all.

Another approach that might work would be for drivers that support
both M.O. to present two clone outputs instead of one, where one is
non-desktop and the other is desktop, and then runtime could switch
between them by turning them on and off, with the condition that
turning one on automatically turns the other off?

>> 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 probably a bit stuck in the C mindset that enums can work as
booleans as long as you have a single false state ;-) So checking if
the value is (present and) non-zero would act as a boolean, but the
same value could also carry the extra info. But I get the point.

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

[snip]

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

Well, that's my worry 8-) Even in normal conditions I can move windows
so they bleed out of the (visible) space. I don't see how this could
be prevented in this case either. Sure, maybe no window gets directly
mapped to this special output, but I don't think we can actually
prevent even just accidental leaking.

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

Well, there could be a completely new extensions ;-) but yeah, I get the point.

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

Yes, Dave was quite clear about that on IRC 8-)

So, my understanding is that there's two aspects in the difficulty of
allowing dynamic screen management: code-side, and protocol-side.

I think that protocol-side, the situation might not be “too” dramatic.
The main issue is that clients get the number of roots on connection,
but this isn't worse than any other root-related property. For
example, the server could still send information only about the
default (or user-defined) X Screen on connection, and make the dynamic
screens be instead advertized (and managed) through RANDR (2.0 or
whatever).

The matter, I would guess, is more on the actual server code side of
things. Assuming dynamic screen creation/destruction is completely out
of the question, it might still be possible to create a certain number
of (additional, potentially hidden) X Screens. So I guess the question
is whether or not this is doable with the current driver model, and if
the extra complexity (which would be in the possibility to move
outputs between them) is at “nonsensically hard to achieve for little
gain” level.

(I'm guessing the general idea here is that it migt not be worth it?)

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

I hadn't considered that, but I'm not sure it has a significant impact
for this particular usage. I mean, the initial “hidden” screens
creation might not even be related to the number of outputs at all,
just a given (maybe user-settable) number.

>> Is this too crazy an idea?
>
> Not at all, it just isn't practical given the assumptions built into the
> entire X ecosystem.

(I actually wish I had some free time to put my coding hands where my
mouth is 8-P).

-- 
Giuseppe "Oblomov" Bilotta