Float position values in drag input filter
ClosedPublic

Authored by romangg on Sep 14 2018, 10:58 AM.

Details

Summary

We lost information when using QMouseEvent::globalPos, since
it is integer. Use instead InputRedirection::globalPointer,
which is updated before the filters are processed and is
float.

Test Plan

Manually.

Diff Detail

Repository
R108 KWin
Branch
dragPointFPos
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 2849
Build 2867: arc lint + arc unit
romangg created this revision.Sep 14 2018, 10:58 AM
Restricted Application added a project: KWin. · View Herald TranscriptSep 14 2018, 10:58 AM
Restricted Application added a subscriber: kwin. · View Herald Transcript
romangg requested review of this revision.Sep 14 2018, 10:58 AM

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?

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>

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.

davidedmundson accepted this revision.Oct 30 2018, 3:26 PM
This revision is now accepted and ready to land.Oct 30 2018, 3:26 PM
This revision was automatically updated to reflect the committed changes.