Scrollstrip (as well as scrollwheel on ipods/sansas) works like
quadrature encoder. The states of input lines are tracked by the
gpio ISR and when the sequence is correct, appropriate button
event is pushed to the button queue directly. The downside of
this implementation is that scrollstrip doesn't emit _REL
events which has some weird consequences. For the scrollwheels
some hack have been crafted in action system to accomodate for
this. I don't like this approach. IMO the correct fix is to
properly emit _REL event when the user stops interacting with
the device or reverses the direction of the move. This patch
implements timeout which forces to emit _REL when expired.
Change-Id: I588ac5810dd2ab00c68935d23a62979cb1c2a912
Reading from /dev/r0Btn only allowed to read one button at a time. Reading GPIO
directly via ioctl() doesn't have this limitation.
This adds a more complete GPIO list also.
Change-Id: If47b0846472f0817305dbf930731255f875e0269
Author: Lorenzo Miori
Retrieve the processes running at startup and compare with a list of
potentially problematic ones. Right now this is Itunes which is known to be
able to cause problems when trying to install the bootloader on an Ipod. No
user notification yet.
This adds the implementation for Windows.
Change-Id: I5ce8a85da52e0ed8f523b5ae6fb5d8f14f6a14c9
Change the none action return value so the various action layers don't get confused by ACTION_TOUCHSCREEN return codes which shouldn't be happening (i.e when a long press region overlaps a short press region whihc has the none action)
Change-Id: I63db2c0b49597ada2c5ebd0ef98e99aeef4f522a
The SSND bit is intended to be right after the t_aiff-sized header.
Someone got cast vs + precedence rules wrong here.
Change-Id: Iccec75043ed5e35724331f9833b24f7e3b90c447
It's not useful as it means we test code at a different -O level than
we run it at.
Fixes build errors caused by gcc 4.3. Fix some warnings
the change would introduce as well.
Change-Id: Id9ff31dc08694b0bfc5272f5e690c41f7918ed22
Example: for a file asm/foo.c, make will look for asm/arm/foo.[cS] and
compile it if found. If not found it'll fall back to asm/foo.c.
Also introduce new ARCH make variable. This is automatically detected by
configure. It is distinct from CPU since CPU defines the dir used for
the target tree (i.e. firmware/target/X, so it can be "hosted").
ARCH really has the target isa and can be x86 for sims/raaa too.
Change-Id: I18e5d2b7b7bbc2ad2be551a74a0fcae5ffbcbf8b
This dir is suitable for stuff that doesn't fit the target tree, e.g. because
it also builds on hosted or otherwise. It also has a generic subfolder for
fallback C implementations so that not all archs need to provide asm files.
SOURCES should only contain "foo.c" where foo.c includes the specific
<arch>/foo.c files from the subdirs using the preprocessor. This way automatic
selection of asm versions or generic C verion is possible.
For the start, the thread support files are moved, since ASM threads can
be used on hosted platforms as well. Since core_sleep() remains platform
specific it's moved to the corresponding system.h headers.
Change-Id: Iebff272f3407a6eaafeb7656ceb0ae9eca3f7cb9
Using the stack pointer for anything else than pointing to the
current stack can have in very bad effects, especially on hosted
platforms (e.g. when mixed with signals). Remove this at a
neglible performance cost.
Change-Id: I9545d701bd13c32456c224b87c708d907880c0ff
Core, codecs and plugins link it separately so this gets rid of SOURCES trickery.
Don't build it for hosted targets.
Change-Id: If15ef90e93cd218a4352ae8e89eea95d3122452f
Using the stack pointer for anything else than pointing to the
current stack can have in very bad effects, especially on hosted
platforms (e.g. when mixed with signals). Remove this at
very slight performance cost.
Signals are by default executed on the user stack, i.e. the stack of
the currently active thread. This has two problems:
1) The stack size of the current stack is likely insufficient (unless
using sigaltstack threads) because our stack sizes are normally
below MINSIGSTKSIZE which is needed to deliver a signal.
2) Some of our asm code does nasty tricks with the stack pointer. When a
signal comes in during this bad things can happen, e.g. random memory
being overwritten or simply a crash.
Using a well defined stack fixes this. This is comparable with the
separate irq stack on native targets.
The debug screen gets un-smoothed battery status via battery_read_info().
The level and runtime that is normally presented to the user needs to be
based on smoothed voltage.
Change-Id: Icb448853973aa1d5832e9094176938cfa12b2e48
