Rockbox

Tasklist

FS#1344 - Car Ignition Auto Stop function

Attached to Project: Rockbox
Opened by Craig Sather (rb_dev) - Monday, 12 May 2003, 07:08 GMT
Last edited by Björn Stenberg (zagor) - Thursday, 08 January 2004, 14:29 GMT
Task Type Patches
Category
Status Closed
Assigned To Björn Stenberg (zagor)
Operating System
Severity High
Priority Urgent
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

This patch implements an automobile ignition auto stop
function which I have dubbed “car adapter mode”.

When using the Archos in a car with a cigarette lighter
power adapter, car adapter mode automatically stops
playback when the car ignition is turned off... which
cuts the external power being supplied to the Archos
via the car adapter.

With this mode enabled, when external power to the
Archos is turned off, if playback is in progress, the
Archos will automatically go into pause state. When
used in conjunction with the existing Idle Poweroff
function, the Archos can be completely powered off
automatically by turning off the car ignition.
Additionally if a sufficiently long Idle Poweroff time
is used, playback will automatically be resumed if the
ignition is turned back on before the Idle Poweroff
function has powered off the Archos. In this case
playback is resumed 5 seconds after the external power
comes back on. This 5 second delay is to allow for the
time while the car is being started.

The function can be turned on & off in the system
settings menu.

Note that some cars do not cut the power to the
cigarette lighter when the ignition switch is turned
off. In this case the cigarette lighter can simply be
rewired so that it is only on when the ignition switch
is on.

This task depends upon

Closed by  Björn Stenberg (zagor)
Friday, 17 October 2003, 14:56 GMT
Reason for closing:  Accepted
Comment by Archie Gulati (agulati) - Wednesday, 14 May 2003, 00:23 GMT

WOW! i have been waiting for this featuer since day 1!,. when
do you rockbox implementors( sorry, but i dont know your
names) think that this will be installed into the daily builds?
any time soon? also, Craig Sather, could you maybe post a
compiled version of this patch on the site? (crossing fingers!).

Thanks alot!! This patch just made my day!!
-A
Comment by CJ Weber (theseige) - Monday, 02 June 2003, 02:03 GMT

yeah it would be nice to get the binary
Comment by Björn Stenberg (zagor) - Thursday, 05 June 2003, 11:28 GMT

Nice feature, I like it.

But please move it from firmware/ to apps/. This is not a
firmware (operating system) feature and should thus not be
located there. Call car_power_management() from status.c
instead, it knows when the plug is connected or disconnected.
Comment by Craig Sather (rb_dev) - Friday, 06 June 2003, 17:27 GMT

Hi Bjorn,

Thanks for taking a look at my patch. There are a few
reasons why it ended up in the firmware power_thread.

1) I sought guidance on the mailing list, and Linus
and I agreed that the power thread was a good place to
put the functionality.

2) Another similar system setting support function –
handle_auto_poweroff() already resides and executes in
the power thread, so it seems to follow current
convention on what types of functionality already
exists there on the firmware side.

3) Placement of the function in the power_thread
insures that the external power status is monitored
and the car adapter mode function works regardless of
what state the “application” side was left in by the
user while an mp3 is playing. Monitoring the external
power status from a place such as inside status_draw()
means that it will not function if the application
side is in a state where it is not periodically
calling status_draw(). Currently a Rockbox user can
do things on the application side that stops the
periodic calls to status_draw(), and leave it in that
state (while playing an mp3 file) which would
inadvertently disable the function if it was part of
the status code as you suggested.

4) This new function has little relation to the status
bar updating functions, but is more closely tied to
and more logically matches the functionality of things
that are already being done in the power thread.
Putting it in the status code just because there is a
function there that gets called periodically most of
the time (but not always) seems to be somewhat of a
hack. There is currently no requirement for the
application side to periodically call status_draw() if
they are doing something which makes status bar
updating unnecessary, and using status_draw() as a
place for calling functions that must always execute
periodically adds that new requirement on all
application code.

5) The line between application and firmware code is
already somewhat blurry as shown with the example in
#2 above (and additionally with existing firmware
functions that have hard-coded calls to application
functions), so an argument can be made that better
functionality & cleaner design has and should continue
to take precedence instead of enforcing rules that the
current code does not follow.

6) You have not suggested that I do so, but I
considered and then decided that it would be a waste
of resources to create a new thread on the application
side to poll the external power status just to get
around the problems stated in #3 above.


Well, that’s my long winded argument. If you still
want me to put this function in the status code, I
will, but it will work more consistently and be a
cleaner implementation if left in the power thread.
Comment by Anonymous Submitter - Friday, 01 August 2003, 22:59 GMT

Hello. Can you please post a compiled version of this patch,
so all of the people can enjoy your hard work?

Thanks
Comment by Anonymous Submitter - Friday, 08 August 2003, 18:44 GMT

Hello. Can you please update this to make it work with the
flashed rockbox firmware files? - it would solve alot of the
problems there. - as i understand it, you cannot have a
firmware that is before a certain date when using a flashed
jukebox.

Thakns
Comment by Craig Sather (rb_dev) - Saturday, 09 August 2003, 04:23 GMT

I don't understand your concern. There is nothing in this
patch that has anything to do with the ability to flash. If
this patch is applied to the current bulid, it can be
flashed to your Roclbox flash memory.
Comment by Anonymous Submitter - Saturday, 09 August 2003, 05:15 GMT

exactly - "if it is applied to the current daily build, it can be
flashed to your Roclbox flash memory." Right now, it cannot
be flashed, because it is applied to the daily build from june
2nd.
Comment by Craig Sather (rb_dev) - Saturday, 09 August 2003, 08:34 GMT

