Re: Need xcb/xkb help for severe kglobalaccel_x11 issue
Moin, Am Samstag, 6. Februar 2021, 10:08:43 CET schrieb David Faure: > Problem mostly fixed by > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/339 > but still seeing 15 notifications instead of 1 (already better than 145...). > > Indeed a single call to > /usr/bin/setxkbmap -layout us,fr -option -option compose:caps > sends 12 XCB_XKB_NEW_KEYBOARD_NOTIFY events, > all with changed & XCB_XKB_NKN_DETAIL_KEYCODES, which makes kglobalaccel > ungrab+regrab all keys. Here setxkbmap doesn't cause any XCB_XKB_NEW_KEYBOARD_NOTIFY events, only XCB_XKB_MAP_NOTIFY. I tried this with Xwayland though, maybe that behaves differently... > Should I add another compression timer in kglobalaccel, or do you think this > is > fixable in setxkbmap? It's probably fixable somewhere in either setxkbmap/xkb or the X server, but a compression timer would work even with older versions and also for other causes like xmodmap, which can be much worse than just 15 events. Cheers, Fabian
Re: Need xcb/xkb help for severe kglobalaccel_x11 issue
On 2021-02-06 10:08, David Faure wrote: Problem mostly fixed by https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/339 but still seeing 15 notifications instead of 1 (already better than 145...). Indeed a single call to /usr/bin/setxkbmap -layout us,fr -option -option compose:caps sends 12 XCB_XKB_NEW_KEYBOARD_NOTIFY events, all with changed & XCB_XKB_NKN_DETAIL_KEYCODES, which makes kglobalaccel ungrab+regrab all keys. Should I add another compression timer in kglobalaccel, or do you think this is fixable in setxkbmap? I think one should be realistic and just add yet another timer ;=) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Need xcb/xkb help for severe kglobalaccel_x11 issue
Problem mostly fixed by https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/339 but still seeing 15 notifications instead of 1 (already better than 145...). Indeed a single call to /usr/bin/setxkbmap -layout us,fr -option -option compose:caps sends 12 XCB_XKB_NEW_KEYBOARD_NOTIFY events, all with changed & XCB_XKB_NKN_DETAIL_KEYCODES, which makes kglobalaccel ungrab+regrab all keys. Should I add another compression timer in kglobalaccel, or do you think this is fixable in setxkbmap? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: Need xcb/xkb help for severe kglobalaccel_x11 issue
On dimanche 31 janvier 2021 00:30:14 CET Fabian Vogt wrote:
> I suspect that something else is triggering keyboard layout reloads or
> similar in a loop. The keyboard kded module listens for new keyboards and
> mouse events and configures them, which is likely to be called on resume
> when devices get reenumerated. You could try to disable that before
> suspend/resume.
Well spotted. After
qdbus org.kde.kded5 /kded unloadModule keyboard
and suspend/resume, I got only one call to KGlobalAccelImpl::x11MappingNotify
This is amazing. Suddenly it manages to reconnect to wifi instantly, too,
and my global shortcuts work instantly.
Previously, kded kept everyone so busy that everything crawled for about a
minute, and wifi timed out...
> If I run "xmodmap .Xmodmap" here with "xev" open, I get quite a high count
> of mapping change events, presumably for every assignment in the file. If
> the kded calls xmodmap with many assignments, that would be enough to
> explain the issue. Maybe xmodmap could be optimized to upload everything at
> once, like setxkbmap.
I debugged what happens in plasma-desktop/kcms/keyboard
and when resuming from suspend, XInputEventNotifier::processOtherEvents()
emits newKeyboardDevice() many many times.
Each time, the slot KeyboardDaemon::configureKeyboard() does all this
KeyboardConfig::load configuring layouts true configuring options true
X11Helper::getGroupNames Fetched keyboard model from X server: "pc101"
XkbHelper::runConfigLayoutCommand Executed successfully in 137 ms
"/usr/bin/setxkbmap -layout us,fr -option -option compose:caps"
XkbHelper::runConfigLayoutCommandand with xmodmap 137 ms
X11Helper::getGroupNames Fetched layout groups from X server: layouts:
("us", "fr") variants: ("", "")
KeyboardLayoutActionCollection::loadLayoutShortcuts Skipping empty shortcut for
"us"
KeyboardLayoutActionCollection::loadLayoutShortcuts Skipping empty shortcut for
"fr"
KeyboardLayoutActionCollection::loadLayoutShortcuts Cleaning component
shortcuts on load true
Going back up, the reason why processOtherEvents() thinks there's a new device
is this:
XInputEventNotifier::getNewDeviceEventType New device id: 15
XInputEventNotifier::getNewDeviceEventType id: 2 name: Virtual core pointer
used as: 0
XInputEventNotifier::getNewDeviceEventType id: 3 name: Virtual core keyboard
used as: 1
XInputEventNotifier::getNewDeviceEventType id: 4 name: Virtual core XTEST
pointer used as: 4
XInputEventNotifier::getNewDeviceEventType id: 5 name: Virtual core XTEST
keyboard used as: 3
XInputEventNotifier::getNewDeviceEventType id: 6 name: Power Button used as: 3
XInputEventNotifier::getNewDeviceEventType id: 7 name: Video Bus used as: 3
XInputEventNotifier::getNewDeviceEventType id: 8 name: Sleep Button used as: 3
XInputEventNotifier::getNewDeviceEventType id: 9 name: Logitech Craft used as: 4
XInputEventNotifier::getNewDeviceEventType id: 10 name: Logitech MX Master 2S
used as: 4
XInputEventNotifier::getNewDeviceEventType id: 11 name: Logitech MX Master used
as: 4
XInputEventNotifier::getNewDeviceEventType id: 12 name: Integrated Camera:
Integrated C used as: 3
XInputEventNotifier::getNewDeviceEventType id: 13 name: Integrated Camera:
Integrated I used as: 3
XInputEventNotifier::getNewDeviceEventType id: 14 name: AT Translated Set 2
keyboard used as: 3
XInputEventNotifier::getNewDeviceEventType id: 15 name: SynPS/2 Synaptics
TouchPad used as: 4
XInputEventNotifier::getNewDeviceEventType new pointer device, id: 15 name:
SynPS/2 Synaptics TouchPad used as:
Before that, it got notified of new device 6, 7, 8, and so on.
It's like X is re-enabling the devices one after the other, and we react to
each one immediately.
This misdetects the device types though:
new keyboard device, id: 13 name: Integrated Camera: Integrated I used as: 3
No, my webcam doesn't have keys...
And for some reason, even mouse devices trigger keyboard processing, see the
arghh comment:
bool XInputEventNotifier::processOtherEvents(xcb_generic_event_t* event)
{
int newDeviceType = getNewDeviceEventType(event);
if( newDeviceType == DEVICE_KEYBOARD ) {
emit(newKeyboardDevice());
}
else if( newDeviceType == DEVICE_POINTER ) {
emit(newPointerDevice());
emit(newKeyboardDevice()); // arghhh, looks like X resets xkb map even
when only pointer device is connected
}
return true;
}
> I actually had the issue that calling xmodmap here basically froze the whole
> session for a while, which was probably caused by that behaviour.
> Agreed. If those events are caused by something we can't fix, then this
> might turn out to be the best option though.
Now I'm thinking maybe the compression should happen in the keyboard module... ?
That wouldn't fix the xmodmap issue though.
Maybe we're seeing a N devices * M keys multiplication issue, i.e. it would be
good to compress at both levels.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
Re: Need xcb/xkb help for severe kglobalaccel_x11 issue
El diumenge, 31 de gener de 2021, a les 0:53:17 CET, David Faure va escriure: > On dimanche 31 janvier 2021 00:39:38 CET Albert Astals Cid wrote: > > El dissabte, 30 de gener de 2021, a les 18:32:32 CET, David Faure va > escriure: > > > 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. > > Does this happen on a short sleep too or needs a long sleep? > > Short sleep does it too. > Close laptop, wait a few seconds for light to blink, open laptop, 145 calls > to > KGlobalAccelImpl::x11MappingNotify (!) > > > If happens with a short sleep, i can't reproduce it :/ > > Lucky you ;) > > But that's interesting, maybe we can approach it from both sides to find what > triggers it. > > I moved out my small ~/.Xmodmap and restarted kglobalaccel5, no change. > Do you want to try with the attached ~/.config/kxkbrc? (after backing up > yours > of course). Unfortunately still all good, here's mine but i guess it won't fix it in your side either. Cheers, Albert > > [Layout] DisplayNames= LayoutList=es LayoutLoopCount=-1 Model=pc101 ResetOldOptions=false ShowFlag=false ShowLabel=true ShowLayoutIndicator=true ShowSingle=false SwitchMode=Global Use=true
Re: Need xcb/xkb help for severe kglobalaccel_x11 issue
On dimanche 31 janvier 2021 00:39:38 CET Albert Astals Cid wrote: > El dissabte, 30 de gener de 2021, a les 18:32:32 CET, David Faure va escriure: > > 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. > Does this happen on a short sleep too or needs a long sleep? Short sleep does it too. Close laptop, wait a few seconds for light to blink, open laptop, 145 calls to KGlobalAccelImpl::x11MappingNotify (!) > If happens with a short sleep, i can't reproduce it :/ Lucky you ;) But that's interesting, maybe we can approach it from both sides to find what triggers it. I moved out my small ~/.Xmodmap and restarted kglobalaccel5, no change. Do you want to try with the attached ~/.config/kxkbrc? (after backing up yours of course). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 [Layout] DisplayNames=, LayoutList=us,fr LayoutLoopCount=-1 Model=pc101 Options=compose:caps ResetOldOptions=true ShowFlag=false ShowLabel=true ShowLayoutIndicator=true ShowSingle=false SwitchMode=Global Use=true
Re: Need xcb/xkb help for severe kglobalaccel_x11 issue
Hi,
Am Samstag, 30. Januar 2021, 18:32:32 CET schrieb David Faure:
> 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...
It's just the XCB equivalent of XkbMapNotify. If you search for the latter, you
should get more hits.
> 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?
Yep. That's what an earlier revision did, but I was recommended to use pad0
instead:
https://phabricator.kde.org/D16434?vs=44241&id=44247&whitespace=ignore-most#toc
It's equivalent to xkbType, which indicates the exact type of this xkb event.
> I'm not sure:
> * if we're really getting a stream of XCB_XKB_MAP_NOTIFY events or if this
> code misunderstands that
I don't think that the code would misunderstand that. AFAICT the check is
strict enough to not catch other events, and if it's wrong instead it wouldn't
catch the correct events either. If this was the cause of the issue, I would
expect misbehaviour outside of the post-resume state. I can't rule it out
though.
> * if so, why is X11 sending such a high number of those
I suspect that something else is triggering keyboard layout reloads or similar
in a loop. The keyboard kded module listens for new keyboards and mouse events
and configures them, which is likely to be called on resume when devices get
reenumerated. You could try to disable that before suspend/resume.
If I run "xmodmap .Xmodmap" here with "xev" open, I get quite a high count of
mapping change events, presumably for every assignment in the file. If the kded
calls xmodmap with many assignments, that would be enough to explain the issue.
Maybe xmodmap could be optimized to upload everything at once, like setxkbmap.
I actually had the issue that calling xmodmap here basically froze the whole
session for a while, which was probably caused by that behaviour.
> * why the code reacts the same to XCB_XKB_MAP_NOTIFY and to
> XCB_MAPPING_NOTIFY, isn't one enough?
When an X client indicates that it uses Xkb instead of the X core protocol,
then it will only receive XKB events. In the case of kglobalaccel, the decision
is made by Qt (which is why it broke at some point). The XCB_MAPPING_NOTIFY
case is probably unused now, which could be ensured by just doing Xkb stuff
explicitly on initialization.
> 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.
Agreed. If those events are caused by something we can't fix, then this might
turn out to be the best option though.
Cheers,
Fabian
> I just noticed https://phabricator.kde.org/D16434 so CC'ing Fabian :)
Re: Need xcb/xkb help for severe kglobalaccel_x11 issue
El dissabte, 30 de gener de 2021, a les 18:32:32 CET, David Faure va escriure:
> 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.
Does this happen on a short sleep too or needs a long sleep?
If happens with a short sleep, i can't reproduce it :/
I just added https://ghostbin.com/paste/Xqgd4 and all i get is
https://ghostbin.com/paste/LMa9n after suspending and resuming a few times.
> 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?
Far from an expert, but i think they are two ways (pure XCB or XKB over XCB
(which is why it uses pad0 to get out the xkb event from the xcb one)) to
notify the same, so I would say it makes sense to handle both.
Cheers,
Albert
>
> 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 :)
>
>
Need xcb/xkb help for severe kglobalaccel_x11 issue
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
