0

I have an embedded Qt application crosscompiled that runs on BeagleBone Black. It works OK, but one thing - it doesn't accept keyboard input if I won't run in directly on BeagleBone Black preceding with sudo. This is a problem because:

  • I cannot remote debug application and use connected keyboard, as it doesn't work,
  • I cannot use keyboard when the app is in rc.local file to boot at startup (even though sudo is used there).

What can I try next?

My /etc/enviroment content is here:

QWS_MOUSE_PROTO=IntelliMouse:/dev/input/mouse0
QWS_KEYBOARD=LinuxInput:/dev/tty
TSLIB_CONFFILE=/etc/ts.conf
TSLIB_PLUGINDIR=/usr/lib/ts

Although I have tried many different configurations for QWS_KEYBOARD. The keyboard I would like to use is /dev/input/event1.

halfer
  • 19,824
  • 17
  • 99
  • 186
Łukasz Przeniosło
  • 2,725
  • 5
  • 38
  • 74
  • Check permissions on /dev/input/event1 then? – Hamish Moffatt Jul 02 '15 at 01:18
  • `crwxrwxrwx 1 root root 13, 65 Mar 1 21:45 event1` – Łukasz Przeniosło Jul 02 '15 at 06:35
  • You need a debug build of Qt, and you need to trace into the platform code to figure out why the keyboard access fails. It's possibly a very simple problem to fix. I don't understand why remote debugging won't work if the keyboard doesn't work. You control the debugger from your host, not from the target. – Kuba hasn't forgotten Monica Jul 02 '15 at 17:46
  • Thats not what I meant. The keyboard works only if i run the app on the board typing in `sudo ./myapp -qws`. They keyboard doesnt work if I remote debug or run the same line using ssh from remote pc. I can press the keyboard keys but they are not registered in the app, but go behind the app to the console (there is no x server). I have no idea how to fix this. The biggest problem is that when i run the app from `rc.local' using `sudo ./myapp -qws` the keyboard doesnt work as well... How can i degug keyboard input if the app doesnt see it? – Łukasz Przeniosło Jul 02 '15 at 17:56
  • I'd run strace on myapp and see what it's doing with /dev/input/event1 then. – Hamish Moffatt Jul 03 '15 at 07:14
  • `/dev/input/event1` is responsive 100%, because I have tested it with tools from `#include`. The problem is the Qt doesnt see the events, for example `QFileSystemWatcher` doesnt detect changes on `/dev/input/event1` – Łukasz Przeniosło Jul 03 '15 at 07:16
  • You can run other apps using that device as a non-root user? – Hamish Moffatt Jul 06 '15 at 00:22
  • Its not abot being or not being root- if i werent root the qt app wouldnt even start. So when i run it, i am root. But for some reason i cant use the keyboard if not executed directly and not via rc script. – Łukasz Przeniosło Jul 06 '15 at 04:34
  • Did you solve this problem? – Ondrej Bozek Oct 27 '16 at 15:26
  • @OndrejBozek Hi. No I did not, I had to implement a c style keyboard watcher in order to capture the key events. Soon I will be trying Qt 5.7 on Raspberry Pi with simmilar approach ( https://wiki.qt.io/RaspberryPi2EGLFS ). I hope not to face this problem again. – Łukasz Przeniosło Oct 27 '16 at 15:30
  • I face this problem after update of KDE plasma 5.6 -> 5.7. Cant' fix it – Ondrej Bozek Oct 28 '16 at 10:02

1 Answers1

0

I also facing this issue. But in my situation, I use remote desktop from Windows OS to raspberry / beaglebone.

My solution (make sure at least you know how to configure ssh in raspberry) :

  1. install xrdp (sudo apt-get install xrdp) on raspberry / beaglebone / other embedded linux
  2. in PC instal xming (search sourceforge)
  3. open XLaunch, select multiple windows > start no client > clipboard > finish
  4. open putty >> session, enter host name / IP address, putty >> SSH >> X11 >> check 'Enable X11 forwarding' putty >> click Open button
  5. login ssh and then type qcreator

now the keyboard should be fine

yp25
  • 11
  • 4
  • 1
    This doesnt solve the issue completly, as one has to transfer X over to the host and still cannot use it at the target when debuging. ALso I think you are running qt creator on the target.... – Łukasz Przeniosło May 03 '16 at 08:28