Nominate our 2022 Qt Champions!

[SOLVED] Help! Keystrokes printing over Qt application

  • Hi Everyone,

    This question might end up being a generic linux input question, but it does involve Qt so hopefully someone can help!

    I'm working with a Qt embedded application running on qt-embedded-free-3.3.4 with the linux kernel 2.6.29. I built Qt with the USB keyboard driver and have set the env variable QWS_KEYBOARD appropriately. The Qt application receives the keyboard input 100%.

    The problem I'm seeing is that all keyboard input is still printing to the screen, similar to if there was a console command line behind the Qt graphics. The text is being printed on top of the Qt application. If there is enough text to reach a Qt graphics object, the object will re-cover the text when it is re-drawn. I've attached a picture of the display (the undesirable text printing over the Qt graphic).

    I'm struggling to find a way to suppress the text from printing. The Qt application is launched from the /etc/inittab via a script:

    The script contents:

    sleep 1
    export QWS_MOUSE_PROTO=None
    export QWS_KEYBOARD=USB:/dev/input/event0
    export QTDIR=/usr/qt/qt-embedded-free-3.3.4
    /home/root/app/detector/detector -d "/dev/ttyS0" &
    sleep 1
    /home/root/app/client/client -qws

    I've tried adding "stty -echo" in an attempt to suppress the printing of the text to the terminal.
    I've tried adding "> /dev/null 2>&1 0>&1" after both application initializations in an attempt to redirect outputs away from the terminal.

    If anyone has any ideas or solutions(!), I would really appreciate the response!


    Edit: Remember QT is QuickTime, use Qt.

  • Does it still happen if the Qt app is the only one running? ie if you do not syart the detector app

  • Thanks for the reply!

    Unfortunately, it does still happen when the "detector" app is removed.

    I've since tried using busybox's sh instead of bash. (same results)
    I've tried using ash instead of bash. (same results)

    If the system is brought up without the Qt app ("client"), the display shows blank (black) and no keystrokes are printed to the screen.

    I did find a half-solution. I've been using Qt's built-in USB keyboard driver. It functions perfectly, with the exception of this background text printing issue.

    I rebuilt Qt to include the TTY keyboard driver. The text printing issue is gone. However, presses of the arrow keys are not seen by the Qt app. The use of the arrow keys is required for my application, so I need to keep hacking at it.

    For kicks and grins, I'm going to rebuilt Qt with all the support keyboard drivers and try each one.

    Any other ideas or suggestions are quite welcome!


  • Options I see are:

    Compare the tty and usb keyboard drivers to see if you can spot how the tty stops the echo to the console or how the usb causes it (maybe some debug code left in?)

    Upgrade to Qt 4.7.2 and try that - although this will require some modification of your application code. It will likely be worth it though 3.3.4 is very old ;-)

  • I'm fairly certain I'm on the home stretch for getting the 3.3.4 libraries running, but if I encounter more issues, the cycles for updating the application to work with Qt 4.7.x might indeed be worth it!

    This gets the TTY driver to support the Arrow Keys (no background text printing).

    My solution is to modify the TTY driver (qt-embedded-free-3.3.4/src/embedded/qkbdtty_qws.cpp) to directly process the keycodes for KEY_(UP|DOWN|LEFT|RIGHT) as mapped in (/qt-embedded-free-3.3.4/src/kernel/qnamespace.h) and used by the Qt::Event objects (/qt-embedded-free-3.3.4/src/kernel/qevent.h).

    Both the USB and the TTY driver utilize the QWSPC101KeyboardHandler->doKey function (from qt-embedded-free-3.3.4/src/embedded/qkbdpc101_qws.cpp) to deal with mapping the keycode to Qt::Key objects. The doKey function has conditionals to deal with "extended" character sets, which include the arrow keys. The extended flag is broken for some reason (it bases "extended=true" on seeing keycode="224"). After determining the correct Qt::Key object, the QWSPC101KeyboardHandler->doKey function calls a kernel level function "processKeyEvent" (from qt-embedded-free-3.3.4/src/kernel/qwindowsystem_qws.cpp). My solution is to bypass all the doKey conditionals for the extended keycodes I wish to support. Here is the diff:

    @root@overo:/usr/qt/qt-embedded-free-3.3.4/src/embedded# diff qkbdtty_qws.cpp.backup qkbdtty_qws.cpp
    < for ( int loop = 0; loop < n; loop++ )
    < handler->doKey(buf[loop]);

    for ( int loop = 0; loop < n; loop++ )
       if(buf[loop] == 103){
       else if(buf[loop] == 106){
       else if(buf[loop] == 108){
       else if(buf[loop] == 105){
       else { handler->doKey(buf[loop]); }


    This kinda gets the USB Driver to stop painting text over the Qt graphic

    I tried using the global qwsServer->enablePainting function to disable painting of the Qt window when a keypress was received. This has marginal success. I stuck the code at the beginning/end of the QWSUsbKbPrivate::readKeyboardData function in the USB driver file (qt-embedded-free-3.3.4/src/embedded/from qkbdusb_qws.cpp). The result is that the typed letter will print and be display momentarily, but the Qt graphic will repaint almost instantly and hide the text. Obviously this approach can work, but it needs to be placed in the code that first parses the external keyboard input event. I have a solution with the TTY driver, so I'm not going to bother hunting this one down, but here's the hack for the marginal solution for anyone forced down that path :)

    root@overo:/usr/qt/qt-embedded-free-3.3.4/src/embedded# diff qkbdusb_qws.cpp.backup qkbdusb_qws.cpp





Log in to reply