Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-15833

Qt:KeypadModifier is sent delayed within QKeyEvents on Embedded Linux (QWS)

    XMLWordPrintable

Details

    • Bug
    • Resolution: Incomplete
    • P3: Somewhat important
    • None
    • 4.5.2
    • None
    • Qt for Embedded Linux, Qt 4.5.2, Linux kernel 2.6.31
      Qt for Embedded Linux, Qt 4.7.1, Linux kernel 2.6.28

    Description

      When pressing keys on the keypad part of the keyboard, the Qt:KeypadModifier is sent delayed within QKeyEvents on Embedded Linux (QWS).

      When receiving the KeyPress event, Qt:KeypadModifier is not set in the modifier flags. When receiving the KeyRelease event, Qt:KeypadModifier is correctly set in the modifier flags. Unfortunately the next KeyPress event does also contain the Qt:KeypadModifier, even if the key is not on the keypad.

      Example:
      Assume you press the 'Plus' key on the keypad, and after that you press the 'T' key. A widget will receive the following QKeyEvents.

      QEvent::KeyPress:   Key_Plus, Modifier: Qt::NoModifier
      QEvent::KeyRelease: Key_Plus, Modifier: Qt::KeypadModifier
      QEvent::KeyPress:   Key_T,    Modifier: Qt::KeypadModifier
      QEvent::KeyRelease: Key_T,    Modifier: Qt::NoModifier
      

      The correct sequence would be:

      QEvent::KeyPress:   Key_Plus, Modifier: Qt::KeypadModifier
      QEvent::KeyRelease: Key_Plus, Modifier: Qt::KeypadModifier
      QEvent::KeyPress:   Key_T,    Modifier: Qt::NoModifier
      QEvent::KeyRelease: Key_T,    Modifier: Qt::NoModifier
      

      I think we have found the cause of this issue in QETWidget::translateKeyEvent(). Instead of using the current modifiers delivered by QWSKeyEvent a previous state of these flags will be used and the current modifiers will be saved for the next event to be translated.
      This may be correct for modifiers activated by keys (ALT, SHIFT, CTRL), because pressing ALT, SHIFT, CTRL creates a separate QKeyEvent, but it is not correct for the keypad modifier.

      Additional Information:
      The same effect can be noticed when extending QKbdDriverPlugin to create a custom keypad handler and call processKeyEvent with a modifier. I have tested this with Qt::ShiftModifier, Qt::AltModifier, Qt::KeypadModifier, Qt::GroupSwitchModifier and get the same result as described above where the keypress after the one specified receives the modifier rather then the desired keypress. While this can be worked around by sending "Dummy Keypresses" before and after to set the modifier this is less then ideal.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            Unassigned Unassigned
            marioroessel Mario Rössel
            Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes