Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: [RaaA] Move SDL stuff to target tree

Re: [RaaA] Move SDL stuff to target tree

From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Sun, 16 May 2010 15:41:34 +0200

Am 16.05.2010 15:23, schrieb Dave Chapman:
> pouly amaury wrote:
>>
>> What do you think about it? Do you have any ideas how my proposal
>> could be improved? Or do you have any questions? Please join the
>> discussion.
>>
>>
>> Sounds ok for me, I like the idea of the simulator being a real target.
>
> Apologies for answering so late (too late in a way, as this patch was
> committed yesterday), but the concept of the simulator being a real
> target worries me. This is simply because the simulator *isn't* a
> real target - it's a simulation of a real target.
>
> My understanding of the purpose of RaaA is that it would use less and
> less of the Rockbox firmware code as time went on. Development of the
> sim should go in the opposite direction - using more and more Rockbox
> code.

No, I don't think RaaA aims to use less and less Rockbox code. It's a
port of Rockbox afterall.

>
> I'm also not convinced that changing some #ifdef SIMULATOR lines to
> use things like HAVE_SDL or HAVE_SDL_AUDIO makes the code for the
> simulator better. IMO it makes it harder to see the places where the
> sim differs from the target it's simulating (it still differs in the
> same way, it's just obfuscated more).
>
> As an example of the different purposes of the sim and RaaA, the SDL
> button driver for RaaA should expose all buttons to the apps/ part of
> Rockbox (especially if there is a full keyboard on the device). The
> SDL button code for the sim should (although it doesn't currently)
> provide simulation of the hardware buttons (and/or touchscreen and
> remote) on the real device, including things like mechanical and
> electrical limitations. Other buttons are used for events such as USB
> insertion/removal.

That's not going to change. The parts that are simulating a target
override the SDL app parts, e.g. by including a different
button-target.h. We never simulated mechanical and electrical
limitations and that's not going to change. We want to run code which
compiles for a target on a more convinient system (simulate), not
emulate the target itself.

>
> Similarly, the LCD code for the sim presents the main LCD, the remote
> LCD (if present on the target), a backdrop image, simulation of
> backlights, simulation of charcell etc. For RaaA, none of those
> complications are needed, but different complications may be - such as
> possible window resizing, or run-time detection of LCD size (if we go
> all the way with RaaA), or other things we haven't thought of yet.

I don't see any problem here. These complications won't touch the SDL
app, because it will not define SIMULATOR.

>
>
> Am I missing something obvious? Why is putting the sim code in target
> tree a good idea?

I think you mix up sim-specific code and sdl specific. The former will
stay specific for the simulator, the latter will be reused for the sdl
application because code duplication is bad.

>
> I would have preferred to have seen a new SDL target being added to
> the target tree, with none of the sim code in it - i.e. a shiny new
> SDL target without the baggage of the sim, and leaving the sim free to
> be developed and improved independently of RaaA (and in the opposite
> direction).
>
>

That doesn't make sense to me. The difference between the sims and an
SDL app boil down to the button and lcd handling. There need to be very
few #ifdef SIMULATOR to separate the SDL app from the sim.

Best regards.
Received on 2010-05-16


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa