Improve Volume Wheel Daemon (Bounty!)

[gpsqueeek]

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]

@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]

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]

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.

 

[Djoga'Ro]

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]

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]

Do they themselves have access to the hardware resources or can they only communicate with the other cores?

 

[netcat]

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 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

 

[elw3]

Yes agreed. We should no read the files at all but directly feed the volume daemon into the kernel. Thats likely a work for several months.

 

[docbroke]

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]

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 :

pyra_volumed.c · master · packages / pyra-hacks · GitLab

Some hacks to quickly get around a few problems

dev.pyra-handheld.com

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]

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]

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]

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]

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]

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]

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]

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]

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?