Rockbox as an SDL app on the zipit Z2.

[dheyse]

I did a quick and dirty build of rockbox as an SDL application on the zipit.

http://macrofig.blogspot.com/2011/01/we-have-liftoff.html

I'm not sure whether this warrants a new port topic, or if any discussion belongs in the rockbox-as-an-app thread.
I did make a few teensy changes to the code.  Is it worthwhile to try and get them incorporated in SVN if it's just me using this?

[Chronon]

Cool. 

I think it is worthwhile to put some patches on the tracker.  I'm not very familiar with this device, but if you have some changes that allow Rockbox to work more smoothly it makes sense to contribute these back.

[dheyse]

I did a quick search in this forum for plugins, but didn't see much.  So I was wondering if anyone has done any work on keymaps for the SDL_PAD on the plugins. 

Also, is there any reason (other than the missing key mappings) that would prevent plugins from functioning on an SDL application build?

[Chronon]

Plugins (at least the ones I have tried) seem to work fine in the simulator, so I would guess a missing key map is probably the culprit.

Also, there is work on porting Rockbox as an application to the Pandora and Maemo:
http://www.rockbox.org/wiki/PandoraPort
http://www.rockbox.org/wiki/MaemoPort

I think it would be good to create a wiki page for this project too.

[dheyse]

Thanks for the links.  I was wondering about those ports after scanning the IRC logs for February. 

I'll have to keep tabs on their SDL app changes because I think we have slightly different needs: touchscreen/mouse vs. buttons/kbd and Window system vs. Fullscreen SDL framebuffer.

[JdGordon]

I did a quick search in this forum for plugins, but didn't see much.  So I was wondering if anyone has done any work on keymaps for the SDL_PAD on the plugins. 

Also, is there any reason (other than the missing key mappings) that would prevent plugins from functioning on an SDL application build?

I read the logs and this isnt the best place to reply but will have to do. You shouldn't add SDL_PAD because it doesnt look like a really generic keypad. you should add a ZIPIT_PAD (or similar) because unless it is 100% egeneric it wont likely be used with other targets

[dheyse]

Arrgh.  I just did something like a hundred SDL_PAD edits.  But you're right.  It seems like a generic SDL_PAD is a only good fit about 80% of the time.  Like when it's left, right, up, down, select, quit, and maybe menu.  I'll switch over to ZIPIT_Z2_PAD once I get it all to compile.

Meanwhile I found 2 files that should be fixed to separate HAVE_BUTTON_DATA from HAVE_TOUCHSCREEN.

In button.c lastdata should be declared when HAVE_BUTTON_DATA, not HAVE_TOUCHSCREEN, but it should require both defined when it's compared to data.

And button-sdl.c should be fixed to return *data unchanged when HAVE_BUTTON_DATA but not HAVE_TOUCHSCREEN.  Or hey, maybe it could return keyboard data.  I believe I saw something about a really old patch for that somewhere in the recent IRC logs.