Qtopia patches (input grabbing and iconify)

SDL Development
1

Ok, here’s a patch that adds support for SDL_WM_GrabInput (default
state is “ungrabbed”) and SDL_WM_IconifyWindow. Also has some other
tweaks such as taking additional steps to clean up when exiting
(bypassing certain bugs in some versions of Qtopia and/or OPIE) and it
also maps Key_F33 to Key_Return (this is the Zaurus ‘ok’ key).

Enjoy.

P.S Sam, this one should be added to CVS unless you spot any issues I
missed (almost shipped with a broken ‘main’ - oops!).

-------------- next part --------------
A non-text attachment was scrubbed…
Name: qtopia.diff.bz2
Type: application/octet-stream
Size: 5532 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20021227/cb12ab3e/attachment.obj

2

David,

Will this need a new version installed on the Zaurus/iPaq or will it work with
the older version?

David
— David Hedbor wrote:> Ok, here’s a patch that adds support for SDL_WM_GrabInput (default

state is “ungrabbed”) and SDL_WM_IconifyWindow. Also has some other
tweaks such as taking additional steps to clean up when exiting
(bypassing certain bugs in some versions of Qtopia and/or OPIE) and it
also maps Key_F33 to Key_Return (this is the Zaurus ‘ok’ key).

Enjoy.

P.S Sam, this one should be added to CVS unless you spot any issues I
missed (almost shipped with a broken ‘main’ - oops!).

ATTACHMENT part 2 application/octet-stream

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

3

Ok, here’s a patch that adds support for SDL_WM_GrabInput (default
state is “ungrabbed”) and SDL_WM_IconifyWindow. Also has some other
tweaks such as taking additional steps to clean up when exiting
(bypassing certain bugs in some versions of Qtopia and/or OPIE) and it
also maps Key_F33 to Key_Return (this is the Zaurus ‘ok’ key).

I patched the SDL library, recompiledt and installed it on the Zaurus (german
version with original sharp ROM). Afther that, I recompiled the Zaurus port
of the C64 Emulator Frodo and linked it against the new libSDLMain.

This new version of frodo prints the following on the Zaurus console when i
start it:

QPaintDevice: Must construct a QApplication before a QPaintDevice
Aborted

The old Zaurus version of Frodo still works with the new version of the SDL.
Some hints, what I have done wrong?

Best regards

Bernd Lachner

4

Bernd Lachner writes:

Ok, here’s a patch that adds support for SDL_WM_GrabInput (default
state is “ungrabbed”) and SDL_WM_IconifyWindow. Also has some other
tweaks such as taking additional steps to clean up when exiting
(bypassing certain bugs in some versions of Qtopia and/or OPIE) and it
also maps Key_F33 to Key_Return (this is the Zaurus ‘ok’ key).

I patched the SDL library, recompiledt and installed it on the Zaurus (german
version with original sharp ROM). Afther that, I recompiled the Zaurus port
of the C64 Emulator Frodo and linked it against the new libSDLMain.

This new version of frodo prints the following on the Zaurus console when i
start it:

QPaintDevice: Must construct a QApplication before a QPaintDevice
Aborted

The old Zaurus version of Frodo still works with the new version of the SDL.
Some hints, what I have done wrong?

Hmm. It sounds like you didn’t use -Dmain=SDL_main when compiling (or
didn’t link with -lSDLmain, but you said you did, so that’s not
it). Either that or the SDLmain library you’re using is stripped (how
big is it?).–
[ Below is a random fortune, which is unrelated to the above message. ]
The Marines:
The few, the proud, the not very bright.

5

Alexandre Courbot writes:

Ok, here’s a patch that adds support for SDL_WM_GrabInput (default
state is “ungrabbed”) and SDL_WM_IconifyWindow. Also has some other
tweaks such as taking additional steps to clean up when exiting
(bypassing certain bugs in some versions of Qtopia and/or OPIE) and it
also maps Key_F33 to Key_Return (this is the Zaurus ‘ok’ key).

I’m sorry to say that I only get segfaults with it :frowning: I’ve tested it
with both scummvm and prboom. The Zaurus screen gets filled at 3/4
(which looks suspicious to me as well), and it segfaults just after. The
current SDL’s CVS works fine however.

[snip]

Additional info: running testsprite with height and width at 100
success. Height at 300 and width at 200 too. Height at 320 and width at
240 fails, as well as height at 200 and width at 300.

I’m running OZ 3.1rc1 - please tell if I can help any further, or if you
want me to check with some program.

This is very strange. I haven’t, as far as I know, changed anything
related to the blitting (other than splitting it in different methods
for clarity). The crashes in thread creation makes no sense to me
(it’s the timer and audio mixer threads).–
[ Below is a random fortune, which is unrelated to the above message. ]
Ontogeny recapitulates phylogeny.

6

