Improve Volume Wheel Daemon (Bounty!)


gpsqueeek

Very Active Member
Joined
Nov 21, 2016
Messages
142
Age
40
One thing that came to my mind is: Do we want to use the wheel exclusive for volume? As said before i already experimented with it as gaming control, i can also see it being used for backlight/LED brightness and such.
I propose having a lock in userspace that programs can create whenever they want to abuse the wheel.
In that case, maybe using the shoulder buttons as alt keys could do the wakeup of the polling : shift + wheel = sound, ctrl + wheel = LED brightness, etc...?
 

KidPaddle

Very Active Member
Joined
May 14, 2006
Messages
419
Location
Germany
@docbroke
I'm not a bash guru, but I usually compare two values with a query like "if [ ABS("$VOL" - "$LASTVOL") > XXXX ]" so that only changes with a difference greater than XXX satisfy the condition. This makes it possible to suppress "fluctuations" when reading the volume value.

I know that the function ABS does not exist in Bash.

Thomas
 

docbroke

Banned
Joined
Feb 21, 2019
Messages
564
Age
40
Location
India
Yes that may be possible with built in bash functions, but someone need to test this in pyra, so that we may find what kind of fluctuations volumewheel is throwing at.
Another thing to note is, that part of script is just copied from original volumed created by ED. I have only modified to use inotifywait with while loop. I will try to update other parts of the script when I get time.
 

Letalis Sonus

Advanced Member
Joined
Mar 5, 2009
Messages
1,478
inotify does not work on device nodes, for these are not real files. It is likely that reading from it actually triggers retrieving the value from the hardware, so you wouldn't have any change event to look out for anyway.

All changes to actual files have to go through the filesystem subsystem, which makes it easy to detect these change. Hardware register on the other hand can change their value all the time without involving any software.
 
Last edited:

Djoga'Ro

moonstruck
Joined
Apr 3, 2016
Messages
1,957
Has making use of the LITTLEs been tried, yet? Maybe one could have one of those run constantly at low frequency and have it process all the pollings and watchdoggies we come up with. It could be something generic that fetches scripts or binaries from a dedicated directory, or it creates a socket to which jobs can be send or whatever?
 

Letalis Sonus

Advanced Member
Joined
Mar 5, 2009
Messages
1,478
Has making use of the LITTLEs been tried, yet?
LITTLE cores implement the same basic instruction set as well as an MMU so you can simply switch over tasks to them, which is not the case with Cortex-M.

Whatever you want to run on them runs on bare metal without being directly managed by the Linux kernel. It would be more fitting to just call them co-processors.
 

Djoga'Ro

moonstruck
Joined
Apr 3, 2016
Messages
1,957
Do they themselves have access to the hardware resources or can they only communicate with the other cores?
 

netcat

Very Active Member
Joined
May 3, 2016
Messages
317
Location
city of thieves
I don't want to be the party pooper but any solution involving polling is a hack. It's simply not appropriate for a battery powered device.

