Re: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole)
Thiago Macieira wrote: >> In fact, couldn't qev include xev functionality in a native event filter? > > It could, but I think the interesting part of qev is to show how it > interpreted the events into Qt. > Anyway, qev isn't really being developed. The last commit to it was mine a I noticed that :) What I think should be at least potentially useful is to show the non- interpreted events. Otherwise you just see a list of Qt events and in fact nothing about interpretation. I started to hack the xev.c source with the idea to call it from a native event handler. I dropped that (for now) when I discovered xev's snooping option... R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce)
Thiago Macieira wrote:
>> AltGr. This is with a US-international layout so it requires AltGr to
>> trigger the deadkey accents.
>
> I know what it is (I have it too, so I can get æ and ø). I was asking about
> where the KeyPress for it is. Neither your nor René's paste showed it.
>
Did it? That was an oversight then:
KeyPress event, serial 40, synthetic NO, window 0x541,
root 0xf6, subw 0x0, time 136884486, (142,95), root:(1328,147),
state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x541,
root 0xf6, subw 0x0, time 136884592, (142,95), root:(1328,147),
state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES,
XLookupString gives 2 bytes: (c2 b4) "´"
XmbLookupString gives 0 bytes:
XFilterEvent returns: True
KeyRelease event, serial 40, synthetic NO, window 0x541,
root 0xf6, subw 0x0, time 136884752, (142,95), root:(1328,147),
state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES,
XLookupString gives 2 bytes: (c2 b4) "´"
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x541,
root 0xf6, subw 0x0, time 136884808, (142,95), root:(1328,147),
state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x541,
root 0xf6, subw 0x0, time 136884957, (142,95), root:(1328,147),
state 0x0, keycode 26 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XmbLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: True
KeyPress event, serial 40, synthetic NO, window 0x541,
root 0xf6, subw 0x0, time 136884957, (142,95), root:(1328,147),
state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES,
XKeysymToKeycode returns keycode: 11
XLookupString gives 0 bytes:
XmbLookupString gives 2 bytes: (c3 a9) "é"
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x541,
root 0xf6, subw 0x0, time 136885057, (142,95), root:(1328,147),
state 0x0, keycode 26 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: False
The keypress also shows up in qev:
QKeyEvent(ShortcutOverride, Key_AltGr, GroupSwitchModifier)
QKeyEvent(KeyPress, Key_AltGr, GroupSwitchModifier)
QKeyEvent(KeyRelease, Key_Dead_Acute, GroupSwitchModifier)
QKeyEvent(KeyRelease, Key_AltGr)
QInputMethodEvent(, commit="U+e9")
QInputMethodQueryEvent(queries=0x1, {})
QInputMethodQueryEvent(queries=0x2, {})
QInputMethodQueryEvent(queries=0x1, {})
QInputMethodQueryEvent(queries=0x2, {})
QInputMethodQueryEvent(queries=0x1, {})
QInputMethodQueryEvent(queries=0x2, {})
QInputMethodQueryEvent(queries=0x1, {})
QInputMethodQueryEvent(queries=0x2, {})
QKeyEvent(KeyRelease, Key_E, text="e")
Something curious, when I let xev snoop the events from my wheeltest
demonstrator, certain events appear to be inverted (release shows before the
press):
KeyRelease event, serial 22, synthetic NO, window 0x5400026,
root 0xf6, subw 0x0, time 137048790, (68,42), root:(73,89),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyRelease event, serial 22, synthetic NO, window 0x5400026,
root 0xf6, subw 0x0, time 137059575, (68,42), root:(73,89),
state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 22, synthetic NO, window 0x5400026,
root 0xf6, subw 0x0, time 137059575, (68,42), root:(73,89),
state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
PropertyNotify event, serial 22, synthetic NO, window 0x5400026,
atom 0x15f (_NET_WM_USER_TIME), time 137059578, state PropertyNewValue
KeyRelease event, serial 22, synthetic NO, window 0x5400026,
root 0xf6, subw 0x0, time 137059760, (68,42), root:(73,89),
state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES,
XLookupString gives 2 bytes: (c2 b4) "´"
XFilterEvent returns: False
KeyPress event, serial 22, synthetic NO, window 0x5400026,
root 0xf6, subw 0x0, time 137059760, (68,42), root:(73,89),
state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES,
XLookupString gives 2 bytes: (c2 b4) "´"
XmbLookupString gives 0 bytes:
XFilterEvent returns: True
PropertyNotify event, serial 22, synthetic NO
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce)
On Friday, 9 June 2017 09:52:32 PDT Allan Sandfeld Jensen wrote: > On Freitag, 9. Juni 2017 17:55:06 CEST Thiago Macieira wrote: > > On Friday, 9 June 2017 07:29:52 PDT René J. V. Bertin wrote: > > > KeyRelease event, serial 22, synthetic NO, window 0x5400023, > > > > > > root 0xf6, subw 0x0, time 126529660, (106,16), root:(680,46), > > > state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), > > > same_screen > > > > > > YES, XKeysymToKeycode returns keycode: 92 > > > > > > XLookupString gives 0 bytes: > > > XFilterEvent returns: False > > > > Both you and Allan: where's the key press for the level 3 shift? > > AltGr. This is with a US-international layout so it requires AltGr to > trigger the deadkey accents. I know what it is (I have it too, so I can get æ and ø). I was asking about where the KeyPress for it is. Neither your nor René's paste showed it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce)
On Freitag, 9. Juni 2017 17:55:06 CEST Thiago Macieira wrote: > On Friday, 9 June 2017 07:29:52 PDT René J. V. Bertin wrote: > > KeyRelease event, serial 22, synthetic NO, window 0x5400023, > > > > root 0xf6, subw 0x0, time 126529660, (106,16), root:(680,46), > > state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen > > > > YES, XKeysymToKeycode returns keycode: 92 > > > > XLookupString gives 0 bytes: > > XFilterEvent returns: False > > Both you and Allan: where's the key press for the level 3 shift? AltGr. This is with a US-international layout so it requires AltGr to trigger the deadkey accents. 'Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole)
On Friday, 9 June 2017 06:02:08 PDT René J. V. Bertin wrote:
> The dead_acute is there twice;
Yes, but one is a KeyPress and the other is a KeyRelease.
> qt.qpa.input.methods.serialize: QIBusText::fromDBusArgument() "(sa{sv}sv)"
> qt.qpa.input.methods.serialize: QIBusAttributeList::fromDBusArgument()
> "(sa{sv}av)"
> QInputMethodEvent(, commit="U+e9")
That's a difference compared to me: I don't have ibus turned on.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce)
On Friday, 9 June 2017 07:29:52 PDT René J. V. Bertin wrote: > KeyRelease event, serial 22, synthetic NO, window 0x5400023, > root 0xf6, subw 0x0, time 126529660, (106,16), root:(680,46), > state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen > YES, XKeysymToKeycode returns keycode: 92 > XLookupString gives 0 bytes: > XFilterEvent returns: False Both you and Allan: where's the key press for the level 3 shift? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole)
On Friday, 9 June 2017 04:32:05 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > That's called qev and you can find in qttools/src/qev. It's not built by > > default. > > But I really meant xev. I just want to know if xev receives any extra > > events in there. > > In fact, couldn't qev include xev functionality in a native event filter? It could, but I think the interesting part of qev is to show how it interpreted the events into Qt. Anyway, qev isn't really being developed. The last commit to it was mine a year ago that made it *usable* by printing the event contents instead of the pointer addresses (10411e51782f7274da626bec01ec3ab8cae8723b qev: Actually print the events, quote "Otherwise, this is the most useless application ever.") We're lucky that whoever did the modularisation in 2011 copied it over (thank you Marius, Prasanth and Liang, IIRC!). It did not receive *any* commits in its Qt 5 or Qt 4 history besides buildsystem and copyright header changes. http://code.qt.io/cgit/qt/qttools.git/log/src/qev/qev.cpp http://code.qt.io/cgit/qt/qt.git/log/tools/qev/qev.cpp -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce)
René J. V. Bertin wrote: > Evidently one cannot use xev now because it'll involve a focus change. But the Actually, maybe one can: `xev -id ` Using that and Qt4: xev (all ok): KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529470, (106,16), root:(680,46), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529470, (106,16), root:(680,46), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529632, (106,16), root:(680,46), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529660, (106,16), root:(680,46), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529761, (106,16), root:(680,46), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False KeyPress event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529761, (106,16), root:(680,46), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529761, (106,16), root:(680,46), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XKeysymToKeycode returns keycode: 11 XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529876, (106,16), root:(680,46), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False qev: QKeyEvent(ShortcutOverride, key=0x1001103) QKeyEvent(KeyPress, key=0x1001103) QKeyEvent(KeyRelease, key=0x1001251, modifiers=0x4000, text="´") QKeyEvent(KeyRelease, key=0x1001103, modifiers=0x4000) QInputMethodEvent(, commit="U+e9") QKeyEvent(KeyRelease, key=0x45, text="e") xev (issue triggered): KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954309, (114,-8), root:(688,22), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954309, (114,-8), root:(688,22), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False PropertyNotify event, serial 24, synthetic NO, window 0x5400023, atom 0x15f (_NET_WM_USER_TIME), time 126954318, state PropertyNewValue KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954399, (114,-8), root:(688,22), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954399, (114,-8), root:(688,22), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True PropertyNotify event, serial 24, synthetic NO, window 0x5400023, atom 0x15f (_NET_WM_USER_TIME), time 126954408, state PropertyNewValue KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954525, (114,-8), root:(688,22), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954621, (114,-8), root:(688,22), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, seria
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce)
On Freitag, 9. Juni 2017 15:30:11 CEST René J. V. Bertin wrote: > Yay, I have found a transient way to trigger the issue transiently! > > github.com:RJVB/qtwheeltest > > Builds against both Qt4 and Qt5. > > To trigger the issue under Plasma: > > - optionally type an é or other accented character to verify things work, > and to have the event output on the calling terminal > - move the mouse pointer to the titlebar taking care not to lose focus, > press the right button (or menu key on the keyboard), expand the "Move to > Desktop" submenu, and then hit the keyboard shortcut to send the window to > another desktop > - without moving the mouse, use the keyboard shortcut to switch to that > desktop. > > For me, the issue is now triggered until I cycle the focus to and fro > another app. Under Qt4, trying to enter an é will yield "´e", under Qt5 I'm > only able to get the unaccented character. > > Evidently one cannot use xev now because it'll involve a focus change. But > the "protected" text editor window has the event tracer function from qev, > which should help. > Then my issue is different I think, because I just don't get the dead-key at all composed or not. With qev: QKeyEvent(ShortcutOverride, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyPress, Key_AltGr, GroupSwitchModifier) QKeyEvent(ShortcutOverride, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyPress, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_AltGr) QKeyEvent(ShortcutOverride, Key_E, text="e") QKeyEvent(KeyPress, Key_E, text="e") QKeyEvent(KeyRelease, Key_E, text="e") with xev: KeyPress event, serial 40, synthetic NO, window 0x6a1, root 0xb8, subw 0x0, time 1982840014, (78,1462), root:(2002,1488), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x6a1, root 0xb8, subw 0x0, time 1982840550, (78,1462), root:(2002,1488), state 0x80, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 40, synthetic NO, window 0x6a1, root 0xb8, subw 0x0, time 1982840646, (78,1462), root:(2002,1488), state 0x80, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x6a1, root 0xb8, subw 0x0, time 1982840726, (78,1462), root:(2002,1488), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x6a1, root 0xb8, subw 0x0, time 1982841654, (78,1462), root:(2002,1488), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 40, synthetic NO, window 0x6a1, root 0xb8, subw 0x0, time 1982841654, (78,1462), root:(2002,1488), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XKeysymToKeycode returns keycode: 26 XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x6a1, root 0xb8, subw 0x0, time 1982841742, (78,1462), root:(2002,1488), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce)
Yay, I have found a transient way to trigger the issue transiently! github.com:RJVB/qtwheeltest Builds against both Qt4 and Qt5. To trigger the issue under Plasma: - optionally type an é or other accented character to verify things work, and to have the event output on the calling terminal - move the mouse pointer to the titlebar taking care not to lose focus, press the right button (or menu key on the keyboard), expand the "Move to Desktop" submenu, and then hit the keyboard shortcut to send the window to another desktop - without moving the mouse, use the keyboard shortcut to switch to that desktop. For me, the issue is now triggered until I cycle the focus to and fro another app. Under Qt4, trying to enter an é will yield "´e", under Qt5 I'm only able to get the unaccented character. Evidently one cannot use xev now because it'll involve a focus change. But the "protected" text editor window has the event tracer function from qev, which should help. R ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole)
Thiago Macieira wrote:
> Here's my output for :
>
> KeyPress event, serial 40, synthetic NO, window 0x81,
> root 0xdb, subw 0x0, time 68201, (-1603,615), root:(217,676),
> state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES,
> XLookupString gives 2 bytes: (c2 b4) "´"
> XmbLookupString gives 0 bytes:
> XFilterEvent returns: True
>
> KeyRelease event, serial 40, synthetic NO, window 0x81,
> root 0xdb, subw 0x0, time 68270, (-1603,615), root:(217,676),
> state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES,
> XLookupString gives 2 bytes: (c2 b4) "´"
> XFilterEvent returns: False
>
> KeyPress event, serial 40, synthetic NO, window 0x81,
> root 0xdb, subw 0x0, time 70041, (-1603,615), root:(217,676),
> state 0x0, keycode 26 (keysym 0x65, e), same_screen YES,
> XLookupString gives 1 bytes: (65) "e"
> XmbLookupString gives 1 bytes: (65) "e"
> XFilterEvent returns: True
>
> KeyPress event, serial 40, synthetic NO, window 0x81,
> root 0xdb, subw 0x0, time 70041, (-1603,615), root:(217,676),
> state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES,
> XLookupString gives 0 bytes:
> XmbLookupString gives 2 bytes: (c3 a9) "é"
> XFilterEvent returns: False
>
> KeyRelease event, serial 40, synthetic NO, window 0x81,
> root 0xdb, subw 0x0, time 70098, (-1603,615), root:(217,676),
> state 0x0, keycode 26 (keysym 0x65, e), same_screen YES,
> XLookupString gives 1 bytes: (65) "e"
> XFilterEvent returns: False
>
> (note how there's an extra KeyPress I had never noticed before)
For future reference, here's what I see under normal conditions when I press
AltGr+e e
KeyPress event, serial 40, synthetic NO, window 0x7a1,
root 0xf6, subw 0x0, time 120475392, (99,141), root:(101,193),
state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x7a1,
root 0xf6, subw 0x0, time 120475718, (99,141), root:(101,193),
state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES,
XLookupString gives 2 bytes: (c2 b4) "´"
XmbLookupString gives 0 bytes:
XFilterEvent returns: True
KeyRelease event, serial 40, synthetic NO, window 0x7a1,
root 0xf6, subw 0x0, time 120475844, (99,141), root:(101,193),
state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES,
XLookupString gives 2 bytes: (c2 b4) "´"
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x7a1,
root 0xf6, subw 0x0, time 120476114, (99,141), root:(101,193),
state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x7a1,
root 0xf6, subw 0x0, time 120476349, (99,141), root:(101,193),
state 0x0, keycode 26 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XmbLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: True
KeyPress event, serial 40, synthetic NO, window 0x7a1,
root 0xf6, subw 0x0, time 120476349, (99,141), root:(101,193),
state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES,
XKeysymToKeycode returns keycode: 11
XLookupString gives 0 bytes:
XmbLookupString gives 2 bytes: (c3 a9) "é"
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x7a1,
root 0xf6, subw 0x0, time 120476443, (99,141), root:(101,193),
state 0x0, keycode 26 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: False
The dead_acute is there twice; I see it appearing only once when I manage to
press the AltGr and e keys sufficiently simultaneously.
With qev/Qt 5.8 I see this:
qt.qpa.input.methods: filterEventFinished return 108 65027 0 false
QKeyEvent(ShortcutOverride, Key_AltGr, GroupSwitchModifier)
QKeyEvent(KeyPress, Key_AltGr, GroupSwitchModifier)
qt.qpa.input.methods: filterEventFinished return 26 65105 128 true
qt.qpa.input.methods: filterEventFinished return 26 65105 128 false
QKeyEvent(KeyRelease, Key_Dead_Acute, GroupSwitchModifier)
qt.qpa.input.methods: filterEventFinished return 108 65027 128 false
QKeyEvent(KeyRelease, Key_AltGr)
qt.qpa.input.methods.serialize: QIBusText::fromDBusArgument() "(sa{sv}sv)"
qt.qpa.input.methods.serialize: QIBusAttributeList::fromDBusArgument()
"(sa{sv}av)"
QInputMethodEvent(, commit="U+e9")
qt.qpa.input.methods: filterEventFinished return 26 101 0 true
qt.qpa.input.methods: filterEventFinished return 26 101 0 false
QKeyEvent(KeyRelease, Key_E, text="e")
And with qev/4.8.7 (is there any way to get the equivalent of qInfo there?)
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole)
Thiago Macieira wrote: > That's called qev and you can find in qttools/src/qev. It's not built by > default. > But I really meant xev. I just want to know if xev receives any extra events > in there. In fact, couldn't qev include xev functionality in a native event filter? R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working)
On Friday June 09 2017 12:51:37 Allan Sandfeld Jensen wrote: > > Wow, at least now I know "it's not just me" ... What DE are you using? > > > I am running Plasma Same here, but Plasma4. > Note application launched via the gui are still affected becaues they are > forked from an already running launcher. To fully start a new Qt application > in KDE you need to launch it from a terminal. Even a KDE terminal? :) That's what I do most of the time anyway, much faster in 99% of the cases :) Thiago Macieira wrote: >> So what I'd need at least for comparison is a Qt equivalent of xev > > That's called qev and you can find in qttools/src/qev. > > But I really meant xev. I just want to know if xev receives any extra events > in there. OK, will try both then. R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working)
On Donnerstag, 8. Juni 2017 16:04:19 CEST René J.V. Bertin wrote: > On Thursday June 08 2017 15:43:07 Allan Sandfeld Jensen wrote: > > I just ran into the same thing today not an hour ago. No idea what > > triggered it, but I haven't seen it before. I solved it by starting ibus, > > but I guess that just adds another layer of interpretting keys. Also > > newly started qt5 applications had working dead-keys too, it was just all > > running qt5 applications that broke. > > Wow, at least now I know "it's not just me" ... What DE are you using? > I am running Plasma > I installed ibus a while back to have another mechanism for swapping and > restoring keyboard layouts. Hasn't helped me at all until now (and it's > been running ever since I installed it). > > Next time I'll see if newly started Qt applications are still affected. I > think I must already have tried restarting the application I get this most > often in (KDE4/Qt4 based KMail) without much success. Maybe you ran into > the version that can be cured by cycling keyboard layouts. > Note application launched via the gui are still affected becaues they are forked from an already running launcher. To fully start a new Qt application in KDE you need to launch it from a terminal. 'Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole)
On Thursday, 8 June 2017 13:15:26 PDT René J. V. Bertin wrote: > I'll try that, but chances are that won't teach me anything. As I said in my > OP, this never affects non-Qt applications like for instance Google Chrome. > The fact affects both Qt4 (4.8.7) and Qt5 apps seems like a huge > coincidence, unless they share the same basic X event handling. It's somewhat a coincidence, because the code was completely rewritten between Qt 4 and 5. However, the people who wrote it inspired themselves on the older Qt 4 code. > So what I'd need at least for comparison is a Qt equivalent of xev That's called qev and you can find in qttools/src/qev. It's not built by default. But I really meant xev. I just want to know if xev receives any extra events in there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole)
Thiago Macieira wrote: > Try using xev and see if any events are sent between the deadkey and the key. I'll try that, but chances are that won't teach me anything. As I said in my OP, this never affects non-Qt applications like for instance Google Chrome. The fact affects both Qt4 (4.8.7) and Qt5 apps seems like a huge coincidence, unless they share the same basic X event handling. So what I'd need at least for comparison is a Qt equivalent of xev :) > Here's my output for : > > KeyPress event, serial 40, synthetic NO, window 0x81, ... > KeyRelease event, serial 40, synthetic NO, window 0x81, > root 0xdb, subw 0x0, time 68270, (-1603,615), root:(217,676), > state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, > XLookupString gives 2 bytes: (c2 b4) "´" > XFilterEvent returns: False > > KeyPress event, serial 40, synthetic NO, window 0x81, ... > state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, ... > KeyPress event, serial 40, synthetic NO, window 0x81, > root 0xdb, subw 0x0, time 70041, (-1603,615), root:(217,676), > state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 2 bytes: (c3 a9) "é" > XFilterEvent returns: False > > KeyRelease event, serial 40, synthetic NO, window 0x81, > root 0xdb, subw 0x0, time 70098, (-1603,615), root:(217,676), > state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, > XLookupString gives 1 bytes: (65) "e" > XFilterEvent returns: False > > (note how there's an extra KeyPress I had never noticed before) You mean the actual 'é' keypress in between the 'e' key press and key release? The sequence appears surprising indeed, apparently clients must decide for themselves which events to filter and which to heed, whether they want to treat the deadkey event + keypress themselves or just get the preprocessed keypress. > R ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole)
On quinta-feira, 8 de junho de 2017 06:23:48 PDT René J. V. Bertin wrote: > > If some > > other application is playing tricks with your keyboard, it will affect the > > deadkeys. > > I guess it'll be very nontrivial figuring out who might be responsible? Try using xev and see if any events are sent between the deadkey and the key. Here's my output for : KeyPress event, serial 40, synthetic NO, window 0x81, root 0xdb, subw 0x0, time 68201, (-1603,615), root:(217,676), state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 40, synthetic NO, window 0x81, root 0xdb, subw 0x0, time 68270, (-1603,615), root:(217,676), state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x81, root 0xdb, subw 0x0, time 70041, (-1603,615), root:(217,676), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 40, synthetic NO, window 0x81, root 0xdb, subw 0x0, time 70041, (-1603,615), root:(217,676), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x81, root 0xdb, subw 0x0, time 70098, (-1603,615), root:(217,676), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False (note how there's an extra KeyPress I had never noticed before) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working)
On Thursday June 08 2017 15:43:07 Allan Sandfeld Jensen wrote: > I just ran into the same thing today not an hour ago. No idea what triggered > it, but I haven't seen it before. I solved it by starting ibus, but I guess > that just adds another layer of interpretting keys. Also newly started qt5 > applications had working dead-keys too, it was just all running qt5 > applications that broke. Wow, at least now I know "it's not just me" ... What DE are you using? I installed ibus a while back to have another mechanism for swapping and restoring keyboard layouts. Hasn't helped me at all until now (and it's been running ever since I installed it). Next time I'll see if newly started Qt applications are still affected. I think I must already have tried restarting the application I get this most often in (KDE4/Qt4 based KMail) without much success. Maybe you ran into the version that can be cured by cycling keyboard layouts. R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working)
On Samstag, 3. Jun 2017 10:11:01 CEST René J.V. Bertin wrote: > Hi, > > I use the "English (Macintosh)" keyboard variant with the standard "English > (US)" layout. Like on Mac, this gives me accented characters via deadkeys > that associate the most common occurrences: AltGr+e is the deadkey for > e-acute, AltGr+i the deadkey for i-circonflex etc. > > At random intervals I lose the deadkey aspect in the sense that in Qt4 > applications, AltGr+e will insert the acute on itself (idem for the other > combinations) and Qt5 applications the deadkey does nothing at all. IOW, in > Qt4 apps I get the accent followed by the to-be-accented letter (´e) while > in Qt5 I just get the letter without the accent. > I just ran into the same thing today not an hour ago. No idea what triggered it, but I haven't seen it before. I solved it by starting ibus, but I guess that just adds another layer of interpretting keys. Also newly started qt5 applications had working dead-keys too, it was just all running qt5 applications that broke. 'Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole)
Thiago Macieira wrote: > Just to provide a different viewpoint: I've only ever used "English (Alt > International)" for the last, oh, 20 years, and I haven't had deadkey problems > in the last 3. I've been using the "English (Macintosh)" layout for a bit over 3 years now, without any issue until I upgraded my hardware a year ago. I don't see how that would be related, but as far as I can tell this still doesn't happen on the old computer. > What you're describing isn't exactly a Qt problem, but must be caused by some > other application. Do you have an idea why only Qt applications would be affected? > The deadkeys lose their state if certain (keyboard) events > get sent to the application between the deadkey and the modified key. I've suspected KDE's kglobalacceld but restarting that one doesn't make any difference. The only other global interference I can think of would come from the screensaver, possibly through the X server itself. I *think* the deadkey issue only happens after the screensaver has kicked in but am not 100% certain. Anyway, changing the screensaving engine from the one in KWin to xscreensaver didn't > If some > other application is playing tricks with your keyboard, it will affect the > deadkeys. I guess it'll be very nontrivial figuring out who might be responsible? FWIW, I have another keyboard issue which I realise could somehow be related because it too never occurred on my old notebook. It affects Konsole only, both the Qt4 and Qt5 versions. In this case I lose keyboard input completely (the paste menu action continues to work). That's either in a single tab or application wide; in the former case I can usually just clone the tab and keep working, in the latter case I have to restart the entire application. And this issue can strike at any moment; I've never been able to reproduce it at will or even figure out a pattern in what I was doing when it triggered. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/XCB applications and deadkeys (which cease working)
On Saturday, 3 June 2017 01:11:01 PDT René J.V. Bertin wrote: > I use the "English (Macintosh)" keyboard variant with the standard "English > (US)" layout. Like on Mac, this gives me accented characters via deadkeys > that associate the most common occurrences: AltGr+e is the deadkey for > e-acute, AltGr+i the deadkey for i-circonflex etc. > > At random intervals I lose the deadkey aspect in the sense that in Qt4 > applications, AltGr+e will insert the acute on itself (idem for the other > combinations) and Qt5 applications the deadkey does nothing at all. IOW, in > Qt4 apps I get the accent followed by the to-be-accented letter (´e) while > in Qt5 I just get the letter without the accent. Just to provide a different viewpoint: I've only ever used "English (Alt International)" for the last, oh, 20 years, and I haven't had deadkey problems in the last 3. There was some problem in some early versions of Qt 5 because of the XCB rewrite, along with problems with the compose map, but they haven't shown up in years. I have never had problems with Qt 4. What you're describing isn't exactly a Qt problem, but must be caused by some other application. The deadkeys lose their state if certain (keyboard) events get sent to the application between the deadkey and the modified key. If some other application is playing tricks with your keyboard, it will affect the deadkeys. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