Ok, here’s a patch that adds support for SDL_WM_GrabInput (default
state is “ungrabbed”) and SDL_WM_IconifyWindow. Also has some other
tweaks such as taking additional steps to clean up when exiting
(bypassing certain bugs in some versions of Qtopia and/or OPIE) and it
also maps Key_F33 to Key_Return (this is the Zaurus ‘ok’ key).

I’m sorry to say that I only get segfaults with it :frowning: I’ve tested it
with both scummvm and prboom. The Zaurus screen gets filled at 3/4
(which looks suspicious to me as well), and it segfaults just after. The
current SDL’s CVS works fine however.

Here are the gdb backtraces:
Scummvm:
(gdb) bt
#0 0x405f1810 in sigsuspend () from /lib/libc.so.6
#1 0x405f1800 in sigsuspend () from /lib/libc.so.6
#2 0x4050ca48 in pthread_create () from /lib/libpthread.so.0
#3 0x4050cadc in pthread_create () from /lib/libpthread.so.0
#4 0x40055f74 in SDL_SYS_CreateThread (thread=0x124980, args=0x10b308)
at SDL_systhread.c:99
#5 0x40055e24 in SDL_CreateThread (fn=0x40056f7c ,
data=0x1112b8) at SDL_thread.c:257
#6 0x4005701c in SDL_SYS_TimerInit () at SDL_systimer.c:282
#7 0x40056878 in SDL_TimerInit () at SDL_timer.c:90
#8 0x4002c0e4 in SDL_InitSubSystem (flags=49) at SDL.c:109
#9 0x4002c17c in SDL_Init (flags=49) at SDL.c:166
#10 0x0000a6c4 in OSystem_SDL_Common::create (gfx_mode=0,
full_screen=false) at backends/sdl/sdl-common.cpp:45
#11 0x0000a694 in OSystem_SDL_create (gfx_mode=-4, full_screen=8)
at backends/sdl/sdl-common.cpp:37
#12 0x00066690 in GameDetector::createSystem (this=0x40520dc0)
at common/gameDetector.cpp:631
#13 0x00066ee8 in SDL_main (argc=1, argv=0xbffffa84) at
common/main.cpp:180#14 0x00092b84 in main (argc=1, argv=0xbffffa84) at
SDL_Qtopia_main.cc:27#15 0x405de634 in __libc_start_main () from
/lib/libc.so.6

Prboom:
#0 0x40626810 in sigsuspend () from /lib/libc.so.6
#1 0x40626800 in sigsuspend () from /lib/libc.so.6
#2 0x40560a48 in pthread_create () from /lib/libpthread.so.0
#3 0x40560adc in pthread_create () from /lib/libpthread.so.0
#4 0x400a9f74 in SDL_SYS_CreateThread (thread=0xf16c8, args=0xe9878)
at SDL_systhread.c:99
#5 0x400a9e24 in SDL_CreateThread (fn=0x40080c60 <SDL_RunAudio>,
data=0xe55f8) at SDL_thread.c:257
#6 0x400813e0 in SDL_OpenAudio (desired=0xbfffd8d0,
obtained=0x40062fb4) at SDL_audio.c:488
#7 0x4002a4e0 in Mix_OpenAudio ()
from /opt/QtPalmtop/lib/libSDL_mixer-1.2.so.0
#8 0x00055354 in strcpy ()

strcpy?? Looks like some stack has been eaten there…

I’ve also tested with the test program testsprite:
#0 0x405a124c in memcpy () from /lib/libc.so.6
#1 0x405a1168 in memcpy () from /lib/libc.so.6
#2 0x4004dac0 in SDL_QWin::repaintRotation3 (this=0x2eac8,
rect=@0xbffff744) at SDL_QWin.cc:296
#3 0x4004dee4 in SDL_QWin::repaintRect (this=0x2eac8, rect=@0xbffff744)
at SDL_QWin.cc:349
#4 0x4004df88 in SDL_QWin::paintEvent (this=0x2eac8, ev=0xbffff734)
at SDL_QWin.cc:366
#5 0x403e48c4 in QWidget::event () from /opt/QtPalmtop/lib/libqte.so.2
#6 0xbffff8f8 in ?? ()

Weird - it seems to crash at a completely different place of the lib.

Additional info: running testsprite with height and width at 100
success. Height at 300 and width at 200 too. Height at 320 and width at
240 fails, as well as height at 200 and width at 300.

I’m running OZ 3.1rc1 - please tell if I can help any further, or if you
want me to check with some program.

See you,
Alex.–
http://www.gnurou.org

7

Am Sonntag, 29. Dezember 2002 21:49 schrieben Sie:

Bernd Lachner <@Bernd_Lachner> writes:

Ok, here’s a patch that adds support for SDL_WM_GrabInput (default
state is “ungrabbed”) and SDL_WM_IconifyWindow. Also has some other
tweaks such as taking additional steps to clean up when exiting
(bypassing certain bugs in some versions of Qtopia and/or OPIE) and it
also maps Key_F33 to Key_Return (this is the Zaurus ‘ok’ key).

