Hi Marek, >> 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. Regards Manuel
