Arg! Where Is Sdl/fbdev For Z Documented!?

[vputz]

I'm pulling my hair out trying to work with SDL and FBDev with OZ 3.5.3 on an Akita.  I was using Hentges 3.5.3, which worked OK, but was a bit slow (9 fps fullscreen on Snes9x).  I then tried Cresho's package for the regular Z rom, which failed as it should have, but I didn't have the Hentges versions of libSDL and Snes9x, so I just reinstalled the OZ versions, which turned out to not be the best idea.

But I've played this game before, with my 6000...

For example: I try Snes9x, which appears to be trying to follow my wishes, but is rotated 90 degrees.  It tries to read a mystical file /tmp/qtembedded-root/QtEmbedded-0.spec, which doesn't exist, but should tell it rotation or QVga information.

"Aha," think I, "I shall create this file and put the directive "Rot=1" in it!

So I do that, and while it obediently says it's reading the file and that it's "Rot=1, Qvga=0", it then, one line down, says that it will use "Rot=0, Qvga=0"

Heck, I was just guessing, there.  I can't find references to a "QtEmbedded-0.spec" anywhere in my knowledge of SDL.  What does it do?  How do you set it up?  How do you convince SDL programs to honor its wishes?  How do you enable Qvga mode?

I then turn to mplayer for help.  I follow the thread on "video playback on the 6000", which I remember working on the 6000.  I create an /etc/fb.modes file with the right info.  I run mplayer with -vm -vo fbdev -fbmode qvga -vop rotate 1.  The movie appears--upside down and reversed left to right.  Changing "-vop rotate 1" to other numbers is useless.  And there is no sound.

I see plenty of howto guides, and many are good.  But few really address WHAT is going on.  Particularly in the case of the QtEmbedded-0.spec file and how it works, that is completely confused.

Please, any help would be appreciated.  I have worked with SDL in the past (Linux platform game that never quiiite made it out the door) so I am familiar with a lot of the basics here, but NOT how it applies to the Z.

Thanks,
-->VPutz

[iamasmith]

I'm guessing that OZ doesn't generate that file for you... contents of /tmp/qtembedded-zaurus/QtEmbedded-0.spec on Cacko 1.23 running on my old SL-C860 is...

Transformed:Rot270:Vga:0

(no cr at the and of the line/file).

Take a look at the SDL QT Interface code for more info.... it's shocking when it comes to dealing with the rotation stuff and generally needs a lot of patching... I seem to remember the zports version working best for me.

- Andy

[vputz]

I'm guessing that OZ doesn't generate that file for you... contents of /tmp/qtembedded-zaurus/QtEmbedded-0.spec on Cacko 1.23 running on my old SL-C860 is...

Transformed:Rot270:Vga:0

(no cr at the and of the line/file).

Take a look at the SDL QT Interface code for more info.... it's shocking when it comes to dealing with the rotation stuff and generally needs a lot of patching... I seem to remember the zports version working best for me.

