There are a couple of reasons not to use the lambda:
* It is unnecessary. The DrmGpu has the DRM file descriptor
* If a crash occurs somewhere in the lambda, the backtrace will be hard
to read
* Instead of processing events in the destructor of the DrmBackend
class, we should keep dispatching events without involving
QCoreApplication::processEvents() until all page flips are completed.
There seems to be an interval between when you copy something from a Wayland
client and when you attempt to paste it into an X client where m_chunks.first().first
is empty, and trying to access its .data() will cause an assertion. While we can't
really gracefully handle this situation, we can at least terminate the function early
and turn the paste operation into a noop instead of a crash.
I just had that crash, this is what coredumpctl suggested it was
happening.
We don't need to make sure we're in dmabuf mode to remove the buffer.
Worst case scenario it won't remove anything. Check the spa_data before
querying in case it's null.
qEnvironmentVariableIntValue() will return 0 if the specified variable
is not set.
This means that swap events will be disabled on AMD GPUs unless the env
var is set explicitly to 1.
This is in a way working around bad protocol, input-method-unstable-v1
and also input-method-unstable-v2 does not have a way for input-method
to mark itself as "deactivated". This can happen when e.g. user closes
the virtual keyboard using swiping down or "close keyboard" button in
keyboard.
When this happens, the state between compositor, text_input and
input_method gets out of sync, compositor does not know that input
method got deactivated and hence it will continue sending various events
to it. The quick way around it is to change focus, which makes
compositor send deactivate request to input-method, that puts compositor
and input-method in sync again.
This patch aims to solve this by tracking the last state of input
method, If we know that input method is active and text input sends us
the show event, we toggle the input-method.
I will re-iterate that this is in no way proper solution, ideally
input-method-unstable-v3 or input-method-unstable-v2 even (since it is
not upstream anyway) gains the new request which essentially allows
input-method to sync enabled/disabled state with compositor.
The contents of the if branch is identical to the implementation of the
Toplevel::damageNotifyEvent() function and setReadyForPainting() will
never be called because m_syncRequest.isPending can be true only if the
window supports sync counters.
In case the compositor wants to cancel a touch sequence, we need to
ignore subsequent touch motion and touch up events until a new sequence
is initiated by the user.
Previously, it was implicitly handled by clearing the mapping table
between the touch slots and touch ids generated by kwayland-server.
At the moment, the display name might change between Xwayland restarts.
It is a problem because the session process (plasma) may have an
outdated value of the DISPLAY environment variable after a restart.
With this change, it is guaranteed that the DISPLAY and the Xauthority
file stay the same until the server is stopped explicitly.
Since QWindowSystemInterface::handleScreenRemoved would not be called in Integration::handleScreenDisabled, Qt apps would still reference disabled screens resulting in crashes.
Previously the text values were updated to the model after
`onEditingFinished()`, that is after losing focus, to prevent
erroneus updates.
This was making also the `needsSaving` signal fire only after
a focus change, which is not consistent with the behavior of
other KCMs.
Use `onTextEdit()` instead, so the model is updated as the user
types.
BUG: 431211
Currently the highlight is only for the items. KCModuleData will come in another MR.
This is more simple implementation than the one I previously made.
Some default value are hardcoded in the KCM such as Rows count (2) and the number
of virtual desktop, on revert to default, it keeps only the first one.
Since kwin runs as a normal user, it cannot create the X11 connection
socket directory because any user process can easily compromise the
security of the system by unsetting the sticky bit.
In order to guarantee the security of the system, the socket directory
must be created by root and have the sticky bit on.
This adds a command line tool which allows the user to set the window
decoration, and then that tool is used in the two knsrc files to allow
the user to switch window decoration directly from either a KNS dialog,
or from Discover.
Xwayland starts listening to -listenfd file descriptors after the WM_S0
selection is claimed. At the moment, it is claimed asynchronously by
kwin. First, we create a dummy window and change one of its properties
to get the timestamp. After the timestamp has been received, we actually
call xcb_set_selection_owner().
This provides kwin greater control over how X11 sockets are created for
Xwayland. For example, it can be used to ensure that the DISPLAY remains
the same across Xwayland server restarts or launching Xwayland on
demand.
Even though -listen <fd> option is deprecated, we still pass it because
older versions of Xwayland may not have the -listenfd option.
This renames updateXauthorityFile to writeXauthorityEntries as it doesn't
actually update (i.e. change) anything, it just writes new ones.
Error handling is introduced, to avoid that it continues silently without
entries, which would cause all connections to fail.
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
Occasionally, I see complaints about the file organization of kwin,
which is fair enough.
This change makes the source code more relocatable by removing relative
paths from includes.
CMAKE_CURRENT_SOURCE_DIR was added to the interface include directories
of kwin library. This means that as long as you link against kwin target,
the real location of the source code of the library doesn't matter.
With autotests, things are not as convenient as with kwin target. Some
tests use cpp files from kwin core. If we move all source code in a src/
directory, they will need to be adjusted, but mostly only in build
scripts.
