[xwl] Generic X selections translation mechanism with Clipboard support
ClosedPublic

Authored by romangg on Aug 24 2018, 7:34 PM.

Details

Summary

In this patch an infrastructure is created to represent generic X selections
in a Wayland session and use them for data transfers between Xwayland windows
and Wayland native clients.

The central manager is the DataBridge class, in which Selection objects can be
created. This is hard-coded and such a Selection object persists until the end
of the session, so no arbitrary selections can be created on the fly. For now
the X Clipboard selection is supported, whose corresponding mechanism in the
Wayland protocol is just called Selection.

A Selection object listens for selection owner changes on the X side and for
similar events into the Wayland server interfaces. If a data provider is
available a selection source object is created by the Selection object. In case
data is requested on the other side, a data transfer is initialized by creating
a Transfer object. A Selection keeps track of all transfers and makes sure that
they are destroyed when they are finished or in case they idle because of
misbehaving clients.

The Clipboard class translates the X Clipboard via a proxy window. Selection
changes on the Wayland side are listened to through a new signal on the active
KWayland seat interface.

The previously used X clipboard syncer helper is disabled. The clipboard sync
autotest is changed to the new mechanism.

BUG: 394765
BUG: 395313

Test Plan

Manually and clipboard sync autotest.

Diff Detail

Branch
0clipboardXwl
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 2710
Build 2728: arc lint + arc unit
romangg requested review of this revision.Aug 24 2018, 7:34 PM
romangg created this revision.
romangg set the repository for this revision to R108 KWin.Aug 24 2018, 7:35 PM
romangg added a project: KWin.
Restricted Application added a subscriber: kwin. · View Herald TranscriptAug 24 2018, 7:35 PM

Just wondering: why did you integrate directly into KWin, instead of adding this to the existing helper process? My motivation to use a dedicated process was to ensure that KWin cannot be attacked through the X clipboard (the data is hold by the helper process, not by KWin). If you think having it in KWin is better I suggest a follow up change to move the normal clipboard functionality also into the xwl directory.

Just wondering: why did you integrate directly into KWin, instead of adding this to the existing helper process? My motivation to use a dedicated process was to ensure that KWin cannot be attacked through the X clipboard (the data is hold by the helper process, not by KWin).

The patch is a preparation step for a not yet uploaded follow-up patch to allow Xwayland DND ( T4611 ). For that I orientated myself on the implementation / WIP-patches of Weston and wlroots, that both have X Selections translation inside the compositor process. Xwayland DND is difficult already and the other projects don't have full support for it yet, so putting the generic X selections support out-of-process was just another complication I wanted to avoid for now. I personally also don't see a particular attack vector when having it in the compositor process. X clients and KWin communicate through the X protocol when exchanging X selections like they always do in a Wayland session with running Xwayland and data received is interpreted as raw bytes and only forwarded to clients on the Wayland side. If there is benefit to having it out-of-process, then I would reassess this in the future, maybe then combined with a move to put all X11 interfacing out of process in a Wayland session. For now I opt for not reusing the helper process in order to reduce the overall complexity and have as a starting point a mechanism akin to other compositor projects.

If you think having it in KWin is better I suggest a follow up change to move the normal clipboard functionality also into the xwl directory.

Do you mean the X clipboard sync heper itself? It gets removed in follow-up patch D15063.

romangg planned changes to this revision.Aug 27 2018, 10:18 AM

There is a small bug when the acitve window gets changed with a Wayland native selection: The Wayland source gets deleted on the later Xfixes notify and the selection request by the clients are not answered. Will update the diff with a fix.

romangg updated this revision to Diff 40510.Aug 27 2018, 1:29 PM
  • Ignore Xfixes notify when we disown a selection
romangg updated this revision to Diff 41388.Sep 11 2018, 10:48 AM

Rebase on master.

romangg updated this revision to Diff 42010.Sep 20 2018, 9:10 PM

Rebase on master.

zzag added a subscriber: zzag.Oct 22 2018, 5:24 PM
zzag added inline comments.
xwl/databridge.cpp
96–102

The lambda is superfluous.

xwl/selection.cpp
133

Is compiler happy about this?

235

Can't we do qobject_cast<Client *>(workspace()->activeClient()) == nullptr?

xwl/selection.h
81

Why explicit?

zzag added inline comments.Oct 22 2018, 6:59 PM
xwl/selection_source.h
34–35

Please follow coding style.

53

The filename is selection_source.h, so it makes sense to use the full name (SelectionSource).

136

Could you please explain why you use QVector<QString> instead of QStringList?

romangg updated this revision to Diff 48520.Jan 2 2019, 11:34 AM

Rebase on master.

romangg updated this revision to Diff 48522.Jan 2 2019, 11:59 AM
romangg marked 2 inline comments as done.
  • Handle review comments
romangg added inline comments.Jan 2 2019, 11:59 AM
xwl/databridge.cpp
96–102

See D15627

xwl/selection.cpp
133

Spills out warnings. It's similar to how Weston and wlroots does it though, so I don't want to increase difference to them here in this first version. Let's revisit it later though.

Or do you have directly a simple solution for it?

235

Have to include client.h for that. But let's do it.

xwl/selection_source.h
136

In general if possible QVector should be preferred over QList according to Qt doc.

zzag added inline comments.Jan 8 2019, 12:27 PM
xwl/clipboard.cpp
99

Please use single line comments.

xwl/clipboard.h
25–30

Please follow coding style.

36–40

/**

44

Why explicit?

xwl/databridge.cpp
96–102

What exactly is the issue?

xwl/databridge.h
58

Please follow coding style.

60

Missing explicit?

xwl/selection.cpp
40

Please compare against QLatin1String

99

Please use a single line comment.

131

Please don't use c-style casts.

133

Or do you have directly a simple solution for it?

http://doc.qt.io/qt-5/qtglobal.html#Q_FALLTHROUGH

309–311

Either add a TODO comment or delete it.

xwl/selection_source.h
120

/**

136

No short names

romangg edited the summary of this revision. (Show Details)Feb 19 2019, 8:21 AM
romangg edited the summary of this revision. (Show Details)
This revision was not accepted when it landed; it landed in state Needs Review.Feb 19 2019, 11:24 AM
This revision was automatically updated to reflect the committed changes.
romangg marked 16 inline comments as done.