Summary:
The new tab shows the information from GLPlatform similar to how it is
shown in the supportInformation. In addition it also lists all available
openGL and EGL/GLX extensions. For that kwinglutils is extended by
functions to return the lists of extensions.
Reviewers: #kwin, #plasma, bshah
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2385
Summary:
Gesture events are swipe or pinch events on a touch pad.
This change implements basic support by:
* wrapping them in LibInput::Event
* processing them in LibInput::Connection and emitting
dedicated signals
* Forwarding them in InputRedirection to PointerInputRedirection
* Support them in the internal input event filter
* Printing debug information in DebugConsole
Further handling is not yet done. In future the following should be
implemented:
* activating e.g. zoom and present windows on pinch/swipe gesture
* forwarding non global gestures to KWayland
Note that forwarding to KWayland is not yet useful as QtWayland does
not yet have support for the unstable protocol. No Qt application could
make use of it yet. So for the moment just global gestures is the best
we can get.
Test Plan: Looked at output of DebugConsole when triggering gestures
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2359
Summary:
Now that we have access to the actual LibInput Device from the event
handler, let's also print out which device received an event.
Test Plan: Manual testing whether the correct device is shown
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1668
Summary:
Instead of reset a proper beginInsertRows, beginRemoveRows is used.
In addition changes in the device are also listened on and emit the
proper dateChanged signal.
Test Plan:
Opened debug console, selected the touchpad device,
toggled shortcut and verified that this updated the data column.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1547
Summary:
The Device class wraps all the information we can get from libinput
about the device, like whether it's a keyboard, pointer, touch, etc.
In addition some more information is queried to figure out how "useful"
a device is. For a keyboard all alphanumeric keys are checked whether
they exist, for a pointer all (normal) buttons are queried.
All the information is exposed as Q_PROPERTY and used by the
DebugConsole. The DebugConsole gained a new tab "Input Devices" which
renders all devices and their properties in a tree view. When plugging
in/out a device, the model gets reset, so it's always up to date.
The new Device class can be used in future to configure the device,
e.g. disable touch pad, set mouse acceleration, etc.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1538
Summary: Replaces the custom logic to switch between the three modes by tabs.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1271
Summary: Inspired by xev a new tool which prints out all input events.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1264
Summary:
While developing support for sub-surfaces it became obvious that there
is a need for visualizing the tree of sub-surfaces.
The surface-tree is a new mode added in the debug console. There are now
two buttons to switch between the default window tree and the surface
tree.
The surface tree is a little bit more basic than the windows tree. The
type of window (whether x11, wayland or internal) is ignored. All windows
build up the top level with the sub surfaces as children.
Each surface is represented by some basic information about it:
* Client (binary path and pid)
* internal surface id
If the surface has a shared memory buffer mapped a scaled down version
is used as the window decoration role.
The model gets reset whenever the tree changes in some way as it's
rather complex to track correctly and well, it's just a debug console.
Currently the tree is not really functional yet as KWin doesn't announce
support for sub-compositor protocol, which is also the reason for lack of
autotests for the model. Will be added once sub-compositor works
properly.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1205
Summary:
The idea behind the debugging console is to have a feature comparable
to xprop and xwininfo just for Wayland. We cannot have command line
utils as that violates the security restrictions, thus it needs to be
exposed directly in KWin.
The debugging console is invoked through DBus:
qdbus org.kde.KWin /KWin showDebugConsole
This opens a window with a tree view. The DebugConsoleModel which is
used by the tree view groups all windows into four categories:
* x11 clients (that is Workspace::clientList() and Workspace::desktopList())
* x11 unmanaged (Workspace::unmanagedList())
* wayland shell clients (WaylandServer::clients())
* wayland internal clients (KWin's own QWindows - WaylandServer::internalClients())
Each window is a child to one of the four categories. Each window itself
has all it's QProperties exposed as children.
This allows to properly inspect KWin's internal knowledge for windows and
should make it easier to investigate problems. E.g. what's a window's
geometry, what's it's window type and so on.
The debugging console is intended as a developer tool and not expected to
be used by users. That's why it's invokation is rather hidden. Due to
the fact that it's internal to KWin it results in:
* no window decoration
* stealing keyboard focus
* no way to resize, close, move from KWin side
* rendered above all other windows
There is a dedicated close button to get rid of it again. While the
console is shown it's hardly possible to interact with the system in
a normal way anymore. This is something which might be improved in
future.
At the moment the model is able to update when windows are added/removed,
but not yet when a property changes. Due to the lack of interaction with
the existing system, that's not a high priority at the moment, but can
be added in future.
Reviewers: #plasma
Differential Revision: https://phabricator.kde.org/D1146
Martin Gräßlin