Skip to main content

Linux/i386 with native Qt.

19 replies [Last post]
ramon_garcia
Offline
Joined: 2006-11-22
Points: 0

Is this compilation posible using the configuration linux_i386_qte? Otherwise, what are the best options for compiling an emulator that allows one to test J2ME applicatins?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
calvrack
Offline
Joined: 2007-02-18
Points: 0

> With qvfb my (usb) keyboard is working but sending
> each key twice :(, making it impossible to use.

Hello, if it could help you (or anyone else reading this topic), seems like the problem comes from the incompatibilty of types in different versions of the QT. Still the issue could be fixed (at least in MR2) by changing the qvfb_handle_input.c:97

from

struct QVFbKeyEvent {
unsigned int unicode;
unsigned int modifiers;
int press;
int repeat;
} qvfbKeyEvent;

to

struct QVFbKeyEvent {
unsigned int unicode;
unsigned int modifiers;
char press;
char repeat;
} qvfbKeyEvent;

strim
Offline
Joined: 2006-10-20
Points: 0

Hi Selenau,

> I built PCSL with "make NETWORK_MODULE=bsd/generic".
> It works. Maybe It is related, because default is
> bsd/qte...

bsd/qte is the only working for linx_qte
bsd/generic is the only matching to linux_fb

the mismatching will lead either to compilation errors with clean build, or to not working
networking in runtime in the case of dirty builds.

> With qvfb my (usb) keyboard is working but sending
> each key twice :(, making it impossible to use.

What the configuration do you mean, linux_qte or linux_fb?

> ps: Could someone please show the way of porting
> input handling in midp? porting fb is easy but, I'm
> not feel same about keyboard handling.

I'll try to help you, but please give me a bit more details on your trouble/configuration.
In qte and fb the keys handling is quite different. In qte the key events are going from
Qt libraries, in fb the input is read directly from keyboard device.

--
Regards,
Strim

selenau
Offline
Joined: 2006-10-11
Points: 0

My configuration is linux_fb.

I'm playing on file :
midp/src/events/mastermode_port/linux_fb/native/mastermode_handle_signal.c

I want to understand responsibility of :
void handleKey(MidpReentryData* pNewSignal, MidpEvent* pNewMidpEvent)

strim
Offline
Joined: 2006-10-20
Points: 0

Okay,

void handleKey(MidpReentryData* pNewSignal, MidpEvent* pNewMidpEvent)

The function is responsible for reading keyboard event from input device (keypad, tty etc.) and converting it to MIDP internal event, e.g. switching MIDlet task to foreground or background, or just simple text input event.

Current implementation is complicated with macro branching, we plan to decouple it properly in MR2. However, now you can see handleKey versions for ARM/fb and i386/qvfb.

The function reads keyboard event from keyboard file descriptor. In QVFb version the data been read is interpreted as a single keycode, so depending on this keycode the MIDP event instance pNewMidpEvent is filled. Also pNewMidpEvent structure is filled with new coming signal type, e.g. AMS_SIGNAL. Using signal type the upper level function midp_check_events(..) will unblock Java treads waiting for certain signals on a certain descriptors.

Please see for midp_check_events() implementation here:
src/events/eventsystem/mastermode/native/midp_master_mode_events.c

--
SY,
Strim

selenau
Offline
Joined: 2006-10-11
Points: 0

What about fbapp_get_keyboard_fd() or what should I do if can't provide a file descriptor?

strim
Offline
Joined: 2006-10-20
Points: 0

Hi Selenau,

Please see mastermode_check_signal.* sources.

If you have no keyboard descriptor you can either integrate you keyboard events checking/handling
into existing function checkForSocketPointerAndKeyboardSignal(..), or easier to create
your own checkForKeyboardSignal() and register it to checkForSignal array of checker functions.

/** Static list of registered system signal checkers */
extern fCheckForSignal checkForSignal[];

A signal checker function is responsible for platform event detection & mapping it to MIDP event/signal.
A checker must return control prior the specified time would run out.
All MIDP signal checkers share common time interval provided to MIDP by VM (timeout param).
Platform signals are grouped into checkers (e.g. socket, keyboard & mouse signals are checked by one
function) according to the idea to do a single platform query for them in a checker function. For instance
socket, mouse and keyboard signals are checked by a single select() call.

selenau
Offline
Joined: 2006-10-11
Points: 0

Hi,

I built PCSL with "make NETWORK_MODULE=bsd/generic". It works. Maybe It is related, because default is bsd/qte...

With qvfb my (usb) keyboard is working but sending each key twice :(, making it impossible to use.

ps: Could someone please show the way of porting input handling in midp? porting fb is easy but, I'm not feel same about keyboard handling.

tusharj9
Offline
Joined: 2005-09-22
Points: 0

Hi,
I checked with QVFb from 2.3.X family and yes it's working!
For network module , i guess problem was due to Scratchbox's /etc/resolv.conf. After modifying this file I'm now able to download MIDlet :) .
One observation, commands such as listMidlet, removeMidlet are not generated. I temporarily modified jams_example.gmk to generate listMidlet.

Thanks you all for guidance.

Regards,
Tushar

strim
Offline
Joined: 2006-10-20
Points: 0

Nice to see you've succeeded!
Don't worry about listMidlet, removeMidlet, etc. They are coming with MR2 soon.

tusharj9
Offline
Joined: 2005-09-22
Points: 0

Hi,
I'm now able to launch phoneME emulator using QVFb :)
To get QVFb working , as suggested earlier by Strim, I downloaded and complied source code of Qtopia Core-4.2.1 and Qt-4.2.0.
Some steps that I followed are as under.
----------------------------------------------
cd path/to/Qtopia/Core
./configure -qvfb
make

cd path/to/Qt/tools/qvfb
make

export DISPLAY=:0.0
xhost +
./qvfb -depth 16

------------------------------------------------
Now I'm able to execute commands such as installMidlet, runMidlet ,usertest ,autotest . Also able to launch midlets as 'internal'. Although actual download and installation is not working at present (may be I'll have to check socket compilation of pcsl) .

The problem that at present bothering me is that phomeME is not responding to key events properly on hlui components. So unable to interact with the MIDlet.

Regards,
Tushar

strim
Offline
Joined: 2006-10-20
Points: 0

Hi Tusharj,

> I'm now able to launch phoneME emulator using QVFb

It's great :)
Thanks for the steps describing.

> Although actual download and installation is not working at present
> (may be I'll have to check socket compilation of pcsl) .

Yes, good guess.
In MR1 MIDP build can occasionally use PCSL build with mismatching networking module. It is possible when PCSL is built with no clean, above a results of previous PCSL builds with other settings. (I mean you could build PCSL for linux_fb and linux_qte at the same place with no cleaning.) Please make clean for PCSL and rebuild it and MIDP properly. In MR2 the problem will be fixed.

> The problem that at present bothering me is that
> phomeME is not responding to key events properly on
> hlui components. So unable to interact with the
> MIDlet.

I have quick guess about it.
MR1 is working with Qt/E 2.3.9, and we used QVFb from the sources of 2.3.9. It is possible QVFb from 4.x can be incompatible with MR1's binding code to QVFb :( I need more time to check it on my own. Have you any possibility to evaluate/check QVFb from 2.3.X family?

--
Best wishes,
Strim

ramon_garcia
Offline
Joined: 2006-11-22
Points: 0

I am asking because I am having issues compiling midp with native Qt. It requires the class QWSServer, specific of Qt embedded.

strim
Offline
Joined: 2006-10-20
Points: 0

Hi Ramon,

The configuration linux_i386_qte is designed to build PhoneME with Qt/Embedded >=2.3.9.
You can not use Qt for desktop instead.

The result of linux_i386_qte build can be started using Qt/Embedded libraries
for i386 and QVFb (Qtopia Virtual Frame Buffer).
LD_LIBRARY_PATH should contain Qt/Embedded libraries.

Regard,
Strim

tusharj9
Offline
Joined: 2005-09-22
Points: 0

Hi,
I got one similar problem for linux_fb_gcc configuration.
I'm building for Linux/i386 without Qt.
But it seems looking for QVFb when i try to use runMidlet.
I get error as below .
"REPORT: /tmp/.qtvfb_mouse-0: No such file or directory ".

Any suggestions what I need to do ?

Regards,
Tushar

strim
Offline
Joined: 2006-10-20
Points: 0

Oh, man, you are pretty close to enjoy with working build of PhoneME, my congratulations! Indeed it is not a similar problem with linux_qte, and I hope it is not a problem at all :)

Reality is that the Linux/i386 binaries of PhoneME need something on the host machine to work in. Instead of any special phone emulators or Linux GUI applications PhoneME on the Linux/i386 machine uses QVFb (Qtopia Virtual FrameBuffer) as a virtual video device and as an input device to get keyboard and mouse pointer events. Thus, when you start runMidlet at i386 host it looks for QVFb to connect to. This error is exactly about QVFb is not found, and I agree it could be more friendly.

To solve the problem please go to Trolltech site (www.trolltech.com) and search for possibility to download QVFb sources or binaries. QVFb is the part of Qtopia Core 4.x, open source edition is available by Troll's.

Regards,
Strim

tusharj9
Offline
Joined: 2005-09-22
Points: 0

Thanks Strim :)

