<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 12:07 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm afraid this limitation is somewhat technical. The problem is that tablet generates Mouse(!) events too. And in most<br>
of the cases these mouse events do not correlate with what we get via native tablet events. It means that if we will<br>
start processing mouse events while tablet is in proximity, the lines will become dizzy, because of out-of-order events.<br>
What is more, in most of the cases we cannot distinguish real mouse events and the synthesized mouse events generated by<br>
the tablet. Right now people in Qt are working on distinguishing them but I'm not sure when and if it is going to work.<br>
There are too many variations where and how these synthesized events are generated.<br>
</blockquote>
<br></span>
Is that even true if we use a QAbstractNativeEventFilter?<br></blockquote><div><br></div><div>I don't know if it is true for XInput2, but in XInput mode the wacom driver was generating mouse events itself. As far as I know, in XI2 mode we can unsubscribe from them and synthesize events manually (that is exactly what Qt 5.5 did). So theoretically it is possible. But I'm not sure how it will work altogether.</div><br><div> </div></div>-- <br><div class="gmail_signature">Dmitry Kazakov</div>
</div></div>