I patched the SDL library, recompiledt and installed it on the Zaurus
(german version with original sharp ROM). Afther that, I recompiled the
Zaurus port of the C64 Emulator Frodo and linked it against the new
libSDLMain.

This new version of frodo prints the following on the Zaurus console when
i start it:

QPaintDevice: Must construct a QApplication before a QPaintDevice
Aborted

The old Zaurus version of Frodo still works with the new version of the
SDL. Some hints, what I have done wrong?

Hmm. It sounds like you didn’t use -Dmain=SDL_main when compiling (or
didn’t link with -lSDLmain, but you said you did, so that’s not
it). Either that or the SDLmain library you’re using is stripped (how
big is it?).

I compiled the SDL again from libsdl cvs, where you newest patch is now
included. Compiling of the sdl for Zaurus works and my old Frodo version runs
with this sdl version on the Zaurus.

Than I configure and make Frodo again. As you can see below, -Dmain=SDL_main
and -lSDLmain is used. The libSDLMain.a library have a size of 158834.

When I now start this Frodo version on the Zaurus the error above comes up
again.

arm-linux-gcc -O2 -g -fomit-frame-pointer -Wall -Wno-unused -Wno-format
-I/opt/Qtopia/sharp//include/SDL -D_REENTRANT -Dmain=SDL_main -DHAVE_SDL
-DQTOPIA -DREGPARAM= -I./ -DFRODO_HPUX_REV=0 -DKBD_LANG=0 -o CPU_common.o -c
CPU_common.cpp
cc1plus: warning: -g with -fomit-frame-pointer may not give sensible debugging

arm-linux-g++ -o FrodoSC main.o Display.o Prefs.o SID.o REU.o IEC.o 1541fs.o
1541d64.o 1541t64.o 1541job.o SAM.o CmdPipe.o C64_SC.o CPUC64_SC.o VIC_SC.o
CIA_SC.o CPU1541_SC.o CPU_common.o -L/opt/Qtopia/sharp/lib/
-L/opt/Embedix/tools/arm-linux/lib -L/opt/Qtopia/sharp//lib
-Wl,-rpath,/opt/Qtopia/sharp//lib -lSDLmain -lSDL -L/opt/Qtopia/sharp/lib
-L/opt/Qtopia/sharp/lib/ -lqpe -lqte -lpthread
cp FrodoSC …

8

Hi,

I ran into the same problem.

QPaintDevice: Must construct a QApplication before a QPaintDevice
Aborted

I think the problem is in src/main/linux/SDL_Qtopia_main.cc. Here,
a QWidget dummy object is created before the QPEApplication exists.
Creating it (dynamically) after the creation of the QPEApplication
instance works for me. See also
http://lists.trolltech.com/qt-interest/2002-09/thread01006-0.html

The funny thing is that an older version of libsdl DID work with
the exact same SDL_Qtopia_main.cc…

cheers,
Arjan Peddemors.

9

Hi,
I ran into the same problem.

QPaintDevice: Must construct a QApplication before a QPaintDevice
Aborted

I think the problem is in src/main/linux/SDL_Qtopia_main.cc. Here,
a QWidget dummy object is created before the QPEApplication exists.
Creating it (dynamically) after the creation of the QPEApplication
instance works for me. See also
http://lists.trolltech.com/qt-interest/2002-09/thread01006-0.html
Have you ran in this problem with a Zaurus SDL program? How have you solved
the problem? Have you patched src/main/linux/SDL_Qtopia_main.cc ?

The funny thing is that an older version of libsdl DID work with
the exact same SDL_Qtopia_main.cc…
Yes. For this reason I didn’t thought that there is a bug in the unchanged
src/main/linux/SDL_Qtopia_main.cc.

10

I think the problem is in src/main/linux/SDL_Qtopia_main.cc. Here,
a QWidget dummy object is created before the QPEApplication exists.
Creating it (dynamically) after the creation of the QPEApplication
instance works for me. See also
http://lists.trolltech.com/qt-interest/2002-09/thread01006-0.html

I tried out to dynamicly create the dummy widget with follwing code in
SDL_Qtopia_main.cc:

#ifdef QWS
cout << “Begin QWS” << endl;
// This initializes the Qtopia application. It needs to be done here
// because it parses command line options.
// QWidget dummy;
app = new QPEApplication(argc, argv);
QWidget *dummy = new QWidget();
app->showMainWidget(dummy);
atexit(cleanupQCop);
cout << “End QWS” << endl;
#endif

If I use this code the error “QPaintDevice: Must construct a QApplication
before a QPaintDevice Aborted” didn’t come on the Zaurus, but it still didn’t
work, the Zaurus freezes in this case completely. But the debug message
"Begin QWS" becomes up before. This message didn’t come in the cas the dummy
widget is not dynamicly generated.

Regards

Bernd Lachner