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
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
I'm 98% sure that the "byteswapped" value I saw was due to another bug
(bad PIO timings on ipods leading to data corruption) and none of the
growing pile of identify device data files that I have include the
backwards one.
Change-Id: Iea47b7419b120a3c8a282b2e3a8f65b8965356ce
This is actually the root fix for the crash; the fix in
772eff8ca6 didn't restrict it to 2 channels, just sanity
checked the file vs MAX_CHANNELS.
Change-Id: If5a0a9b946a179ad47d6e7955f7c025de3aaaa0e
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
It's not clear that we've ever intended to support >2ch files, based on
'#define MAX_CHANNELS 2' and other logic that only seems to care about
mono vs not.
Change-Id: I15e92fb29cceef32e63fc3a821f6e96bbde930b6
This should be a no-op for .lang files, but it can matter when
generating talk clips, as those are based on the raw filename.
Change-Id: Ia449ae7668818e4bf093347fd0fb15fa5b67fa69
