Introduce cloning and replication of output devices
Needs ReviewPublic

Authored by romangg on Aug 31 2019, 8:56 PM.

Details

Reviewers
None
Group Reviewers
KWin
Maniphest Tasks
T11222: Reimagine output cloning
Summary

The org_kde_kwin_outputdevice and respective org_kde_kwin_outputconfiguration
protocols will be extended by events to indicate the current replication and
clone status of an output device and a request to change the replication.

Here the notion of clones designate outputs sharing the same properties in an
immutable fahsion. This is mostly dependent on hardware characteristics when
outputs share a common CRTC. Changes to such an output will inevitably apply to
all its clones alike. The property is meant mainly to inform clients about
such a relation.

Replicas on the other side are arbitrary duplications of the image on an
output on other ones. This is an one-to-many relation allowing one output as
source of the image, also called the replication source, and arbitrary many
other outputs as replicas of the replicaiton source. It is expected that the
compositor has means to facilitate the replication in a sensible way, for
example by providing black bars to compensate for different aspect ratios.

Besides the protocol description changes and standard client API this patch
introduces on server side new functions and algorithms to make use of this
new interface in an efficient way:

  • Logical position and size are cached values of the current position and size of the output in compositor space respecting the replication status.
  • The cached clients-scale is the recommended scaling factor sent to clients on this output such that clients on the replication source and all replicas can provide buffers of optimal resolution. It is the ceiled maximum of all width and height quotients between replicas and replication source and the replication source scale itself. When an output is not a replica it always equals the ceiled scale value of the output.
  • The view-geometry provides a recommended geometry, which is cached as well, of positioning the actual viewable area on the output in pixel-coordinates. Using this geometry the aspect ratio of the final image on every replica will be the same one as the one of the replication source. The geometry returned is a rectangle positioned at the origin with size equaling output's mode size when the output is not a replica.
Test Plan

Tested with patches in KWin, libkscreen and KScreen. Autotests in the future.

Diff Detail

Repository
R127 KWayland
Branch
clone
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 15939
Build 15957: arc lint + arc unit
romangg created this revision.Aug 31 2019, 8:56 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptAug 31 2019, 8:56 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
romangg requested review of this revision.Aug 31 2019, 8:56 PM
zzag added a subscriber: zzag.Aug 31 2019, 9:11 PM
zzag added inline comments.
src/client/outputdevice.cpp
391

That's not safe if the raw string is dynamically allocated, use qstrlen instead.

zzag added inline comments.Aug 31 2019, 9:22 PM
src/client/outputdevice.cpp
391

Correction: that's not reliable way to check whether a C string is empty. You assume that all empty strings have the same address, which in some cases cannot be true, e.g. if the string is dynamically allocated.

romangg added inline comments.Aug 31 2019, 9:42 PM
src/client/outputdevice.cpp
391

Will change in next revision. It currently also does not yet check if the provided source uuid is not the one of the output-device itself.

romangg retitled this revision from [server] Introduce cloning and replication of output devices to Introduce cloning and replication of output devices.Aug 31 2019, 11:11 PM

If the output device - that is the replication source - goes away (hot plug) we need to clear the replicationSource field in the other output device. This is straight forward with a single connect but question is if afterwards the replicate event should be send to clients with null string (and a flag indicating that this source removal was due to a hotplug and was not set explicitly) or if they should just conclude this from the other output device going away. A similar case is the replication source being switched off while staying connected. Here the output device does not go away, but the wl_output normally should. Still it makes sense to not replicate an output which is switched off. So remove the replication source in the compositor and then signaled to the clients?

romangg updated this revision to Diff 65118.EditedSep 1 2019, 12:02 PM
  • Add trigger reason and direction enums
  • Disable replication on output device going away

I decided to go with the enums to make it explicit. Also I plan on using these in the future with events to signal the current dpms state of the output device without necessity to go through the dpms protocol and by that have separation of dpms and output device control. In this context also the additional trigger_direction enum will be useful.

Tested it by removing an output while being replication source or replica. Other monitor then switches back to showing independent image.

kpiwowarski added inline comments.
src/client/protocols/outputdevice.xml
318

It's not the same ;)

None        = 0,
Explicit    = 1 << 0,
Hotplug     = 1 << 1,
Dpms        = 1 << 2,
Enablement  = 1 << 3
330

down

romangg updated this revision to Diff 65263.Sep 2 2019, 5:44 PM
romangg marked 2 inline comments as done.