The solution might involve...... a device driver. And interrupt handler. (I'm optimistic interrupts are emitted)

What does /proc/interrupts say?
 

Wally

I am a banana!
Staff member
Joined
Jan 31, 2006
Messages
3,124
Age
34
Location
Melbourne, Australia
I also think as part of this we need to take into consideration those who wear bluetooth headsets without volume controls as some may want to use the volume wheel to do stuff too :D
 

docbroke

Banned
Joined
Feb 21, 2019
Messages
564
Age
40
Location
India
inotify does not work on device nodes, for these are not real files. It is likely that reading from it actually triggers retrieving the value from the hardware, so you wouldn't have any change event to look out for anyway.

All changes to actual files have to go through the filesystem subsystem, which makes it easy to detect these change. Hardware register on the other hand can change their value all the time without involving any software.
Yes indeed, inotify is out.
 

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
221
The bash script is not what's currently used on the pyra, before anyone spends a lot of time trying to improve it.

This is the real volumed at the moment :


Doing some basic improvements to that is very simple, but as said before, I'd prefer a more generic iio addition to the input daemon to handle it.
( which is here : https://dev.pyra-handheld.com/packages/funkeymonkey-pyrainput )
 

Binky

Death's Steed
Staff member
Joined
May 28, 2003
Messages
6,989
Location
16A (TO)
In that case, maybe using the shoulder buttons as alt keys could do the wakeup of the polling : shift + wheel = sound, ctrl + wheel = LED brightness, etc...?
At what level is the wheel position absolute?

If the wheel is a potentiometer connected to an ADC, using modifiers would lead to some odd behaviour. If you set the volume, then pressed the modifier for display brightness, the brightness would jump to whatever you set the volume to. When you released it, the volume would jump to your new brightness setting!
 

elw3

ƐʍlƎ
Joined
Aug 10, 2010
Messages
1,594
Finding actual useful usage scenarios for other purposes might be a tad hard. The stop notch is a hindrance.
Without one it would be much more flexible. Since we can easily calculate the turning direction there is absolutely no need to map the volume to the actual position of the wheel nor to taking one full turn as a 100% value.
Imagine the case where a random software sets the volume to high while the actual wheel is set to 0, now to turn the volume down again we need to first turn it up too using the wheel because the daemon only kicks in and sets the volume when the wheel is turned. Without a stop notch we could simply turn.

Why again do we have such strange analogue>digital cross breed anyway? Have we really voted for that?
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
11,024
Why again do we have such strange analogue>digital cross breed anyway? Have we really voted for that?
I'm not sure how this all evolved, but it seemed a bit convoluted back when it was discussed. I think many including myself just felt a regular Analog volume wheel would just fine enough and maybe adding in digital controls were felt was needed and that's how this started? I think once the digital control were implemented the volume wheel should have been just changed to an encoder wheel.
 

elw3

ƐʍlƎ
Joined
Aug 10, 2010
Messages
1,594
Well lets not forget that it feels nice while saving us from crackling....
But after all this messing with it i may just using only keys for volume, after all we have enough of them.
And maybe run a wheel daemon only if the lid is closed + music running.
 

Neelix

Insecticidal Maniac
Joined
Jan 8, 2011
Messages
3,264
Location
Melbourne, Australia
Finding actual useful usage scenarios for other purposes might be a tad hard. The stop notch is a hindrance.
Without one it would be much more flexible. Since we can easily calculate the turning direction there is absolutely no need to map the volume to the actual position of the wheel nor to taking one full turn as a 100% value.
Imagine the case where a random software sets the volume to high while the actual wheel is set to 0, now to turn the volume down again we need to first turn it up too using the wheel because the daemon only kicks in and sets the volume when the wheel is turned. Without a stop notch we could simply turn.

Why again do we have such strange analogue>digital cross breed anyway? Have we really voted for that?

There is no "stop notch", it's a potentiometer, not an encoder wheel. Turning the wheel sets an absolute value and the device can only detect the turning direction by noting the change in value, not the other way around. Perhaps there would have been advantages to using an encoder wheel instead, but that decision was made a long time ago, and it's not something that can now just be changed on a whim.

- Neelix
 

elw3

ƐʍlƎ
Joined
Aug 10, 2010
Messages
1,594
You seem to have mixed booth up, its the other way around. Encoder wheels usually dont have a stop. Potentiometers have or have not, depending on design, and for a wheel it does not need to have one.
On a potentiometer the turning direction is implied in the very readout, its just questioning if the next value is bigger or smaller than the previous (with a special for the 0 to Max step).

I dont think an encoder wheel will give us any benefit here. Likely it will be the worse choice.
 

ouzle

Very Active Member
Joined
Jun 3, 2019
Messages
127
Location
England
The advantage of an encoder wheel is that it gives out digital pulses that can trigger an interrupt. The CPU enjoys a long, lazy sleep until the encoder moves. The second pulse we receive (on the 2nd encoder wire) tells us the direction of motion.

For the potentiometer, the driver asks the analogue to digital convertor (ADC) for a reading, then waits for an interrupt, then reads out the voltage.
 

Git1

Still Fresh
Joined
Dec 23, 2020
Messages
19
I think the confusion may be 'stop-notch' vs 'detents'. elw3's query was regarding limits of rotation angle. As I understand it though, I don't think there is any such thing as an 'endless' pot. Even multi-turn pots can only be rotated so many times in each direction.

So if the volume wheel is indeed a pot it could be assumed it could only be rotated so far in each direction yes?
 
Top