Could you explain the relationship to global shortcuts? That sounds to me like a bug which needs to be fixed in kglobalaccel

Might this change fix this issue? https://bugs.kde.org/show_bug.cgi?id=370588

In D3829#71714, @graesslin wrote:

Could you explain the relationship to global shortcuts? That sounds to me like a bug which needs to be fixed in kglobalaccel

I don't really sure about this. So basically XlibNotifications uses XISelectEvent to monitor certain event. And strangely, the event is not received only if it is triggered by global hotkey. The Display* used in touchpad kded is already a separated one instead of Qt's, so I don't know if there's any interference between them. If someone could highlight me about what is the real cause of this I'd appreciated it.

My guess is that it could be caused by mix Xinput call on the same display and there's some interference.

In D3829#71724, @knambiar wrote:

Might this change fix this issue? https://bugs.kde.org/show_bug.cgi?id=370588

Yeah, I suspect so. I already put it in CCBUG, but I'd prefer reporter to confirm it.

In D3829#71877, @xuetianweng wrote:

In D3829#71714, @graesslin wrote:

Could you explain the relationship to global shortcuts? That sounds to me like a bug which needs to be fixed in kglobalaccel

I don't really sure about this. So basically XlibNotifications uses XISelectEvent to monitor certain event. And strangely, the event is not received only if it is triggered by global hotkey.

Which "event"?

The Display* used in touchpad kded is already a separated one instead of Qt's, so I don't know if there's any interference between them. If someone could highlight me about what is the real cause of this I'd appreciated it.

This sounds weird and wrong to me. In none of the applications we use, even in the heavily X relying one like KWin or kglobalaccel, we create another Display, but use the one Qt provides. From my experience there is no need to have a dedicate Display. It can certainly be a source for issues.

In D3829#71988, @graesslin wrote:

In D3829#71877, @xuetianweng wrote:

In D3829#71714, @graesslin wrote:

Could you explain the relationship to global shortcuts? That sounds to me like a bug which needs to be fixed in kglobalaccel

I don't really sure about this. So basically XlibNotifications uses XISelectEvent to monitor certain event. And strangely, the event is not received only if it is triggered by global hotkey.

Which "event"?

search XIPropertyEvent in xlibnotifications.cpp

For whatever reason, that part of code is not reached if it is triggered by global hotkey with current code, the display pointer is not shared with anyone.. I really don't understand why adding a new one helps, but it does help.

I would say the overall problem is that this here still uses an XLib event queue. But Qt uses an xcb connection. I would say this needs a porting away from the XLib code and use Qt's XCB connection and event handling.

In D3829#72924, @graesslin wrote:

I would say the overall problem is that this here still uses an XLib event queue. But Qt uses an xcb connection. I would say this needs a porting away from the XLib code and use Qt's XCB connection and event handling.

At that time the xinput in xcb is incomplete and buggy so XLib is the only choice. Not sure if things change now.

In D3829#73066, @xuetianweng wrote:

In D3829#72924, @graesslin wrote:

I would say the overall problem is that this here still uses an XLib event queue. But Qt uses an xcb connection. I would say this needs a porting away from the XLib code and use Qt's XCB connection and event handling.

At that time the xinput in xcb is incomplete and buggy so XLib is the only choice. Not sure if things change now.

no, it never was buggy. There are just no bindings. But all we care about are the events. And events are just a struct. If one wants to use them one can. An example how one can use XInput from an xcb based application without needing the bindings is https://cgit.kde.org/kwin.git/tree/plugins/platforms/x11/standalone/xinputintegration.cpp

What's next for this?

This patch works for me :)

@graesslin, does this still need changes to be merge-worthy?

My proposal to fix the bug at https://phabricator.kde.org/D10498

In D3829#158947, @ngraham wrote:

@graesslin, does this still need changes to be merge-worthy?

Yes, we did not migrate back to xlib, so the port to xcb is still required.