Which Function For Scaling/zooming?

[greendots]

I will have to try to get dsp-bridge working

Why not dsplink or dspgateway? Maybe you know which is best to use in our case and can tell us, as I have no clue.

I only know what I read about it here: http://elinux.org/BeagleBoard/DSP_Clarification (don't forget the 2 links on bottom)

 

[Exophase]

Without having looked at it too extensively yet I think we should consider dsp-link:

Pros vs dsp-bridge:
- Lower level and lighter weight, may be more suitable for the kinds of things we're interested in pursuing on Pandora, including access to 100% CPU time and 100% of the small internal memory
- DSP side appears to be an open source library you link your DSP stuff to, not a binary blob operating system you preload on the DSP
- Angstrom preferred?

Cons vs dsp-bridge:
- Don't get support for dynamic loading and sharing the DSP, I don't think
- Miss out on application support like Leonora

Maybe somehow both could be supported...

 

[cosam]

What I recommend is doing it like psx4pandora does, using wrapper script technique:

ofbset -fb /dev/fb1 -pos 0 0 -size 800 480 -mem 307200 -en 1
fbset -fb /dev/fb1 -g 320 240 320 480 16
export SDL_VIDEODRIVER=fbcon
export SDL_FBDEV=/dev/fb1

op_runfbapp ./your_app_here

ofbset -fb /dev/fb1 -pos 0 0 -size 0 0 -mem 0 -en 0

I'm trying to use this approach to do a centred 3x scale, but with the following values:

export SDL_FBDEV=/dev/fb1
ofbset -fb $SDL_FBDEV -pos 160 24 -size 480 432 -mem 86400 -en 1
fbset -fb $SDL_FBDEV -g 160 144 480 432 16

When I get to running op_runfbapp, I get:

op_runfbapp: (not hiding FB): KDGETMODE: Invalid argument

And SDL doesn't want to give me a surface. Can it be used like this? What am I doing wrong?

 

[Exophase]

Make sure your arguments to op_runfbapp are both quoted and escaped, it's weird like that. I mean, do this:

my (string) ->
"my\ (string)"

 

[cosam]

Make sure your arguments to op_runfbapp are both quoted and escaped, it's weird like that. I mean, do this:

my (string) ->
"my\ (string)"

I thought it might be something like that too but apparently it's on about a different kind of argument. The only special chars I'm using are quotes around the final argument, and backslashing those doesn't help. Even tired with just a single argument (the executable with a "./" in front) and still no joy. In both cases the executable gets run fine and its arguments are passed as expected.

 

[Exophase]

Could you paste the actual line that's giving you problems?

 

[cosam]

Could you paste the actual line that's giving you problems?

Don't have it at hand, but suffice to say it's nothing more than:

op_runfbapp ./executable "$FILE"

