2016-07-01 14:49 GMT+02:00 Elvis Stansvik <[email protected]>: > 2016-07-01 14:01 GMT+02:00 Elvis Stansvik <[email protected]>: >> 2016-06-30 18:59 GMT+02:00 Thiago Macieira <[email protected]>: >>> On quinta-feira, 30 de junho de 2016 17:16:54 PDT Elvis Stansvik wrote: >>>> Would it be possible to install a QAbstractNativeEventFilter and >>>> somehow "fix-up" the event combination that makes the event >>>> compression fail? Has anyone else been in the same boat? >>> >>> Yes, in combination with a non-native filter that detects when the event has >>> been delivered and processed. You need to keep a state: >>> >>> if event has been seen >>> and event has not been delivered >>> swallow event >> >> I'm not actually sure I understand this approach, would be great if >> you could elaborate just a little. >> >> Also, how would I determine if an event has been "seen"? And how would >> I correlate the non-native event and the native when I receive the >> non-native one? >> >> Using this code: >> >> static inline bool isXIEvent(xcb_generic_event_t *event, int opCode) >> { >> xcb_ge_generic_event_t *e = (xcb_ge_generic_event_t *)event; >> return e->extension == opCode; >> } >> >> static inline bool isXIType(xcb_generic_event_t *event, int opCode, >> uint16_t type) >> { >> if (!isXIEvent(event, opCode)) >> return false; >> >> xXIGenericDeviceEvent *xiEvent = >> reinterpret_cast<xXIGenericDeviceEvent *>(event); >> return xiEvent->evtype == type; >> } >> >> MotionEventFilter::MotionEventFilter(QObject *parent) : QObject(parent) >> , m_xiOpCode(0) >> { >> // Query the XInput extension for its major opcode >> int xiEventBase, xiErrorBase; >> XQueryExtension(QX11Info::display(), "XInputExtension", >> &m_xiOpCode, &xiEventBase, &xiErrorBase); >> } >> >> bool MotionEventFilter::nativeEventFilter(const QByteArray &eventType, >> void *message, long *result) >> { >> Q_UNUSED(result); >> >> if (eventType == "xcb_generic_event_t") { >> auto event = static_cast<xcb_generic_event_t *>(message); >> >> switch (event->response_type & ~0x80) { >> case XCB_MOTION_NOTIFY: { >> std::cout << "XCB_MOTION_NOTIFY" << std::endl; >> break; >> } >> case XCB_GE_GENERIC: { >> if (isXIType(event, m_xiOpCode, XI_Motion)) >> std::cout << "XI_Motion" << std::endl; >> break; >> } >> default: >> break; >> } >> } >> return false; >> } >> >> I've been able to determine that the XCB_GE_GENERIC events I'm getting >> are actually XI_Motion events from the XInput2 extension: The above >> prints: >> >> XI_Motion >> XI_Motion >> ... >> >> when I move the mouse. >> >> But I'm not seeing the symptom described in that bugfix commit >> message, which says: >> >> "The current version of the mouse motion event compression >> algorithm does not work with certain configurations - >> situations where we get one XCB_GE_GENERIC event between >> every XCB_MOTION_NOTIFY event." >> >> So I'm now unsure if this is really the bug I'm seeing, or if >> something else is causing event compression to fail. >> >> If I'm going to compress events on my own, wouldn't I need to maintain >> my own event queue like Qt does? Or is there an API to inspect the Qt >> event queue? > > In fact, I don't think this is really possible on the application > side. At least not in a satisfactory way. Because doesn't Qt poll XCB > for events, possibly taking in a whole bunch of them at once into its > queue, and then decides what to deliver and what to discard? I don't > see how I could do something similar at the app level, where I'm not > in charge of the XCB connection so to speak. > > I'd love to hear if anyone thinks what I'm seeing is really the bug fixed by > > https://codereview.qt-project.org/#/c/126136/ > > or if it's something else. > > To me it looks like it might be something else, since I'm not > receiving any XCB_MOTION_NOTIFY at all, only XI_Motion (are those > supposed to be compressed in 5.5.1?).
In the meantime, I think I've found a way to work around the bug in the framework I'm using (VTK) together with Qt. There was a way to make it not issue a render in its GL window in response to every mouse move, and instead direct it through a call to update() on the QWidget in which I had the GL window. So I think I'll use that workaround instead of trying to work around it using event filtering. Thanks for the input anyway! Elvis > > Elvis > >> >> Elvis >> >>> >>> -- >>> Thiago Macieira - thiago.macieira (AT) intel.com >>> Software Architect - Intel Open Source Technology Center >>> >>> _______________________________________________ >>> Interest mailing list >>> [email protected] >>> http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
