In absolute pointing mode, the quickscreen now accepts
a touch anywhere in the middle third of the screen edge
to trigger an item, and pressing anywhere else on the
'grid' will exit -- the same as how 3x3 mode works.
Previously it required a touch inside the text viewport
to trigger an item, and exited after any touch outside
the viewports. This made it very difficult to use since
the text viewports are too small to reliably touch.
Change-Id: I971eaeb4a2c67bebef3d7b070a29b897df07b8e7
In absolute pointing mode the keyboard is virtually unusable since
the keys are too tiny (just 8x6). There are other issues too: for
example putting the keys on top doesn't make sense on touchscreens
and there is a lot of empty space in between keys that serves no
real purpose.
Until these issues can be addressed properly simply force 3x3 mode
when in the keyboard.
Change-Id: I3ea95ae479372f5b5f86ffcc2dbde10a03663820
Touch devices have physical buttons too, and these should be
subject to repeat acceleration. That feature was disabled for
the sake of better touch event responsiveness (apparently).
So, re-enable the acceleration feature & add a special case
to exempt BUTTON_TOUCHSCREEN from acceleration.
Change-Id: I9e097e27457fbd6b824f098e8b325ff35c59dde4
The behavior of the top/bottom items is not intuitive when used
with settings like volume or brightness -- pressing up will
actually *decrease* the setting, and down will increase it.
This patch inverts the direction, so the top item will increase
the setting.
The reason for this is that historically, the quickscreen seems
to have had only 3 directions -- left, right, and bottom. Bottom
therefore selected the next value, and when top was introduced
it selected the previous value.
The counter-intuitive nature of this was later reported as a bug
on the Fuze V2 and got an incorrect fix (commit 2271995517) under
the assumption that ASCENDING_INT_SETTINGS was the issue.
Change-Id: I3be92534469cea4f5efd81ab024288c052367411
Add the 6th format specifier for the 6th parameter and show seconds,
too. Most radio stations will update once per minute only, but still...
Change-Id: Ia878bc001c903112df3ed336df260e30eae68e3b
Based on a patch by Amaury Pouly which was based on a patch from Ryan
Hitchman.
I mainly moved the code for polling into the tuner driver so it can be
reused by other targets. I added the CONFIG parameter for the polling
frequency (in ticks) to save energy. Also, I did some minor cleanups.
Change-Id: I95a62e7e1e42c62dbf47ecb27a3b312a42be62aa
All three X1000 native targets turned out to have a very
similar boot configuration and used a nearly identical
makefile. Eliminate this duplication by moving the logic
into the main makefile.
Change-Id: I13044b9675c0abd605b8accdb2fee4f54549b020
Due to how the old control request API worked, the request
pointer (and the pointed-to contents) passed by the driver
must remain valid for the lifetime of the request.
The buffered copy wasn't used consistently anyway, so it
should be safe to just get rid of it.
(This only affects the old API compatibility layer.)
Change-Id: I00294c718a7515a91b84f7c7cae5220c73aa5960
In the old API, usb_core_transfer_complete() would ignore
any completions on EP0. The legacy control API will also
ignore most completions on EP0, but it only did so after
filling in the completion event.
If the driver submits a spurious completion on EP0, then
this could clobber a previously queued completion event.
Fix this by deciding whether to ignore the completion
*before* modifying the event data.
Change-Id: I68526898a96efa594ada4e94bb6851aaaf12e92a
Should prevent a delay, dropouts and memory corruption
that can occur when applying a skin while music is playing
Change-Id: Ic2c8fd788117a7d797fb315a36e366a2e34d3460
When running and USB plugged announce status ack'd the USB and then un intentionally fell through to EV_EXIT
this caused the thread to exit but not the TSR hook
Now: plugin keeps track of usb status and doesn't announce till usb is unplugged again
on unplug the start-up beep is played to announce its presence
announce_status on startup blocks usb since USB handling is done in the thread that hasn't started yet
Now: don't start if USB is plugged
Plugin now beeps if it couldn't play the announcement excpept for missing voice file unfortunately
Change-Id: I69cf7e687508ce02358432e7bd1adc27c78c4072
Appears to return 0 until the axp has (presumably) completed
its first real measurement.
Note about erosq: keep the power_inint() delay large to ensure
nothing breaks in the bootloader for the time being.
Change-Id: I444e858207cc401c42f1e6ceacf067ad543d4ff8
Allows user to decide whether scrolling lists will wrap around
to the opposite end after the first or last item has been reached.
Change-Id: I22156812cf4c857ddc4b6c48c1cef013b1985260
handles the folder selection for autoresume paths and database paths
folder_select uses the pluginbuf to build the directory tree
hopefully having it as a plugin will make it stop corrupting
TSR plugins like battery_bench and announce_status
I left the original include and source in the gui directory for now
there are currently no other users..
Change-Id: If40ccb5a2bec4286a0616c10dfa7e1479a592808
Reverts to the behavior pre-commit dfff938 with the additional change
that it will not skip the last entry.
Change-Id: Ia03da03b1bdccd8a9591548cd0ca9f58f4767947
Each time PictureFlow was launched, it would rebuild the
album artwork cache from the beginning.
Depending on the number of albums, this could take a while
and resulted in choppy scrolling.
PictureFlow will now remember how many albums have been
inspected already, and only rescan and write new artwork
when the album index cache gets updated or rebuilt.
Change-Id: Icd78106dacea44b80904ac609caa355cc9113168
- Shortcuts Menu would delete SHORTCUT_TIME shortcuts
when deleting any other shortcut.
- Shortcuts would crash or show wrong number of items
after deleting a shortcut and then launching a shortcut
when simplelist_show_list was executed again.
Change-Id: Ia87c94a364c516fd662cb3c7d245c566a3fa91ca
| with some code refactoring we can eliminate the static
char buffer in get_full_path()
I'm guessing making the functions recursive prompted the static buffer
I don't see any reason we can't just pass the same buffer
|
During tested I noted failure after buffer was full
-- splash added for buffer full notification
added some logic to not add partial entries and try to find a
| selected item that will fit in the remaing buffer
------------------------------------------------------------------------
While looking through the source I noticed a few potential
pitfalls with the current code.
Namely the stack allocated temporary buffer
sized to setting_len.
I also noted the rigid vect[32] with the timeless --
/* 32 separate folders should be Enough For Everybody(TM) */
and decided to make it a bit more robust
The saved items are hashed with crc32 on all the paths
and a hashed_len is kept to aid in the buffer full message before the
user actually goes to save the changes
(assuming they even get the message)
In the old code, buffer might be the same since it ran out of
space and didn't get their later selections
the hashed_len could easily be turned into a way to get a needed buffer
size as well for someone in the future just pass a really large maxlen
I made get_full_path non recursive since it liked to blow the stack
while embedded in all the other recursive calls making it a pain to debug
(the real reason the buffer was static?)
traverse first from the current folder to root mutating the
parent pointers to point at the previous child
next traverse back to the folder unmutating & taking names on the way
Folder depth is now uint16 65535 levels is probably excessive
children_count is also uint16 as well
I made the first folders below root '/' stay below root
instead of shifting since the horizontal real estate is limited
slightly smaller than it began but hopefully faster & more reliable
Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
The address from the packet needs to be saved before sending
the response -- after the response the request being pointed
to could get overwritten. This used to be done correctly but
I unintentionally broke it when updating the handler to the
new control request API.
Change-Id: I9b11548baf20dce44a82301731405dc8e8f1cef3
Ive seen no ill effects having this disabled on target so
limit it to the sim to stop Address Sanitizer from dumping
on the extra byte read. the bad data is never used AFAICT
since the loop ends
Change-Id: I8cb54e9d1f8fe28747867d861a015edb3dbfa5ff
Because usb_core_legacy_control_request() is called by an
interrupt handler the global variables used to track the
current control request at the very least need to be volatile.
It might also be necessary to disable IRQs but I'm not sure
of that.
Change-Id: I0f0bb86d0ad63734e8d3c73cb1c52fedf5a98120
save to a .tmp file on save and rename on next load
I think this should pretty minimally invasive as the same file
still gets overwritten in subsequent attempts until it is loaded again
the save path is still static
so it won't cause issues holding up shutdown.
load might be a bit slower with the searching for tmp+current file
and renaming them
Plus there is now a backup of your last settings file
Change-Id: If95618b93a0ba7954d5d8cab1d6ea3f07e658509
we shouldn't need to save the last_screen unless the plugin were to
bypass the normal shutdown procedure
if its a crash do we really want to resume the plugin?
its it is intentional save the settings prior.
Change-Id: I994ed256e7b9e88add0c846825a39b298e2644dd
since the plugin browser now exits before running plugins
it has already loaded the dest data for the plugin
the plugin will be run from the root menu with the open_plugin run key
BUT, since the calls originated from the shortcuts menu
it overwrites the run key with its own
this patch allows the shortcuts menu to overwrite the dest
key as well so it can run the loaded plugin
Change-Id: I63912071d720df01c6fda25d92d9541818e52a43
recent changes broke shortcuts when they originated from the root menu
I mistakenly thought GO_TO_ROOT only happened at start and otherwise was
GO_TO_PREVIOUS
this commit also adds a few missing features for Start In Previous
to resume the last plugin running at shutdown
Additionally GO_TO_ROOT now overwrites the global last_screen so you can
return to the main menu on next startup
Change-Id: I86bf842616e25dc3d4f684ff9d476e6a5ba96b04
The onplay-context was previously not reset when using the playlist
viewer, which led to a bug if onplay() was last called in the context
of the database. If you then tried to insert songs into a dynamic
playlist using the playlist viewer, a selected track from the database
would be picked, instead of one from the displayed playlist, due to
special behavior of add_to_playlist() within the database context.
Change-Id: I727d96fc1bfb2454ed3535959c1b0044ff7d6359
now that the plugin browser is resumable
exit it before running plugins
this causes a problem with the open plugin
shortcuts that call other plugins
but its now handled in count limited loop
so plugins can run plugins in a chain
and overall with less overhead too..
the problem remaining --
the plugin exits on USB, returns to ROOT
the browser resumes the
directory next time you select plugins
making for an unwanted auto return
Change-Id: If401f698207cbae824e95d69a378f13456a5dee4
We have this nice event library laying around probably a few more places
we could use event callbacks
Change-Id: I9180fa9d78788d161f2587110644ca3e08df6f50
So that a “scroll left” button can be repurposed
for returning to the main menu when there is no
existing menu button mapping.
Change-Id: I38515943313f69cc3241b3f523c94ea012471b88
make the plugin browser remember the last item between invocations
this has bugged me for the longest time dealing with the plugin_menu
Fix a very old bug fix for reloading lang strings in the lang menu
FS#8117, sending multiple ENTER_MENU_ITEM callbacks from different
areas of the code makes it hard to keep track of where your callback
is originating
Change-Id: Ib0a61558c11ee4c772134378a7020ac0e10fc4ee
