Problem with wacom pen: tabletEvent and mouse{Press,Release}Event overlap

Hi!

I'm experiencing problems working with the pen of my Lenovo X220T. I noticed that I can not draw rectangles. More precisely: They're a single point when the cursor snaps to the grid, i.e. the seconds point is set to be the same as the first point.
I noticed that the syntetic mouse events sent from QG_GraphicView::tabletEvent overlap with the native mouseRelease/Press events.
A quick fix for me was to just comment out the syntetic mouse events in ::tabletEvent but this seems clumsy and I don't know if that would break other people's hardware or if this might break with another Qt version / Xorg version or whatever.
According to Qt's docs, Qt should not be sending a (for example) mousePressEvent if the QTabletEvent was accepted but adding ev->accept() to ::tabletEvent (before sending the syntetic mouse event but that sould not matter) did not fix my problem so maybe the mousePressEvent is caused by xinput in my case.
Adding ev->accept() would not harm either way as it conforms to QTouchEvent's documentation.

After adding debug output to QG_GraphicView::mousePressEvent and QG_GraphicView::mouseReleaseEvent I noticed that the events overlap, i.e. the order is:

PRESS (native)
PRESS (syntetic)
RELEASE (native)
RELEASE (syntetic)

This order does not make any sense logic-wise because:
a) there's no way you can receive two press events without a release event inbetween if you have one input device
b) in case of multiple input devices: there's no meaning in accepting two press events without a release event inbetween.

So I suggest that the "proper" way would be to keep track of the state.

::mousePressEvent
    if (pressed) return
    pressed = true
    //logic here

::mouseReleaseEvent
    if (!pressed) return
    pressed = false
    //logic here

This way the syntetic events would just be ignored because the native events caused the state to be set accordingly. In case other people's tablet setup does not cause native mouse events to be set, this solution would not break their setup.

Any thoughts? I can prepare a patch for the state tracking if this sounds meaningful to you.


Cheers,

cptG

Hi cptG,

ravas is working on GUI side

I feel we should review the logic with touch screens, mouse, together with wacom in mind.

Feel free to send in pull requests for fixes and/or diagnosis.

Thanks,

dxli

cptG wrote

Hi!

I'm experiencing problems working with the pen of my Lenovo X220T. I noticed that I can not draw rectangles. More precisely: They're a single point when the cursor snaps to the grid, i.e. the seconds point is set to be the same as the first point.
I noticed that the syntetic mouse events sent from QG_GraphicView::tabletEvent overlap with the native mouseRelease/Press events.
A quick fix for me was to just comment out the syntetic mouse events in ::tabletEvent but this seems clumsy and I don't know if that would break other people's hardware or if this might break with another Qt version / Xorg version or whatever.
According to Qt's docs, Qt should not be sending a (for example) mousePressEvent if the QTabletEvent was accepted but adding ev->accept() to ::tabletEvent (before sending the syntetic mouse event but that sould not matter) did not fix my problem so maybe the mousePressEvent is caused by xinput in my case.
Adding ev->accept() would not harm either way as it conforms to QTouchEvent's documentation.

After adding debug output to QG_GraphicView::mousePressEvent and QG_GraphicView::mouseReleaseEvent I noticed that the events overlap, i.e. the order is:

PRESS (native)
PRESS (syntetic)
RELEASE (native)
RELEASE (syntetic)

This order does not make any sense logic-wise because:
a) there's no way you can receive two press events without a release event inbetween if you have one input device
b) in case of multiple input devices: there's no meaning in accepting two press events without a release event inbetween.

So I suggest that the "proper" way would be to keep track of the state.

::mousePressEvent
    if (pressed) return
    pressed = true
    //logic here

::mouseReleaseEvent
    if (!pressed) return
    pressed = false
    //logic here

This way the syntetic events would just be ignored because the native events caused the state to be set accordingly. In case other people's tablet setup does not cause native mouse events to be set, this solution would not break their setup.

Any thoughts? I can prepare a patch for the state tracking if this sounds meaningful to you.


Cheers,

cptG