* FLUSH_EXT is used if featureflag is set and we are using LBA48
(unconditionally used for CE-ATA on ipod6g)
* FLUSH is used if featureflag is set (ATA6+) or if device claims to be ATA5+
* Rename ata_disk_can_power_off() to ata_disk_can_sleep() as that is
what it actually tests for. Only use it to gate issuing the
STANDBY IMMEDIATE command.
* Restore behavior of ata_disk_is_active() to return 1 if drive is
"spinning" or powered up.
* Allow poweroff if drive claims PM support OR we are able to issue
FLUSH/FLUSH_EXT commands.
* Added ata_flush() to explicitly trigger a flush operation, and hook it
up to storage_flush() in the device shutdown path. (Flushes were
only previously used in the storage device power management path)
* After issuing all settings, re-issue IDENTIFY_DEVICE to make sure
it reflects everything we've enabled.
* Update manual section on Flash/SSD mods.
Change-Id: I6770a54ef3a87f4c47120bcb96c944a6652f1bf4
Attempt to change file fails due to access to uninitialized memory with negative index
Fixup for 55a5bfe7
Change-Id: I9c42f66c856c1d4b7261da5e4996efbe9597bcd4
Add ability to imageviewer to view current track embedded/folder album art
Add "View Album Art" WPS context menu item
Change-Id: I49caebd38e5e3e2910d418bbeaa5e51da0e6bd93
When creating a new control file for the current playlist,
the existing file will now be renamed to serve as a backup,
until the next time the control file is replaced again,
allowing you to restore the previous state of the playlist,
in case you accidentally cleared it.
This also means that an entirely new file is created each
time, instead of truncating the existing one.
Change-Id: I2fd96eb8c3940b85df807fd7646dc0359a036351
In the following scenario, a garbage file name would
be written to the control file for the playing track
(resulting in a failure to resume correctly):
- "Keep Current Track When Replacing Playlist" option is set
- A track is playing that was not inserted but instead comes
from a playlist file on disk
- User performs "Playing Next..." -> "Play" on some tracks, so
that the current playlist is replaced (but leaving the playing
track queued)
- User saves the playlist while queued track is still playing
(the offer to remove queued tracks is declined)
The failure occurs because the pl_save_update_control function
assumes that the seek offset for queued files always points into
the control file. Meanwhile, the remove_all_tracks_unlocked
function adds the PLAYLIST_QUEUED flag indiscriminately, even if
a track comes from a playlist file instead of having been inserted.
Theoretically, this could be addressed by adding the playing
track's file name as a parameter to PLAYLIST_COMMAND_CLEAR,
which the track is then updated to point to, unless it
was already inserted (alternatively, we could seek within
the playlist file for such tracks).
Unless I'm missing something, it may be preferable, though, to
get rid of PLAYLIST_COMMAND_CLEAR completely, and instead have the
remove_all_tracks_unlocked function start over with a fresh
control file, into which we insert a single ('P' and) 'Q' command.
This seems to have several advantages:
- When resuming, we eliminate the need to parse and handle all of
the outdated entries again that end up being cleared anyway
- It is ensured that the control file doesn't rely on the existence
of a playlist file anymore after the playlist has been cleared
- We can reset the playlist's file name, which should make it less
likely for the user to overwrite their previous (now unconnected)
playlist that was still displayed in the Save dialog
- Unrelated bookmarks for the previous playlist aren't displayed
anymore
- Improved consistency with existing behavior when the "Keep
Current Track When Replacing Playlist" was disabled.
Change-Id: I41a89295bbac878807d65db9cf67b8a485daf0e5
Removed check that was introduced in 54e6bafa. This check doesn't work in WPS as BUTTON_NONE actions come while you still have button pressed. I believe the proper fix for this is already commited in c354e0bd.
Fixes FS#13370
Change-Id: I86e92c296c0bfa42caaed9cb3540e311630daf9c
Fixes ignored button press in yes/no screen.
It depends on keymapping - this issue happens if action before wait_for_release is mapped on release action. Something like:
{ ACTION_STD_OK, BUTTON_SELECT|BUTTON_REL, BUTTON_SELECT }
Change-Id: Idc6a57ef7a7daf75c21c9887e07fbefc814b6ae3
ipod6g was configured with SECTOR_SIZE of 4096, but this ATA driver
unconditionally translated these to 512B operations on the actual
storage device.
Rockbox's storage layer already has robust support for "logical sectors
larger than physical storage sectors" through use of
MAX_LOG_SECTOR_SIZE. So switch to that mechanism, allowing the ipod6g
ATA driver to be simplified.
If we want to support drives with physical sector sizes > 512B, then
we need to port the MAX_PHYS_SECTOR_SIZE logic from the primary ATA driver.
Additional changes:
* Simplify MWDMA/UDMA selection logic
* Report CE-ATA mode in debug menu
* Use LBA48 commands only if drive is over 128GiB.
* Drop default sleep/poweroff time from 20s to 7s (matching main ATA driver)
Finally, the bulk of the changes are the first phase of a badly needed
style cleanup that made reading this driver a lot harder than it should
be. I intend to split this into a separate patch.
Change-Id: I2feca9fd319c8d6cfb3c2610208970428d2fa947
And fix up all the problems I've found so far.
...This will undoubtedly introduce a pile of new warnings.
Change-Id: I868de507a0e9790f289676c198e2977c26755f22
Since commit e0df995 storage_disk_is_active may be 0
even if there is no disk that needs to be spun up or
device to power on, so it doesn't really make sense
to check for it, anymore, in order to decide whether
to display the loading indicator.
For remaining devices with spinning disks, the noise
or vibration of the disk spinning up may serve as a
sufficient signal when loading a plugin, that the
device isn't frozen. Plus, for the tagtree, search
progress is displayed after 0.5s anyway.
Change-Id: I5791725e2388d7113818a358204968d8a4e6f843
Added jpeg decoder jpegp.c using RAINBOW lib. Currently enabled only for pictures not supported by old decoder (as old decoder more optimized for low mem targets)
Someone TODO:
* Old decoder has optimized downscale logic which new decoder doesn't have (it gives big difference in required memory and time for decoding). This logic should be ported/adapted if possible.
* Add smooth downscaling.
* Grayscale support
Change-Id: Ie96bc62848b51cc6a3942f8e069ec6ab02dc1c56
Added unmodified files from RAINBOW library by Attila Tarpai
Full sources:
https://github.com/Halicery/vc_rainbow
Change-Id: I356486b6a332aa3f610ddcae57f8a2044653b051
Code has no effect since commit a0e95c8.
Functionality is now handled by the playlist_insert_context_add function
Change-Id: Ie91f605bd7a7d03556fa70d195a06bc55866741d
If you have say 1000 playlist entries and select the 1001 song in the directory
dirplay loads tracks 1-1000 shuffles them and track 1001 is never heard from again
Instead start at the file and loop through the directory mod dir len
Change-Id: Ieded5decdc1f7c44b1be8491dbd4f359ae21f79a
Hint: this is a good way to not wait on dirplay to load a ton of tracks
On usb plug system_flush() gets called before the other
threads get a chance to ACK the insert
system_flush() calls playlist_shutdown() (amongst other things)
playlist_shutdown closes the control file
the audio thread acks USB insert
audio_stop_playback is called which now can't look up the
filename from the now closed handle for control the control file
I left the guard for checking for USB insert but it appears to be
fine without it
Change-Id: I935dbf7aed38d4a57413c0063ad953f427e9b3bb
I forgot we had duplicated code between playlist.c and tagtree.c this saves
a bit of space and should speed up adding tracks a bit
further I noticed a buf here where there was the potential to return without closing
the opened track search
Change-Id: I15ed8447fc4fe13de5bfeb9fbb59b151e2fbf36a
with our large voice file being loaded in its entirety to the buffer
there isn't enough room to allocate the required pcm buffer
well prior to this patch we looked for 1k free to allow the talk buffer
to be given away
well the pcm buffer expects something like 5-600 kb on the clipzip
and there is 1k allocatable but not 300 more
so instead get the required pcm buffer size and check against that
Change-Id: I40a056e4170c37bc3429f0cb37af221ae7f812e5
<..> gets interpreted as a drive/volume ID, which has special voicing rules.
(this is especially visible in the DB browser)
Change-Id: I7c2598004a4e58451267d77f786eb52f7c09bd3f
