Giuseppe Bilotta <giuseppe.bilo...@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
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel