For years, I've noticed that when resuming a laptop from sleep, kglobalaccel 
and X11 
use 100% CPU for a few minutes, making everything crawl for a while.

I finally debugged why: kglobalaccel grabs and ungrabs all global shortcuts 
many many times in a row.

KGlobalAccelImpl::nativeEventFilter event->response_type= 85 xkbEvent= 1 
calling x11MappingNotify()
KGlobalAccelImpl::x11MappingNotify Got XMappingNotify event
KGlobalAccelInterface::ungrabKeys 
KGlobalAccelInterface::grabKeys 
KGlobalAccelImpl::nativeEventFilter event->response_type= 85 xkbEvent= 1 
calling x11MappingNotify()
KGlobalAccelImpl::x11MappingNotify Got XMappingNotify event
KGlobalAccelInterface::ungrabKeys 
KGlobalAccelInterface::grabKeys 
and so on, and so on...

The reason why x11MappingNotify() does ungrabKeys+grabKeys is apparently "Maybe 
the X modifier map has been changed."
... which is not the case at all...

What's an XCB_XKB_MAP_NOTIFY anyway?  
http://manpages.ubuntu.com/manpages/xenial/en/man3/xcb_xkb_map_notify_event_t.3.html
is very much incomplete...

Is it event really such an event that we're getting?
The code says

    } else if (m_xkb_first_event && responseType == m_xkb_first_event) {
        const uint8_t xkbEvent = event->pad0;
        switch (xkbEvent) {
            case XCB_XKB_MAP_NOTIFY:
                qDebug() << "event->response_type=" << event->response_type << 
"xkbEvent=" << xkbEvent << "calling x11MappingNotify()";
                x11MappingNotify();
                break;

What sense does it make that this code is checking pad0, which looks like some 
padding member? To avoid a downcast to a more specific event type maybe?

I'm not sure:
* if we're really getting a stream of XCB_XKB_MAP_NOTIFY events or if this code 
misunderstands that
* if so, why is X11 sending such a high number of those
* why the code reacts the same to XCB_XKB_MAP_NOTIFY and to XCB_MAPPING_NOTIFY, 
isn't one enough?

Without outside help I guess I would just compress those events using a timer, 
but that would be a "fix without really understanding the code", never good.

I just noticed https://phabricator.kde.org/D16434 so CC'ing Fabian :)
                
-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5



Reply via email to