Rockbox mail archiveSubject: 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
>> 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
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
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
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.
Received on 2010-05-16