So it seems that phoneME is at present tied to QVFb (Qtopia )for using framebuffer.
Is there any possibility to use GTK+ frame buffer (GtkFB)?

Regards,
Tushar

strim
Offline
Joined: 2006-10-20
Points: 0

Unfortunately PhoneME can't work with GtkFB right now, but we can think to introduce it for MR2.

You are right, PhoneME is tied to QVFb, but not strongly.
The QVFb binding code of linux/fb version is strictly located in fbapp_export.(c|h) sources, you can try to update the code to use GtkFB. Any questions are welcome :)

Yours,
Strim

selenau
Offline
Joined: 2006-10-11
Points: 0

I'm a little bit confused,

1) phoneME is not tied to QVFB for using frame buffer at the moment, I've tested it. But as I remember now fbapp_export.c has a macro definition which tells compiler if cpu=i386 then use QVFB else if cpu=arm use (/dev/fb0), and I have to change it, but it was trivial.

2) As I believe, GtkFB is not counterpart for QVFB. GtkFB is GTK library working/displaying on top of framebuffer rather than X11 (it is also not an active project, as again I remember documentation says it is possible for it to not compile at all). QVFB is a framebuffer emulation application for X11 so you do not need to exit x11 inorder to test your application.

Today I looked qvfb first time, but I belive someone can build an example using SDL, which is more common, so people not tied on a trolltech application (maybe because of application licences).

