Follows a useful change added in the kwaylandScanner tool the
s_version becomes part of the Private class.
Also fixes the related generation in the tool.
* fix initializer type -- was hardcoded, seems like an oversight
* add semicolons after class declarations -- one less thing to fix in the
resulting code
REVIEW:125110
Uses QWidgets to render a very small UI.
* lists each Output
* for each output shows whether dpms is supported
* and which dpms mode it's in
* and provides a button to change the mode
Adding support for a org_kde_kwin_dpms interface. On server side
Dpms is mostly bound to the OutputInterface exposing just a very
small manager. Whether Dpms is supported and which mode is used is
tracked directly on the OutputInterface.
In the header for each request a method is created, with following
features:
* ignores requests working as destructor
* adjusts return type for requests containing newId
* adds QObject *parent = nullptr for requests containing newId
* adds the arguements
* turns arguments from wayland into Qt types
In the cpp the same logic is applied. Methods are not properly
implemented and won't compile in the case of returning.
* parses the protocol
* can derive file name to generate from protocol name
* detects which interface is a global and which one is referenced
* generates client code for global and for resource
* comes with a mapping.txt file to translate wl -> KWayland
The small tool added here allows to automate the process of generating
the boiler plate for an interface. Currently it's able to generate the
Client side code representing a wl_global.
The tool does not get installed, so run it from build directory:
Example usage:
./kwaylandScanner -c Foo -f foo -g wl_foo
This will generate a wrapper for the wl_foo interface in files:
foo.h and foo.cpp
The class is called KWayland::Client::Foo.
The tool will be extended. Following things are on the TODO list:
* parse xml to get the Wayland names
* add listener (if needed)
* generate code for Wayland interfaces representing Resources
* generate the Server boiler plate
CCMAIL: mart@kde.org
CCMAIL: sebas@kde.org
* Raises wl_seat supported version to 4 in both server and client
* Raises wl_keyboard supported version to 4 in wl_keyboard
* wl_pointer and wl_touch are still on version 3
* Raises minimum Wayland version to 1.6
a protocol to activate the blur behind windows and to
optionally set a sub region of the window where to apply
the blur to, in case the window is shaped
REVIEW:125015
This change addresses the sometimes cumbersome to use API of Registry.
So far to bind an interface one needed to connect to the signals when
setting up the registry. There was no other way to get the name and
version at a later point. This made it difficult to use one Registry
in different parts of an Wayland application.
This change adds a convenient:
struct AnnouncedInterface { quint32 name; quint32 version;};
AnnouncedInterface interface(Interface) const
QVector<AnnouncedInterface> interfaces(Interface) const
The first one is meant for interfaces like wl_shm which is normally only
announced once. The latter one is meant for interfaces like wl_output
for which normally multiple interfaces can get announced.
Those methods can be used without having to connect to the announced
spy.
REVIEW: 124734
The shadow protocol is inspired by the KWin's X11 protocol and the
DecorationShadow in KDecoration2.
A shadow is attached to a surface (after a commit on surface) and
consists of several image parts (represented through a buffer):
* top-left
* top
* top-right
* right
* bottom-right
* bottom
* bottom-left
* left
In addition there is an offset on each side.
For more information see also the X11 protocol described at [1].
Note: the protocol is currently missing documentation and changing
the shadow is not yet properly delegated to the server API.
[1] https://community.kde.org/KWin/Shadow
This interface allows a client to fake input events and the server
might use them. There is an authentication mechanismn in place which
requires the server to mark the client as authenticated in order for
any events to be emitted at all.
This interface is intended for use cases like kdeconnect which allows
to remote control a device.
The idle time interface is modelled for the use cases of the KIdleTime
framework to allow providing a Wayland specific implementation.
It supports registering idle timeouts which are triggered on server
side if there has not been any user activity on the seat for the
requested amount of time. Once user activity resumes a resume from idle
signal is emitted.
In additon there is the possibility to simulate user activity which
simulates the resume from idle.
Sending a new PlasmaWindow as an event is quite problematic. The main
problem here is that it sends an id of 0 and this doesn't make sense
when the interface gets bound and all existing windows are send to the
client.
This changes the interaction to have the client create the resource for
the PlasmaWindow instead of the server creating it. The server generates
"window ids" and sends those to the client. The client now binds a
PlasmaWindow with the "window id" in the normal way.
In case the server doesn't know the id any more, it directly sends an
unmapped and destroyes the newly created resource again. It is not a
protocol error as that can happen (common example: file open dialog of
Qt 5 applications on Xwayland).
on xwayland clients, send mouse press, move and release
corresponding to touchDown, move and release
this gives a very basic touchscreen support on
xwayland clients
reviewed-by: Martin Graesslin <mgraesslin@kde.org>
Server can set a themed icon name, client gets it directly turned into a
QIcon. That only works with QGuiApplications as can be seen in the
adjusted paneltest.
Sends an umap to the client and destroys the resource afterwards.
The PlasmaWindowInterface gets automatically destroyed once there
are no more resources bound to it.
Check whether the resource for the Keyboard/Pointer/TouchInterface
is still valid before trying to use it.
This was hitting crashes in wayland during the wl_foo_send_enter
calls.
The Qt surface extension is a small protocol to allow exchanging
additional data between QWindows and the compositor. What we are
currently only interested in is the possibility to close a surface
from the Compositor.
Protocol description is copied from QtWayland 5.4.2 branch.
Before emitting the new damage we need to restrict it to the geometry
of the surface. That's required by the documentation and at least
QtWayland/OpenGL emits non-sense damage events.
If a resource is null, because e.g. the surface got already destroyed,
wayland will create an error while marshalling arguments causing
the connected client to in worst case abort.
Apparently we need to add a small delay after starting weston otherwise
it fails to connect on the CI system.
Additionally we switch to using headless-backend.so which should also
make the setup more robust.
Running real world applications (Xwayland) showed that it doesn't like
at all that we do a dispatch when we are going to flush. This caused
in a very reliable manner a "Connection closed" error in XWayland, taking
down the client and in return the (xwayland-enabled) server.
BufferInterface used to have a SurfaceInterface as parent. This could
result in easily hitting the abort condition that the BufferInterface
was still referenced when it gets deleted by just having one other
user referencing the BufferInterface.
There is no need to have the BufferInterface deleted when the
SurfaceInterface to which it belongs gets deleted. The BufferInterface
will get deleted once it's completely unreferenced and also has a
destroy listener.
Basically just wraps the size of the attached buffer. Convenience to
not have to go down to the Buffer to read the size.
TODO: apply buffer scale and transform.
Uses eglQueryWaylandBufferWL (if available) to determine the size of the
buffer. In order to do so, the server library links against egl (1) and
one needs to register the EGLDisplay in Server::Display by the user of
the library. For this a new method Display::setEglDisplay is added.
1: not using epoxy as it doesn't wrap the Wayland interfaces yet.
This change demonstrates how one can install a custom event dispatcher
before creating the QGuiApplication and how to process Wayland events
using the event dispatcher to e.g. start an Xwayland server prior to
creating the application.
It also allows to use
--platform wayland
on the test application. The wayland QPA plugin will connect to the
KWayland server started prior to creating the application.
Please note that such a setup will freeze unless QtWayland has commit
1e32e71 [1].
[1] 1e32e71403
This allows to start the Wayland server before the QCoreApplication is
created with an eventDispatcher being installed through
QCoreApplication::setEventDispatcher.
Instead of performing dispatchEvents for a hard coded number of
expected events from Xwayland, we use select on the pipe to figure
out whether Xwayland has started writing the display number. As long
as select does not indicate that the pipe is ready we need to dispatch
further events.
Anologous to the implementation in Pointer:
* signal entered and left
* Surface *enteredSurface()
The passed in keys are not yet passed along and
currently ignored.
Now the code handles correctly the attaching of a null buffer
(emits a signal unmapped) and if a commit doesn't have a pending
buffer it won't be reset. Damage requests are ignored if no buffer
has been attached yet.
Properly reset focus when surfaces get added/removed. E.g. when
writing in Kate additional surfaces are created for which we do
not want to pass focus.
If one passes StartMode::ConnectClientsOnly the socket in
XDG_RUNTIME_DIR is not created and instead one can only connect to
this server using the Display::createClient method. A very nice
solution to just have a Server and one dedicated Client talk to each
other.
The selection is supposed to be sent to the DataDeviceInterface just
before getting keyboard focus. In order to do that the SeatInterface
keeps track of the DataDeviceInterface which is the current selection
and the DataDeviceInterface of the focused keyboard client.
SeatInterface friends DataDeviceManagerInterface so that the latter
can register each created DataDevice for the SeatInterface.
The button state is a seat-global state and not a per pointer state.
All pressed/released and axis events are moved to the SeatInterface
and just invoke the related method on the focused surface pointer.
Makes PointerInterface more like other Interface classes wrapping
wl_resource. The most important change is the handling of the
focused surface. This is now kept in the SeatInterface and can also
be set if there is no PointerInterface for the client yet.
The unit tests had to be adjusted and some are also disabled as the
button events are not yet moved into SeatInterface.
This method is supposed to return the PointerInterface for the current
focused surface. At the moment it just creates the one global
PointerInterface. The existing SeatInterface::pointer method got
removed as that is actually wrong usage.
There can only be one focused surface per Seat, thus the information
should be hold in the seat.
This only adjusts the API, the actual data is still hold in the
PointerInterface. This still needs adjustment.
The ClientConnection is managed by Display. Whenever one tries to
get a ClientConnection for a wl_client* and it doesn't exist yet a
new one will be created and a clientConnected signal will be emitted.
Also there is a clientDisconnected signal.
ClientConnection provides access to pid, uid and gid. The idea is
to extend it to provide access to all the resources created for the
client.
Required information is passed through the ctor of Private.
::create is still virtual as ShellSurfaceInterface is retrieving
client information. This can be fixed once we have a better wl_client
encapsulation class.
The Resource base class is supposed to be used by all interface
classes which get created for a wl_resource.
Most interface classes are adjusted, but there are some exceptions:
* BufferInterface: is different as the wl_resource is already created
* PointerInterface and KeyboardInterface: those two need changes, the
implementation differs from all other interface implementations.
Version and interface get passed to the ctor allowing Global::Private
to implement ::create instead of providing a pure virtual method.
Also the static bind method is added to the Global::Private which
delegates into a pure virtual method.
New base class KWayland::Server::Global which all Interface classes
for a wl_global inherit. Furthermore there is a shared base class
for all the Private classes of that type.
The BufferInterface used nested calls of wl_shm_buffer_begin_access
and allowed multiple different BufferInterfaces to be in a block
between wl_shm_buffer_begin_access and wl_shm_buffer_end_access.
But this is not allowed: nesting is only possible if it accesses
the same buffer!
This resulted in an abort when we accessed two BufferInterfaces
at the same time. The added test case aborts in the previous
version.
The fix now changes the semantic of the method. The BufferInterface
doesn't hold the QImage any more, but creates a new one every time
::data is invoked. The QImage is created with a custom cleanup
function which calls to wl_shm_buffer_end_access. It ensures that
we don't call into wl_shm_buffer_begin_access as long as there is
a valid QImage for any other BufferInterface still around and
instead returns a null QImage.
Thus a user of a BufferInterface::data should destroy the returned
QImage as soon as it's no longer needed or create a deep copy if
it needs to be kept around.
Counter part for the copyClient test app: the pasteClient test app
creates and maps a shell surface and waits for selection announce,
initiates the copy/paste mechanismn and prints out what got pasted.
After success it closes itself.
The test application copyClient creates a ShellSurface, maps it as
fullscreen, renders a green buffer and when it gets pointer focus it
sets "foo" in mimetype "text/plain" into the selection.
This test application "testRenderingServer" is able to start a
Wayland server and uses a QWidget to render the "scene". It manages
ShellSurfaces and renders them on the QWidget in a very static way.
Furthermore input events (key, pointer, wheel) are forwarded to the
top most Surface.
This test server is able to support kwin_wayland as a client, but
weston's test application in latest release fail due to missing
xdg_shell support.
Qt::MouseButton is mapped to the linux buttons. The mapping does
not match the mapping used in QtWayland module [1] as that seems
to be incorrect to me. E.g. Qt::BackButton is not mapped to BTN_BACK.
[1] qtwayland/src/client/qwaylandinputdevice.cpp
Proof-of-concept code illustrating how to start a Wayland server
before creating the QGuiApplication and also starting an Xwayland
server before creating the QGuiApplication. Thus the QGuiApplication
is able to connect to the Xwayland server started in the same
application.
Event dispatching in Display requires a QSocketNotifier which
requires the QCoreApplication to be created. This requirement renders
it impossible to create the server before the QCoreApplication is
created. But there are use cases which need this:
Let's assume we want to integrate a wayland server into an existing
X11 dependent application which uses QApplication and enforces the
xcb plugin. This means said application requires that an X Server is
up and running before the QApplication is created. If we want said
application to connect to an Xwayland server we need to be able to
create the Wayland server AND the Xwayland server before creating
the QApplication.
The solution is to only create the socket notifier if the
QCoreApplication exists. For the case that it doesn't exist an
additional method is added which needs to be called once the
QCoreApplication got created. In addition a manual event dispatch
method is added which allows to block for events when we don't
have a QSocketNotifier set up yet.
Only selection part is implemented, drag'n'drop still needs to be
implemented.
Unit test is not properly testing whether the data can be transferred.
This needs some better architecture to have multiple processes which
perform the source and target part.
This implements the subcompositor and subsurface protocol on both
Client and Server side.
Client:
New classes SubCompositor and SubSurface. The SubCompositor can be
created through the Registry and creates the SubSurface which is
bound to a Surface and has a parent Surface. The SubSurface class
provides convenient wrappers for all calls exposed in the
wl_subsurface interface.
Server:
New classes SubCompositorInterface and SubSurfaceInterface. Support
for all commands is added, though the API probably still can need
some fine tuning. The synchronized vs. desynchronized behavior is
not yet exposed in the API. This could also be delegated towards
the user of the library.
This makes it possible to install and then use it. Installation is still
commented since we can't give enough stability guarantees for now.
In detail:
- do not actually install headers
- generate the export header into Wayland/Server
- include it from there
REVIEW:120579
Emitted when the Wayland display is done flushing the initial interface
callbacks, announcing wl_display properties. This can be used to compress
events. Note that this signal is emitted only after announcing interfaces,
such as outputs, but not after receiving callbacks of interface properties,
such as the output's geometry, modes, etc..
This signal is emitted from the wl_display_sync callback.
REVIEW:120471
The test started to fail on my system without changing anything. I
assume my system got an update to latest wayland version and it
looks like the registry doesn't announce anything if nothing is
registered. So now our display at least creates the Shm interface.
In addition the test case is slightly improved with a few smaller
changes added during the debug session.
The EventQueue is a wrapper for wl_event_queue. The usage is for the
case that the connection is in a different thread.
The EventQueue needs to be added to the Registry before Registry::create
is invoked. This ensures that the Registry gets added to the EventQueue
and all objects created by the Registry (and further down the tree)
will be added to the same EventQueue.
The auto-tests which already used a wl_event_queue are transited to the
EventQueue class. That's also the reason why there is no dedicated
unit test: the new code is sufficiently tested by the existing tests.
This makes the API more consistent and allows to properly cleanup
Keyboard and Pointer if the connection dies. Like with Shell and
ShellSurface signals are emitted from Seat when the interface is
going to be released or destroyed. These are connected to the
methods of the created Pointer and Keyboard.
