Fuze+, native Sonys, and some of the Zens use 2K sectoring from
the partition/filesystem perspective, even though the underlying
storage used 512-byte sectoring.
Change-Id: I247d8cae2582c63ec1d4dda0fb225b1a25c8e16a
This allows a single build to support ATA drives with (eg) 512B and 4K
logical sector sizes. This is needed because ATA drives are user-
replaceable and we don't know what could get plugged in.
* Add disk_get_log_sector_size() API (no-op for non-ATA storage)
* Mostly a no-op if MAX_LOG_SECTOR_SIZE is not enabled
* Sanity-check that storage's logical sector size is not larger
than what we're built for
NOTE: Other layers (eg ATA, FAT, etc) still need to be made aware of this.
Change-Id: Id6183ef0573cb0778fa9a91302e600c3e710eebd
* Support varying-sized logical sectors in a single build, instead
of a hardcoded SECTOR_SIZE.
* Properly truncate READ CAPACITY(10) if drive has over 2^32 sectors
And fix potential alignment issues
* Properly truncate READ_FORMAT_CAPACITY if drive has over 2^32 sectors
* Support READ CAPACITY(16)
Change-Id: I744b8629131f9ede31e1a972a6700b2244f2e798
....It's specified in 16-bit words, not bytes. So multiply it by 2.
(This hasn't been a problem in practice as everything uses 512B logical
sectors so far..)
Change-Id: I0b1abd0f6184330f0b7f5c000c5ad547038f7c95
ata_disk_is_active() behavior with SSDs has reverted, so we want to keep this.
This reverts commit ef19fa4408.
Change-Id: I29f08617285747c17a52352bd7bba4069e71cde6
* 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
We moved to SDL2 but still had the SDL1 'sdl-config' executable
used in one place. Additionally, all comments and the help text
referenced the wrong executable name.
Change-Id: Ie2efa80d27be5f6391fc84e49e207aa2aac26e72
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
sizeof(...) has type size_t which is long unsigned int on amd64, and so
the conversion specifier d without length modifier isn't suitable. There
is the length modifier 'z' for size_t arguments, but this is only
available on Linux. So casting to unsigned long and using 'lu' is the
portable fix.
This fixes:
rkboottool.c:215: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’
This is just to display the frequency correctly in the debug menu and prepare
for future use of said divider
Change-Id: Ib4c80ec71b3300bdf17edf6cc590229f7640d0f5
I am maintaining rbutil in the Arch Linux [community] repo.
There is an on-going effort to remove desktop files from our
PKGBUILD tarballs by either pushing them upstream or creating
them at build time. Relevant bug report:
https://bugs.archlinux.org/task/23387
Change-Id: Ic40cbfe92cf81e33b566ee39e0afea9c6c5d2754
This information is available in the RDA5802N or RDA5807 datasheet. I suspect
that register SYSCONFIG6 is not actually used by the tuner. Based on an
obscure statement in the datasheet, I guess SYSCONFIG5 is a frequency in Khz
called freq_direct that offsets the lower band frequency (56/67 MHz) but
1) it is not enabled (FREQ_MODE=0) and 2) it is not clear if this offset is
really just to avoid interference (ie the RF and IF are simply shifted by this
amount) or an actual offset.
Change-Id: Ia469f5370aee7c8c3390324d0cef1193c64df755
The current code relies on the initial value of some RDS register(which is
documented) but this assumption will be broken when we start enabling RDS.
This commit changes the code to really read the chip ID, although it is more
involved.
Change-Id: I0ed630322a94523612d2f0297dbcbea5f869eb6d
This requires a small change to support headers without supports macros. This
generates much simpler macros but disable more advanced macros such as BF_SET,
BF_WR and friends.
Change-Id: Icb5470c3f3e816e83335b4ecfa465be6c26be007
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
We can't assume that album art file starts right after album art type (apparently it can contain also additional info like filename).
Related to FS#12576 (album art is now shown)
Change-Id: I68c7a1dc536ff13a47fb73ea84539b2f7a44265b
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
Now no matter how [de]normalized the input strings are, we will
normalize them to the best of our ability in what we use.
This adds a dependencey for Perl's Unicode::Normalize.
Change-Id: I13e275692ea33a463b19f3a499ea06ce1acbb44a
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
