Also removes an unnecessary second call to SeatInterface::setPointerPos.

I saw one potential problem, you can clarify if it's relevant. If event is someone that resend with different position that current one, as i can see input()->globalPointer() will result in current position which can be different from event position, do you think?

In D15502#327512, @anthonyfieroni wrote:

I saw one potential problem, you can clarify if it's relevant. If event is someone that resend with different position that current one, as i can see input()->globalPointer() will result in current position which can be different from event position, do you think?

Thanks for taking a look at it.

The filters are run through always directly after each event. In this case the relevant code is in pointer_input.cpp: PointerInputRedirection::processMotion, where m_pos is set by a call to PointerInputRedirection::updatePosition. Since this happens directly before every filter run on mouse move, the position is the same.

Yeah, i see they are in sync but if someone sends adjustment events who contain not a *real* mouse position like these https://phabricator.kde.org/source/plasma-workspace/browse/master/shell/panelview.cpp$839 Is this can be a problem>

In D15502#328074, @anthonyfieroni wrote:

Yeah, i see they are in sync but if someone sends adjustment events who contain not a *real* mouse position like these https://phabricator.kde.org/source/plasma-workspace/browse/master/shell/panelview.cpp$839 Is this can be a problem>

Where should these events originate from? The filters are run through directly afterthey comes from the PointerInputRedirection, which bases the position value on a hardware position. KWin is the compositor, so it does not receive hardware events from its clients.