Move the volume bar input handling to skin_touchsupport.c so
volume bars can be used in the .sbs as well as the .wps skin.
Change-Id: I018fa1c84f93b64d676b68e3bea63ddb9141e492
Fix the heuristic used for detecting a touch-enabled theme.
The old method assumes that volume bar and progress bar tags
are always auto-created, but this might not be true. Instead,
mark regions that originate from a %T tag as user-created and
check for those.
Change-Id: Iec732d299a2b4e298bef8069a68ff94e3b642703
This is necessary if you want to detect touches on the bar region
using %Tl conditionals. Suppressing the auto-created region and then
creating one manually using %T doesn't give exactly the same results
because user-defined touch regions can't yet specify padding.
Change-Id: I2f4bde8eb56ba89645c72f3cc9d4b2355b934abd
It's been possible to label touch areas since the v3.9 stable
release, but it was never documented in the manual, only the wiki.
Change-Id: I6b92ff1d19369c105dc3a90aa04f8763f18a4214
* Detection of 64-bit Arm v8-a
* Proper detection of integer division support
* always on v7-m, v8-a, v9-a, v8-m.main
* sometimes on v7-a, v7-r, v8-r
* never on v8-m.base v6-m, v6 and older "classic"
* tl;dr: Rely on toolchain preprocessor definition
For the most part these additional variations won't acutally work
for native target builds, but sane -A detection is needed for
"local" builds now. -R detection is left out as it's not likely
to matter.
Change-Id: I8f6a52edc4d14490fc00e2f487406eca701eef02
Simply knowing that a touchscreen is present isn't that useful for
themes. Having %Tp evaluate as true when in pointing mode and false
in 3x3 mode is better. For example, themes can change their layout
or hide touch UI elements when in 3x3 mode, or show a status icon.
Although a similar effect can be achieved with the %St tag it's
simpler to use %Tp for this purpose -- it can report the current
mode, not just the user preference.
Change-Id: Ie343c105970dca11864fa44c6a091ed8e9e35b3d
Seeking to the very end of the track with the touchscreen caused
rapid skipping through the playlist because each touch event
generates a separate seek operation, kind of like rapidly pressing
a physical button. Fix this bug by executing the seek operation
only for the release event.
Change-Id: Ic1080065a68e7cc2ba98e2f27293c954f2ec8fb2
Use the gesture API to improve reliability, and allow press and hold
to repeatedly increment or decrement a value like on button targets.
Change-Id: Ic01b7a0802c3dec9f1534f5dd11e006b28a875b6
Use the gesture API in the yes/no screen to suppress bogus
touches and generally improve reliability.
Change-Id: I44adf95255f07d81188fd249dc00a91519ca7b99
Make use of the new gesture API to overhaul list touch support.
This should fix most of the annoyances with touch navigation in
menus and make the touchscreen easier to use.
Change-Id: Ied300947fcf755e2810e9348496ed86eaf620669
Provide a default gesture object in the action system which will
be kept up to date with touch events automatically. This reduces
the boilerplate needed to handle touch input.
Change-Id: I76f51ac2c3e3a0da204707d62e91a175c5f8c76a
The touchscreen repeat interval effectively controls the report
rate of the touchscreen to the action code. Touch interactions
are smoother with a faster refresh rate, but the CPU needs to be
fast enough to keep up, or we risk queue overflows.
25fps is the minimum required to appear smooth, and probably all
targets will be able to handle the extra CPU load.
Change-Id: I96dcc80ea2ce8b915ff5682360c2e719b835388d
Add a cleaner API for reporting touch events and deprecate the old
action_get_touchscreen_press() API. The old API is now emulated by
using the new one internally.
Change-Id: I001378e66f9c81806f134f011420d671954fcde2
The only v7-a targets we have are built using the androidndk (with gcc
4.9) but it is possible to perform "self-hosted" builds for eg the
simulator or the sdlapp.
Where this gets messy is the considerable amount of inline arm
asm we have.
Native builds will need considerably more work to support
v7-a processors, but we have to start somewhere.
(Note that this contains parts of commit 508bfabe8, which had to
be reverted due to breakage)
Change-Id: Ia1c8e10d21a976c68fdaae58e4d776854b63186c
They haven't seen any work since 2013, and likely hasn't compiled in at
least a couple of releases -- not that we ever "released" anything for
these targets.
Futhermore, upstream for both has been effectively dead for about as
long, and there's been no user reports of these being used since 2017
(and even then only in passing).
It isn't worth the effort to triage their current state, much less
uplift into something supportable, while the maintenance burden of
keeping these things in-tree can be demonstrated by the diffstat.
Change-Id: Id93bd450679d1b75e2c74295b3ae1548cd241b24
The way the button driver reported touch events was problematic
and made it impossible to detect if a touch started or if it was
a continuation of an existing touch.
Now, the first detected touch event gets BUTTON_TOUCHSCREEN and
all subsequent touch events while the screen is pressed will get
the BUTTON_REPEAT bit set. When the screen is released the final
event will have the BUTTON_REL bit set.
Change-Id: Ia456a22b2180031555a82231c2af32576bc5f2cb
For touch targets and right-handed use it makes most sense to
put the scrollbar on the right so your finger doesn't get in
the way of the touchscreen. Sorry left-handed people!
Change-Id: I35cfd8aa3bee6eb638572c9ca592942c53188a50
This reverts commit 508bfabe83.
Reason for revert: Completely breaks builds made using Android toolchains. A different approach is necessary.
Change-Id: Ie8767f1f304c1313e8a539179bc33d1cc7032a3c
It seems that there are a couple of codecs that use assembly optimizations. Some of their instruction sequences are not valid Thumb code. To be able to compile them successfully on TI OMAP4430, ARM mode is forced on the codecs.
Change-Id: I932186177b540985e37cb3a5333943572da1c60a
This is a partial revert of a79bdaf46
It caused all sorts of build breakages for misc stuff like the dbtool,
which doesn't include any per-target build directories
Change-Id: I493a33c1859706679972e47c96196223415985d9
They are nearly entirely generic wrappers around ALSA controls, unique
per target, and are ripe for further consolidation.
Change-Id: I05e4a450e3e89e03616906601c4f8fa46200dff5
Several hosted targets read their battery state from a fixed
sysfs path. Get rid of the duplicated code by handling this
common case in power-linux.c.
Some targets use non-standard units in sysfs instead of the
typical microvolts / microamps, so allow the scale factors
to be overridden by the target.
Change-Id: I31dc4ffc7a2d2c066d00a74070f9f9849c1663d0
I didn't change the number of anything that would be consider "popular"
but the longnames are all unchanged so it's only muscle memory that will
be affected.
Change-Id: Ic34a2e01801b14e81d4f7c84633bf10fdcbc43c9
Our decade+old defaults are reported to trigger a failure on
one user's IHIFI770c and IHIFI960, but work on their HM-603.
Backing CAS latency off from 2 to 3 appears to be sufficient.
What's interesting is that on paper, CL=2 should be easily attainable
due to our max RAM clock of 100MHz, well within the worst-case timings
of the EM639165 SDRAM.
So as an experiment, this code can go back to CL=2 when we change the
CPU+RAM clock speeds. IF this still proves problematic, it will be
removed.
Change-Id: I4a8cfa0563c076e7f25d9599a19b454f590861cd
The introduction of a debounce interval for USB
status by event (see e75a3fb), often resulted in the
FiiO M3K crashing after disconnecting from USB.
Shortening the interval to 10ms appears to fix this,
or make a crash much less likely at the very least.
Change-Id: Ibf1f02779ab1704d9b1c86d39b21648a3e2c4e9d
Creative ZEN lost it's time when shutting down.
The bug was introduced with commit 7f282b9280 (g#2601),
followed by e3f6e9d9f6 (g#2616).
I guarded all persistent register writes with wait loops,
as described in the datasheet.
TODO:
test SONY_NWZE360 and SONY_NWZE370 targets
Change-Id: Ib38ab8691fd1c6e8d0771c1e2eca20dfeb6fc87f
Displaying the fonts as you select them is nice but IMO pretty wasteful
I think a few static bitmaps would probably suffice
I however don't feel like addressing this so lets just disable it, for now?
Change-Id: I882cc0c4129e99d8b2f4ac135301dc3906340bb7
The issue was the false case returning NULL for children elements
instead just ignore the false branch for everything but
SKIN_TOKEN_SUBLINE_TIMEOUT_HIDE
Change-Id: Ie0f4f51646faf116e563ab7e60d52d18759f4220
When Waveform mode was active, frequency changes during playback
(if set to "auto", or with USB audio active) weren't picked
up
Change-Id: Iebec7db951312b7dacff850e9554e1d06762ab3a