Where "executable" is the program (all lower case ASCII, but tried quoting too) and $FILE is an absolute path to a file and can be anything (I've tried all sorts). Even without the "$FILE" I get the same problem. I do "export SDL_VIDEODRIVER=fbcon" before hand too, as in the example. Also tried:

op_runfbapp ./executable "\"$FILE\""

As per your suggestion, but to no avail.

 

[notaz]

When I get to running op_runfbapp, I get:

op_runfbapp: (not hiding FB): KDGETMODE: Invalid argument

This one is normal, ignore it.

export SDL_FBDEV=/dev/fb1
ofbset -fb $SDL_FBDEV -pos 160 24 -size 480 432 -mem 86400 -en 1
fbset -fb $SDL_FBDEV -g 160 144 480 432 16

And SDL doesn't want to give me a surface. Can it be used like this? What am I doing wrong?

You are setting virtual resolution to 480x432, do you really need that? If you do that you need to allocate appropriate amount of memory, that is at least 480*432*2 bytes.
From what can I see you just want to scale 160x144 to 480x432, in that case just set virtual resolution to 160x144

fbset -fb $SDL_FBDEV -g 160 144 160 144 16

Make sure your arguments to op_runfbapp are both quoted and escaped, it's weird like that. I mean, do this:

my (string) ->
"my\ (string)"

Damn, that's long fixed in GIT, forgot to push it through to ED of HF

 

[cosam]

You are setting virtual resolution to 480x432, do you really need that? If you do that you need to allocate appropriate amount of memory, that is at least 480*432*2 bytes.
From what can I see you just want to scale 160x144 to 480x432, in that case just set virtual resolution to 160x144

fbset -fb $SDL_FBDEV -g 160 144 160 144 16

Ah, I see. I was thinking virtual resolution was what you wanted to scale to. Tried your example and it does get a bit further, only I still can't set the video mode in SDL: "Unable to open a console terminal". Googling that I get stuff about virtual consoles not being compiled in but that doesn't appear to be the problem. It also fails opening /dev/tty0 due to lack of permissions but setting that to 666 didn't help. An strace shows me two ioctl calls which fail with EINVAL:

ioctl(4, VT_GETSTATE, 0xbecf2572)
ioctl(4, KDGKBMODE, 0xbecf257c)

Not sure if that's a problem or not. I'll play with it some more...

 

[notaz]

Ah, you can't use fbcon from X then, forgot about SDL wanting terminal stuff so badly.

Try dropping all the SDL_VIDEODRIVER stuff and maybe fbset (but leave ofbset), I think x11 SDL allows setting different resolutions which results in letterboxed image, no? If so you should be able to scale from that.

Edit: ah shit it still won't work, this will run on first overlay which can't be scaled. Don't really know how to do it with stock SDL.

 

[cosam]

Heh, you're right - it doesn't work. It tries to though. Removing the SDL_VIDEODRIVER variable lets it run, but you get a black screen and it seems no keyboard events can get through to the app. Dropping fbset doesn't appear to make any difference.

 

[cosam]

OK, I worked around the SDL video issue by writing straight to the frame buffer. The colours are messed up but that should just be a case of shifting some bits around. Any ideas as to why SDL isn't getting any events through?

 

[Pickle]

OK, I worked around the SDL video issue by writing straight to the frame buffer. The colours are messed up but that should just be a case of shifting some bits around. Any ideas as to why SDL isn't getting any events through?

If you dont SetVideoMode SDL wont generate events. You will have to get things direct.

 

[cosam]

If you dont SetVideoMode SDL wont generate events. You will have to get things direct.

Ah crap, of course... So I should just start pulling stuff from /dev/input or is there a better way?

Nevermind: found kernel interface stuff on the wiki. Works great!

 

[cosam]

I had a fiddle with SDL yesterday evening and I managed to get fbcon working by rewriting the event handling stuff. This means you can do hardware scaling from pretty much any resolution to... well, pretty much any other resolution using something like this:

export SDL_VIDEODRIVER=fbcon
export SDL_FBDEV=/dev/fb1
export SDL_FB_BROKEN_MODES=1

ofbset -fb $SDL_FBDEV -pos 0 0 -size 800 480 -mem 307200 -en 1
fbset -fb $SDL_FBDEV -g 320 240 320 480 16

op_runfbapp ./your_app_here

ofbset -fb $SDL_FBDEV -pos 0 0 -size 0 0 -mem 0 -en 0

This could probably be refined somewhat by calling ofbset/fbset from within SDL or duplicating some code snipets to so the same. You'd then be able to just do SDL_SetVideoMode to whatever you like, and have it scaled up automagically. Shouldn't be hard to add some flags (or borrow existing ones) to do letterboxing or stretching. Right now I've lost audio, but I suspect that's just down to missing ALSA stuff on my part.

Library: http://www.cosam.org/computers/pandora/libSDL-1.2.so.0.11.3.gz
Patch: http://www.cosam.org/computers/pandora/SDL-1.2.14-pandora-fb.patch

 

[notaz]

That's quite a destructive patch, I guess things like USB keyboards would go down with it applied?

 

[cosam]

That's quite a destructive patch, I guess things like USB keyboards would go down with it applied?

Yeah, it's pretty vicious :->

Virtual console switching basically bit the dust, but AFAIK we don't have that on the Pandora anyway. USB keyboard is a good point though; to be honest I didn't even think about it. I guess it's only an issue when fbcon is used explicitly and, seeing as that never worked anyway, nothing's really broken as such. I will however test/fix USB keyboard support as it'd be good if it did work. Thankfully no alterations were required on the mouse/touchscreen side of things.

 

[notaz]

Virtual console switching basically bit the dust, but AFAIK we don't have that on the Pandora anyway.

You can type 'sudo chvt 1' and it will go into terminal just fine. SDL used to work a while ago from there, you could kill X and run your SDL game from a terminal, not sure how it goes now.

 

[urjaman]

You can type 'sudo chvt 1' and it will go into terminal just fine. SDL used to work a while ago from there, you could kill X and run your SDL game from a terminal, not sure how it goes now.

Yeah... btw why is it that ctrl-alt-f1 (ctrl-alt-fn-1) doesnt work? (I could propably find out myself but no time...). Nice to have a fullscreen app frozen and think "Ok i'll just drop to the console and kill it" *ctrl-alt-f1* *nothing* "uh, oh...". I do have mouse-over-edge changes workspace, though so i can usually just move my mouse over/under the screen and launch a terminal from there, but still its a PITA.

 

[john4p]

Thanks a lot, SteveM. I'll try this maybe next week with UAE4All.