This patch as it currently exists isn't "applied" to any
build. The patch stands by itself. Patches do not have to be
applied only to the build from which they were made, they
can be applied to subsequent builds. Patches applied to
subsequent builds may or may not still apply cleanly. If
they don't apply cleanly, the patch utility indicates what
parts of the patch it could not apply, so that those changes
can be applied manually.

If you are not able to apply the patch yourself and still
want this feature in flash, I would suggest that you contact
the project admins (notably Bjorn Stenberg
<bjorn@haxx.se>)and ask them to put this patch in the CVS
baseline. There is quite a bit of demand for this patch,
but unfortunately it has just sat here for 3 months waiting
for a response from the project admins.
Comment by Anonymous Submitter - Monday, 11 August 2003, 17:26 GMT

I did what you asked, and e-mailed bjorn, but still no
response. It looks like a while before we will have this in the
CVS. In the meantime - could you please patch this file to a
daily build, so more people can use it, and comment on it to
the administrators - thus making implementation faster?
Comment by Craig Sather (rb_dev) - Tuesday, 12 August 2003, 01:06 GMT

Updated patch file to apply cleanly to daily20030811
Comment by Anonymous Submitter - Tuesday, 12 August 2003, 02:22 GMT

Cool, thanks! but i meant to make it so that it was an
ajbrec.ajz file - or a rockbox20030811.ucl file.

Sorry for the misunderstanding
Comment by Craig Sather (rb_dev) - Wednesday, 13 August 2003, 04:20 GMT

If you email me privately (rb_dev@yahoo.com) I can get you
the .ajz file.

I haven’t played around with doing any flashing or even read
the docs so if you need any help getting from the .ajz file
to flashing your recorder, I would suggest that you ask the
people on the mailing list who have been working with the
flash stuff.
Comment by Anonymous Submitter - Friday, 15 August 2003, 13:29 GMT

after a few bugs in the code, i patched in my source and it
worked.....

but, after i turned the feature on and after the jukebox
turned totally off, the jukebox doesn't turn on again when the
ignition switch is turned on.

Question: is there temporary and absolute RAM place?????
Comment by Anonymous Submitter - Friday, 15 August 2003, 13:31 GMT

after a few bugs in the code, i patched in my source and it
worked.....

but, after i turned the feature on and after the jukebox
turned totally off, the jukebox doesn't turn on again when the
ignition switch is turned on.

Question: is there temporary and absolute RAM place?????

answers to: LordRG125 AT web dot de
Comment by Andre Schaefer (lordrg125) - Friday, 15 August 2003, 13:34 GMT

after a few bugs in the code, i patched in my source and it
worked.....

but, after i turned the feature on and after the jukebox
turned totally off, the jukebox doesn't turn on again when the
ignition switch is turned on.

Question: is there temporary and absolute RAM place?????

answers: lordrg125 AT web DOT de
Comment by Craig Sather (rb_dev) - Saturday, 16 August 2003, 00:01 GMT

If you think that you have found bugs in the code please be
specific, as people have been using this patch on both
recorders and players without any problems.

Also, as the initial patch description states, playback will
only resume if external power is applied BEFORE the idle
poweroff function has shut the recorder off. Once the unit
is turned off, the Rockbox code can't be used to control
anything, because reapplying the power at that point only
causes the default Archos firmware charging code to execute.
Comment by Anonymous Submitter - Wednesday, 24 September 2003, 19:08 GMT

hi

I'm newbie on patching rockbox ...
and I would like to patch the standard 2.0 version with
your, but I can't find the right command to patch succefully
...
Could you right here, the command to apply it, or could
you send it to me ?

geo_fr at hotmail dot com
Comment by Anonymous Submitter - Monday, 06 October 2003, 20:17 GMT

Could someone email me the .ajz with this patch. This is just
what I've been looking for but l can't work out how to patch.

richard.a.walker@btinternet.com
Comment by Anonymous Submitter - Monday, 20 October 2003, 06:17 GMT


What about a auto on??
I used it for a couple of weeks and it disturbed me that
everytime i switch the jukebox on, I have to go through
menus and switch the carmode on... Isn't there any way to
permanently switch it on??? Is it?

Please think about it before implementing it.
Comment by Craig Sather (rb_dev) - Tuesday, 21 October 2003, 09:43 GMT

The last setting restored after a power off/on cycle,
however since this setting is saved to disk only if the disk
is spun up after the setting is changed but before the unit
is powered off, the setting (and some other settings also)
will not be saved if the unit is powered off before doing
some operation that spins up the disk.

As long as some operation that spins up the disk (such as
browsing the directories or loading the buffer while playing
an mp3 file) is performed before the unit is shut off, the
latest setting will be restored when the unit is powered
back on.

This behavior is documented in the user manual on page 10,
however the manual incorrectly states that this is true only
on Player models, but on Recorders this is also true for
some of the settings that are only stored on disk by the
Recorder (as opposed to the RTC memory area where there is
limited space for the Recorder to store some settings).
Comment by sophana (sophana) - Thursday, 08 January 2004, 14:03 GMT

could auto-on be implemented when firmware is flashed?

The problem might be that settings are stored into disk. So
this feature would have to be 'hard'

One other solution would be to reserve one flash sector for
storing settings.

Too bad I only have a player which is actually not working
with flashable rockbox!

Could anybody store the patched binary for the player
somewhere on the web and make the url available? That
would be great.

Thanks

Comment by Björn Stenberg (zagor) - Thursday, 08 January 2004, 14:29 GMT

Yes it can.

What's stopping it from working already is the fact that we
enter the battery charging screen instead of booting up when
DC is connected to a turned off recorder.

This (car auto stop) feature is now in Rockbox. You don't need
a patched binary to use it.

Loading...