QtForum.org

Hi to everyone.

Here my problem:
I have to develop a GUI app on a board (ARM based) with no keyboard and no touchscreen.
The only interaction is provided throug a joystik (five buttons: up, down, left, right, select) and other eight soft keys.
The problem is how make the Qt app aware of the events generated by the keys.

I've made a search on the forum and on the site doc, but didn't found anything of help.

I've be very glad if someone could point me to interesting resources about this topic, or would directly suggest a track of solution.

Thank you very much!


Ste.

My fault, sorry, I forgot it.
I'm using Qt/Embedded version 3.3.5.

Regarding the keys, here what I have discovered so far:

About the file /src/kernel/qkeyboard_qws.cpp, I have read of it in the doc file: 'character input in Qt/Embedded'.
The problem is that such file is missing. At his place I find instead the header file 'qkeyboard_qws.h'.

In the same directory I've found the file 'qvr41xxkeyboard.cpp' that, following the above article, is one of the default keyboard driver utilized by 'qkeyboard_qws.h'.

Then I see in the config options the following:


-qt-kbd-<driver> ... Enable a keyboard <driver> in the Qt Library
...
Possible values for <driver>: [ sl5000 tty usb yopy vr41xx ]


In the kernel on the board there is a driver for the management of the buttons, and there is the file /dev/buttons in the filesystem, all correctly configured.

I suppose there is all the necessary for enabling the key functionality that I need, the problem is that I can't see how to combine them.......

Bye!


Ste

Hi to everyone.

Here some news about this topic:

The file qkeyboard_qws.cpp mentioned in the doc file 'character input in Qt/Embedded' is not in the specified directory because it doesn't exist no longer.
The above file is relative to Qt 2.3, and I believe things are a little changed since there.

In version 3.3.5 everything regarding key(board) management is in QTDIR/src/embedded.

What I'm trying to do now is modify the driver for the cassiopeia device (qkbdvr41xx), adding some function key, and recompile everything with the config option

-qt-kbd_vr41xx'

Is it right to believe that code lines like:

case 0x11:
keycode = Qt::Key_Up;
break;

define events (Key_Up) that are received and processed directly by Qt widgets?

Bye!

Ste

Hi to everyone.

The procedure described in my previous post didn't work.
I also changed in the code the device responsible of the buttons, and tried exporting QWS_KEYBOARD=wr41xx:/dev/buttons,
but nothing appens.

I've no more ideas.
Some hints?

Bye

Ste

Hi guys!

Here the latest news about this topic:

I've found the mechanism keyboard driver are generated in Qt.

From the file 'qwindowsystem_qws' the env variable QWS_KEYBOARD is readed and parsed, the 'driver' kind and related 'device' are recognized. These variables are passed as argument to a function of the file 'qkbddriverfactory_qws' that, in a later time, create the driver for the specified argument he received.
In my case the QWSVr41xxKeyboardHandler is activated (the file is 'qkbdvr41xx_qws').

In the latter a QSocketNotifier::read is somehow activated on the 'device' of interest.
When the socketnotifier fire an event 'activated(int)' the procedure for reading the keyboard data is started (readKeyboardData()). readKeyboardData() is the code I've adapted for my board's keys.

Well, after a little of debugging I've discovered that the function readKeyboardData is never activated.
At the moment I can't say why.

I've tried changing the R/W permission on the device with no results.

If you have a possible idea of solution, make me know, please
(otherwise say a prey for me....)

'bye

Ste

Ok, here some news for those of you that are interested in this topic:

I've solved at least a part of the problem.
The fact is: tle 'qkbdvr41xx_qws' driver, like the other keyboard driver, has this snippet of code thet controls the events generated from a socket bound to the device that controls the buttons:

connect( notifier, SIGNAL(activated(int)),this,
SLOT(readKeyboardData()) );
//readKeyboardData();
}

When the QSocketNotifier 'notifier' fire the event 'activated' the function 'readKeyboardData' is launched.
this action have to occure in a separate thread respect of the main program thread and, by default, thread support is not enabled in Qt/Embedded.

So I recompiled everithing with thread support and tried again.

This time thigs works: the function 'readKeyboardData' is launched.... too many times!

It seems that the event 'activated' of the notifier is continously launched, even if I don't touch any button.

God know how much time I'll need to discover why.
(And I have to make it work for.... yesterday!)

Have a nice day.

Ste

Looking at the number of persons that have looked at this thread I imagine that this is an argument of interest.

So I'm quite proud to announce that I've finally solved the problem!
Or at least I've found a partial solution, not very elegant, but that works fine enough for my purposes. (I still have to refine it).

1) My device has a different mechanism for buttons events handling respect to the one of the device the driver 'qkbdvr41xx_qws' was designed for. This of course didn't work.
So I changed completely that part of code, the function 'readKeyboardData', accordling to the indication that the developers of the device have got me. I can't publish it in detail, I can only say that it is a while cycle that run continuosly listening the events that occures.

2) when I tried to run this new 'readKeyboardData' function, well, keys were detected, but the endless cycle blocked the rest of the application! So I've spent unsuccessfully the days of saturday and sunday trying to make start a new thread in 'qkbdvr41xx_qws'. I must admit that I'm quite a newbie for what regards C++ programming.

3) today I've found the solution: I've transformed the endless cycle in a normal one, then I've connected the 'readKeyboardData' slot to the notifier signals I told you last time.
The notifier continuosly fire events, the cycle is continuosly run and key events are detected.

That's all.
It works fine quite all the time.

I think this will be the last post about this topic so, for the moment, goodbye.
(now I'll start to develop the real Qt application, so likely I'll need again the support of this group).

Regards,
Ste