On 5/15/23 17:24, Traut Manuel LCPF-CH wrote:
Hi Marek,
Hi,
I tend to not change existing user-space interfaces. I would prefer to have an additional event or using sysfs.
I am increasingly concerned about the race condition between change of volume (via sysfs) and frequency (via SND_TONE) . So I would be banking toward additional event, like SND_TONE_WITH_VOLUME or something along those lines.
SND_TONE_WITH_VOLUME is also ok from my side. But implementing some locking shall also be possible.
NOTE: This uses approach similar to [1], except it is much simpler.
[1]
https://patchwork.kernel.org/project/linux-input/cover/20230201152128
.614439-1-manuel.traut@xxxxxx/
This one is more complex, because the mapping between duty cycle and volume is not linear. Probably it depends also on the used beeper hardware which values are doing a significant change in volume. Therefore the patchset introduced a mapping between volume levels and duty cycle times in the device-tree to allow user-space applications to control the beeper volume hardware independently.
I wonder whether this mapping shouldn't be considered policy and left to userspace to deal with, instead of swamping the kernel or DT with it ?
How could a Linux distribution detect which mapping is required to be installed?
For me it seems to be easier to have the device-specific information in the device-tree.
The alternative might be to have volume in 0..65535 range (i.e. the top
16 MSbits) and be done with it, then the PWM subsystem is responsible
for mapping this to 0..50% of PWM duty cycle .
