On Wayland we get the damage from the SurfaceInterface instead of
using a damage handle. This change ensures that the damage handle
interaction is only used on platform X11, while on Wayland we get
the damage from the SurfaceInterface directly.
Adds proper support for binding Wayland buffers to EGLImage.
The loading is split into a shm part and a Wayland buffer part,
so that both is supported.
Wayland buffer support is limited to format EGL_TEXTURE_RGB and
EGL_TEXTURE_RGBA. Other formats and multiple texture are not supported.
For Xwayland we need to have the Scene (and EglDisplay) created prior
to starting Xwayland and having X11. This requires creating the
Compositor before creating Workspace and starting Xwayland.
To support this the startup of Compositor is split into two parts:
prior and after Workspace creation.
The change might also be interesting for the kwin_x11 case as it could
result in the compositor being up in a quicker way.
On wayland OpenGL might get initialized before we have a connection
to the XServer and we might only have an xcb connection. So let's
guard the access.
In kwin_wayland the InputRedirectionCursor is created before the X11
connection is established. Because of that possible usage needs to
be guarded. This is only in cursorTracking so far. The parent class
exposes whether the cursor is tracked and the doStartCursorTracking
gets invoked again when the x11Connection becomes available.
The WaylandBackend emits a signal when the backend is ready. If a user
connects to it after it became ready, it will never get notified.
Therefore the WaylandBackend tracks also whether it is ready and
implements connectNotify to emit the signal again if a user connects and
the backend is already ready.
Users of the signal need to disconnect if they cannot handle it being
invoked multiple times. So far the only user does handle this properly.
This reorders the startup sequence quite a bit:
1. Create QAbstractEventDispatcher and install it on QCoreApplication
2. Create Application
3. Start Xwayland, use thread to get when its ready
4. Create xcb connection
5. perform startup
For using the wayland QPA it needs a patch in QtWayland which will be
part of Qt 5.4.2, otherwise it blocks.
EglWaylandBackend gains support for creating textures from a
BufferInterface. At the same time it loses the possibility to use
the Xcb shm extension to load the texture. That is Xwayland is
required.
In order to support it in a better way the WindowPixmap is passed
to the Texture for loading and updating. Which is then passed to the
backend specific implementation.
The concept of Buffers do not match WindowPixmap perfectly. With X11
we had a pixmap as long as the size was the sime, then it got discarded.
With Wayland we get a new Buffer whenever the window gets damaged.
Furthermore the Buffer might get destroyed any time (especially if the
client disconnects) or the data becomes invalid (it's a shm section after
all).
This adds some constraints on how the Buffer can be used. It's suggested
that the implementing sub-classes do a deep copy of the Buffer's data
when accessing it. For OpenGL that's rather obvious, for QPainter it
needs a dedicated QImage::copy.
WindowPixmap holds a pointer to the currently used Buffer, but doesn't
guarantee that it stays valid. Every time the window gets damaged, the
pointer needs to be updated.
The QPainter based scene is the first to implement support for Buffers:
on creation a deep copy is performed, on damage the changed parts are
painted into the deep copy.
Adds the SurfaceInterface identified by the surface id we get from
Xwayland. This allows in an easier way to map a Toplevel to a
Wayland surface and will also be useful for Wayland clients.
Only --xwayland stays supported. The option --displayfd and --rootless
are always set. Simplifies the feature matrix and the other X servers
don't make any sense now that we can start a proper rootless Xwayland.
The WaylandServer is at the moment only used to support starting an
Xwayland. It does not support Wayland clients yet, so don't get
excited.
For Xwayland it's using the trick of creating the Display before the
QApplication is created with manual event dispatching.
The --xwayland option starts a rootles Xwayland server. If a
rootless Xwayland server is used OperationModeXwayland is used
which is introduced with this change as well.
When XWayland associates a Wayland surface with an X window it
sends a WL_SURFACE_ID client message to the window manager.
KWin listens for this client message in Toplevel and provides it
as a member in Toplevel.
This requires KWin to actually start a Wayland server (and XWayland)
to make proper use of the information.
KWin::connection() uses the property to resolve the value instead of
using QX11Info. In practice this doesn't change anything at the moment,
but allows kwin_wayland to provide an xcb connection without depending
on QX11Info.
As we cannot make xcb_connection_t* available as a metatype, the
property's type is set to void*.
KWin::rootWindow() uses the property to resolve the value instead of
using QX11Info. In practice this doesn't change anything at the moment,
but allows kwin_wayland to provide a root window without depending on
QX11Info.
point of the calculation is to know how much
the window must be moved to de-compensate for
the deco but calculateGravitation() w/o a
deco (thus now w/o borderTop() etc.) is NOOP.
BUG: 344234
FIXED-IN: 5.2.2
point of the calculation is to know how much
the window must be moved to de-compensate for
the deco but calculateGravitation() w/o a
deco (thus now w/o borderTop() etc.) is NOOP.
BUG: 344234
X-KDE-ParentComponents is a list, so we have to check if this list
contains the plugin, not do a string comparison. It seems the
queryparser has become a bit stricter in this case. This query should be
fixed anyway, however, and it fixes a fairly important bug in the effect
system.
REVIEW:122821
X-KDE-ParentComponents is a list, so we have to check if this list
contains the plugin, not do a string comparison. It seems the
queryparser has become a bit stricter in this case. This query should be
fixed anyway, however, and it fixes a fairly important bug in the effect
system.
REVIEW:122821