- Andy
[div align=\"right\"][a href=\"index.php?act=findpost&pid=112723\"][{POST_SNAPBACK}][/a][/div]

Thanks--that is a help actually; I've got Snes9x back to its fullscreen, correctly rotated, and rather slow (10 fps max) self.

Any idea how to set it to QVga mode, if possible?  And where did you get that information on how to set the line?  Is this part of the regular SDL distribution, or something that's just for the Zaurus, or what?  

I guess my question is this: If I was to look for a canonical website for SDL on the Zaurus, where would I turn?

-->VPutz

[lardman]

Might be worth asking whoever is the maintainer for the SDL packages in OE, or look at apps that behave as you want (iirc, mplayer uses SDL and can do various rotation/scaling things.)


Si

[iamasmith]

I'm guessing that OZ doesn't generate that file for you... contents of /tmp/qtembedded-zaurus/QtEmbedded-0.spec on Cacko 1.23 running on my old SL-C860 is...

Transformed:Rot270:Vga:0

(no cr at the and of the line/file).

Take a look at the SDL QT Interface code for more info.... it's shocking when it comes to dealing with the rotation stuff and generally needs a lot of patching... I seem to remember the zports version working best for me.

- Andy
[div align=\"right\"][a href=\"index.php?act=findpost&pid=112723\"][{POST_SNAPBACK}][/a][/div]

Thanks--that is a help actually; I've got Snes9x back to its fullscreen, correctly rotated, and rather slow (10 fps max) self.

Any idea how to set it to QVga mode, if possible?  And where did you get that information on how to set the line?  Is this part of the regular SDL distribution, or something that's just for the Zaurus, or what?  

I guess my question is this: If I was to look for a canonical website for SDL on the Zaurus, where would I turn?

-->VPutz
[div align=\"right\"][a href=\"index.php?act=findpost&pid=112818\"][{POST_SNAPBACK}][/a][/div]

I would simply start by looking at the QT sources included in libSDL, it's a defined interface option but all sorts of things cause problems with rotation on the Zaurus and be mindful that a clamshell device in clamshell mode is already rotated (natural screen orientation is portrait).

Common SDL problems include SDL reporting to the application the portrait geometry when running in fullscreen so instead of getting back 640x480 when your app queries this info it gets 480x640 , indications of this problem are that apps that vertically centre the display (like scummvm) end up displaying partially off screen when in clamshell mode and/or chop the screen display on the right so that only 480 pixels are displayed horizontally (happens with quake).

As I mention zports.sf.net has some patches to libSDL but I think that somebody could really do with stripping the whole of Qtopia support out of SDL and rewriting it...

<disclaimer>lol, this may have all been tidied up since I last looked of course</disclaimer>

- Andy

[Hrw]

clamshell device in clamshell mode is already rotated (natural screen orientation is portrait).

Under 2.6 kernels all c7x0 machines has landscape as default (0 degree rotation). Cxx00 has portrait anyway (hardware limitation)

[iamasmith]

clamshell device in clamshell mode is already rotated (natural screen orientation is portrait).

Under 2.6 kernels all c7x0 machines has landscape as default (0 degree rotation). Cxx00 has portrait anyway (hardware limitation)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=112846\"][{POST_SNAPBACK}][/a][/div]

Interesting....

I also remember that on the Sharp ROM the qpe library needs a setting in qpe.conf to tell qpe to translate the screen 180 degrees otherwise the interface gets rendered upside down.

I supposed up to now that the rationale behind this was related to providing a frame buffer driver with sequential access to pixels so that images could be blit to the frame buffer without having to undergo any form of translation.... in this manner drivers requiring the highest performance could achieve that but would bear in mind the actual orientation of the frame buffer in relation to the address map.

Obviously libraries such as qpe implement translation and rotation and provide abstract device contexts for applications to draw into which are then translated and rendered by the driver.

Maybe I'm wrong, perhaps the clamshell units memory maps for the display are organised horizontally making horizonal bulk transfers efficient.. perhaps not though... certainly OpenBSD frame buffer accessed through WSDISPLAY_IO orientates to portrait and it needs rotation switches in the wsfb Xorg driver to make the X server render to the wsdisplay so it seems to correlate that there is a natural orentation against the display memory map.

Is this in fact the case or does the 2.6 Kernel on these devices provide translation for the frame buffer? - if so then bulk copies on to of native frame buffer services (such as those implemented by the Xorg fb driver) would be fairly slow.

Perhaps you expose the frame buffer graphics access in a different manner for high performance rendering.. this would be another option.

Actually, you refer to 'hardware limitation' on the SL-Cxxxx, does this suggest that the SL-Cxxx units had a programmable controller (part of the Ati chipsets?) that could organise the frame buffer memory map into a landscape mode, whereas the SL-Cxxxx (using the PXA27x LCD controller) can't?

For my own curiousity I would be interested in any information you had on this HrW.

- Andy

[vputz]

Hmm.  Sounds OK.  When you say "look at the LibSDL sources"--the ones in the OE tree?  I'm setting up BitBake/OE, so I'll try to check that out.

I did play with the settings a bit ("Transformed:Rot270", etc).  Setting QVga mode made no visible difference, though (although Snes9x reported "Qvga=1" instead of "Qvga=0", but output was identical); not sure what's involved with using Qvga mode.

I notice that mplayer can do it, but only in conjunction with fbdev ("-vo fbdev" et al).  Not sure what's involved there.

I'll check out the LibSDL sources and see if I discover anything...

[lardman]

For my own curiousity I would be interested in any information you had on this HrW.

Have a word with RP on irc #oe


Si