wilderjds/kwin - kwin - gitea-jacopods

Author	SHA1	Message	Date
Aleix Pol	f5a73b87e3	Initial support for tablets on Wayland Summary: This includes support for them on libinput and turns it into fake pointer actions. This doesn't implement zwp_tablet, this will have to happen in an iteration later. Test Plan: Been playing around with it, see video. https://www.youtube.com/watch?v=GF1WbO8FVvU Reviewers: #plasma, #kwin, romangg Reviewed By: #plasma, #kwin, romangg Subscribers: zzag, davidedmundson, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D25663	6 years ago
Frederik Gladhorn	12886cf442	Be consistent about touch point id type: use qint32 Summary: There is no point in using quint32 and casting back and forth in numerous places. Fix a bunch of compiler warnings that we implicitly cast between signed and unsigned. This makes things consistent with what we get from libinput. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: zzag, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23086	7 years ago
Martin Flöser	d2a9232ad3	Pass SwitchEvent from LibInput through KWin and add to DebugConsole Summary: This change introduces a new SwitchEvent and passes it through the InputEventSpy and InputEventFilter. The DebugConsoleFilter implements it so that the events can be monitored in the debug console. Test Plan: Untested as my only device with such switches has too old libinput Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D9521	8 years ago
Martin Gräßlin	a9ac70f007	It makes sense to actually also build the new input_event_spy.cpp Sometimes C++ surprises me. How could that compile without being in the build set?	9 years ago
Martin Gräßlin	84e3308149	Introduce an InputEventSpy for processing input events Summary: So far KWin's input event processing is mostly based on InputEventFilters. A filter can - as the name suggest - filter out an input event from further processing. Our code shows that this is not sufficient for all input event processing. We have several areas inside KWin where we need to have access to all input events, where the processing needs to happen on all events and filtering is not allowed. This results in sub-optimal code which has classes which know too much and do too much. Examples: * key-repeat handling done in KeyboardInputRedirection * Layout change OSD in Xkb * modifier only shortcuts in Xkb * emitting signals for Cursor class in KeyboardInputRedirection Also there are misuses of the InputEventFilters and internal API * DebugConsole keyboard state (uses wrong information) * DebugConsole input events tab (uses Filter, should be a spy) This change introduces the API needed to fix these problems. It introduces an InputEventSpy which is modelled after the InputEventFilter with the difference that it has only void messages and uses the KWin introduced event classes. The spies are always processed prior to the filters, thus we know it can have all events. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D3863	9 years ago