Lost keyboard control when qt application starts on non-X11 system
Hello
We have a strange problem when a qt application is being started, and I am not sure if this is the right Topic to post and describe the problem, it might also be an issue depending regarding the underlaying linux system (minimalistic debian installation). We are running the embedded version on a x86 system running without any X11 environment.
Lets describe the problem:
In general: we have 5 tty’s running:
root 1272 1 0 10:53 tty1 00:00:00 /sbin/getty 38400 tty1
root 1273 1 0 10:53 tty2 00:00:00 /sbin/getty 38400 tty2
root 1274 1 0 10:53 tty3 00:00:00 /sbin/getty 38400 tty3
root 1275 1 0 10:53 tty4 00:00:00 /sbin/getty 38400 tty4
root 1276 1 0 10:53 tty5 00:00:00 /sbin/getty 38400 tty5
and console is set in grub to:
kernel /boot/vmlinuz-2.6.32-5-686 root=/dev/sda1 vga=0×318 console=tty6
I am able to switch console using a wired usb keyboard by pressing alt-<fX> keys if no qt application is started. But when I start the application, for example the textedit demo application (eighter with or without specifying the QWS_KEYBOARD environment) I lost the control over the keyboard and switching to another console, e.g. for a login, is impossible. This also happens i different types of options given, for example:
QWS_KEYBOARD=linuxinput QWS_MOUSE_PROTO=“Tslib:/dev/input/event4” ./textedit -qws -display “:1”
QWS_KEYBOARD=TTY:/dev/tty1 QWS_MOUSE_PROTO=“Tslib:/dev/input/event4” ./textedit -qws -display “:0”
What am I doing wrong? As far as I can see the qt application ‘takes’ the /dev/pts/0 device
root@sidv50-10-10:~# ls -l /proc/1367/fd
total 0
lrwx——— 1 root root 64 May 5 11:13 0 -> /dev/pts/0
lrwx——— 1 root root 64 May 5 11:13 1 -> /dev/pts/0
l-wx——— 1 root root 64 May 5 11:13 10 -> /proc/mtrr
lr-x——— 1 root root 64 May 5 11:13 11 -> /dev/input/event4
lrwx——— 1 root root 64 May 5 11:13 12 -> /dev/tty1
lrwx——— 1 root root 64 May 5 11:13 13 -> socket:4479
lrwx——— 1 root root 64 May 5 11:13 14 -> /tmp/qtembedded-1/fonts/_12_50.qsf
lrwx——— 1 root root 64 May 5 11:13 15 -> /tmp/qtembedded-1/fonts/_20_75.qsf
lrwx——— 1 root root 64 May 5 11:13 16 -> /tmp/qtembedded-1/fonts/_11_50.qsf
lrwx——— 1 root root 64 May 5 11:13 17 -> /tmp/qtembedded-1/fonts/_11_50_italic.qsf
lrwx——— 1 root root 64 May 5 11:13 18 -> /tmp/qtembedded-1/fonts/_16_75.qsf
lrwx——— 1 root root 64 May 5 11:13 19 -> /tmp/qtembedded-1/fonts/_11_75.qsf
lrwx——— 1 root root 64 May 5 11:13 2 -> /dev/pts/0
lrwx——— 1 root root 64 May 5 11:13 20 -> /tmp/qtembedded-1/fonts/_9_50.qsf
lrwx——— 1 root root 64 May 5 11:13 21 -> /tmp/qtembedded-1/fonts/_9_75.qsf
lrwx——— 1 root root 64 May 5 11:13 22 -> /tmp/qtembedded-1/fonts/_9_50_italic.qsf
lrwx——— 1 root root 64 May 5 11:13 23 -> /tmp/qtembedded-1/fonts/_12_75.qsf
lr-x——— 1 root root 64 May 5 11:13 3 -> pipe:4472
l-wx——— 1 root root 64 May 5 11:13 4 -> pipe:4472
lr-x——— 1 root root 64 May 5 11:13 5 -> pipe:4475
l-wx——— 1 root root 64 May 5 11:13 6 -> pipe:4475
lrwx——— 1 root root 64 May 5 11:13 7 -> socket:4476
lrwx——— 1 root root 64 May 5 11:13 8 -> /dev/fb0
lrwx——— 1 root root 64 May 5 11:13 9 -> /dev/tty0
5 replies
./configure \ -prefix ../staging/usr \ -nomake tools \ -nomake examples \ -nomake demos \ -nomake docs \ -nomake translations \ -qt-gfx-transformed \ -qt-gfx-vnc \ -no-xcursor \ -embedded x86 -exceptions \ -little-endian \ -depths 16,24,32 \ \ -platform qws/linux-x86-g++ \ \ -no-openssl \ -no-cups \ -no-largefile \ -L../staging/usr/lib \ -I../staging/usr/include \ -qt-mouse-tslib \ -host-little-endian \ -qt-zlib \ -opensource \ -confirm-license \ -v
After days of testing, I finally found a solution. The way to solve this problem is simply to use DirectFB instead of LinuxFb on the target, so all ctr-alt-<nr> keypresses on the attached usb keyboard are recognized and it’s possible to switch to a console after the application has been started, great :)
You must log in to post a reply. Not a member yet? Register here!