but I can be completely wrong, also.... :)

strim
Offline
Joined: 2006-10-20
Points: 0

Hi Selenau,

The idea of linux_fb_i386 configuration is not to provide phoneME implementation for Linux/i386 with [b]frame buffer device[/b]! The goal is to have an implementation as close to linux_fb_arm as it is possible and at the same time working on a Linux/i386 machines. In this way developer can test and debug a functionality at a host machine instead of more difficult deployment to a real ARM device, or more tricky work with ARM emulators.

> 1) phoneME is not tied to QVFB for using frame buffer
> at the moment, I've tested it.

It is true or false depending on what you do mean by "phoneME".

"phoneME Feature MR1 software includes implementations of CLDC 1.1, MIDP 2.0, and a number of optional package JSR. ..." The software consists of a Java code, shared native code (not specific for platforms, underlaying native libraries, ...), and of a platform dependent native code for a set of supported platforms and configurations.

Surely, Java code and shared native code have no dependence on Qt. However, native code specific for linux_fb_arm, linux_fb_i386 or linux_qte_... needs to be connected to a real life in some way.

The configuration linux_fb_arm is designed for real Linux based mobile devices with ARM CPU architecture and frame buffer driver for a graphical output. It is enough just to open e.g. /dev/fb0 device and draw there.

Not so easy for linux_fb_i386, because host Linux machine can have no frame buffer device at all. To unify numerous Linux/i386 host environments, and at the same time to have a small difference with linux_fb_arm version some virtual fb device is needed. QVFb can provide such a one. The native code to bind linux_fb_i386 to QVFb is kind of sample code, it can be easily changed to use other output/input devices.

But as I remember now
> fbapp_export.c has a macro definition which tells
> compiler if cpu=i386 then use QVFB else if cpu=arm
> use (/dev/fb0), and I have to change it, but it was
> trivial.

If your host machine has frame buffer device, it is
possible to use host /dev/fb0 instead of QVFb, but please note that phoneME can query fb device for screen geometry and other properties. I don't think you want to see phoneME of full screen size on your PC :) More careful support for host fb device is needed than just the trivial replacement.

> 2) As I believe, GtkFB is not counterpart for QVFB.
> GtkFB is GTK library working/displaying on top of
> framebuffer rather than X11 (it is also not an active
> project, as again I remember documentation says it is
> possible for it to not compile at all). QVFB is a
> framebuffer emulation application for X11 so you do
> not need to exit x11 inorder to test your
> application.

You are right. I'd known not enough about GtkFB when I believed it could be used instead of QVFb. I thought it was kind of virtual fb above GTK+, but all is visa versa :))

> Today I looked qvfb first time, but I belive someone
> can build an example using SDL, which is more common,
> so people not tied on a trolltech application (maybe
> because of application licences).

Is it Simple DirectMedia Layer? "SDL is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. ..."

If so, using SDL we will go rather to a new phoneME configurations linux_sdl_i386/arm, than to suggest a configuration similar with linux_fb_arm and working on Linux/i386.

SDL is not the only such a layer, please check also directFB.

Thank you for the
good questions,
--
Regards,
Strim