Hardware events

Hardware events

[Rolf Theunissen]

Hello,

For some hardware devices (for instance the ThinkPad EC) the volume can 
be changed by (only) hardware buttons. Changes in the the hardware 
mixers are notified in the driver via the function "snd_ctl_notify" with 
the mask SNDRV_CLT_EVENT_MASK_VALUE.
For notification of volume changes to the users of the system, an OSD 
can be used. To implement such a OSD, it must be possible to respond to 
changes done by the hardware.

This raises the following question: is it possible to detect the events 
originating from the hardware in the functions that handle the callbacks 
(set via snd_mixer_elem_set_callback/snd_hctl_elem_set_callback)? This 
would allow to implement an OSD that only responds to the hardware 
buttons and that would ignore events originating from "software".

Thanks

Re: Hardware events

[Clemens Ladisch]

Rolf Theunissen wrote:
> For some hardware devices (for instance the ThinkPad EC) the volume can
> be changed by (only) hardware buttons.
> ...
> This raises the following question: is it possible to detect the events
> originating from the hardware in the functions that handle the callbacks
> (set via snd_mixer_elem_set_callback/snd_hctl_elem_set_callback)? This
> would allow to implement an OSD that only responds to the hardware
> buttons and that would ignore events originating from "software".

The control notifications are for all changes of the control.

If it is not possible to change the volume in software, then the driver
must not set the control to be writable.


Regards,
Clemens

Re: Hardware events

[Rolf Theunissen]

Clemens Ladisch wrote:
> Rolf Theunissen wrote:
>    
>> For some hardware devices (for instance the ThinkPad EC) the volume can
>> be changed by (only) hardware buttons.
>> ...
>> This raises the following question: is it possible to detect the events
>> originating from the hardware in the functions that handle the callbacks
>> (set via snd_mixer_elem_set_callback/snd_hctl_elem_set_callback)? This
>> would allow to implement an OSD that only responds to the hardware
>> buttons and that would ignore events originating from "software".
>>      
> The control notifications are for all changes of the control.
>
> If it is not possible to change the volume in software, then the driver
> must not set the control to be writable.
>
>
> Regards,
> Clemens
>    

The issue is not that the driver should be writable or not. Even, if the 
volume is read only, an OSD can be shown for any event. However when the 
volume can be set both in hardware and in software, the end-user will 
expect different behavior.
For instance, if the user changes the volume in a music player 
application, no OSD should be shown as this clutters the interface. But 
if the volume is changed from the hardware a OSD should be shown.

I don't know if a ticket should be opened for this issue.

Regards,
Rolf

Re: Hardware events

[Clemens Ladisch]

Rolf Theunissen wrote:
> Clemens Ladisch wrote:
>> The control notifications are for all changes of the control.
>>
>> If it is not possible to change the volume in software, then the driver
>> must not set the control to be writable.
> 
> The issue is not that the driver should be writable or not. Even, if the
> volume is read only, an OSD can be shown for any event. However when the
> volume can be set both in hardware and in software, the end-user will
> expect different behavior.

The control notifications are for all changes of the control.

If you want to treat hardware-originated changes differently, you have
to send an additional, different notification for the OSD tool.

Usually, such volume change buttons are just treated as input devices,
and software is then expected to change the actual mixer control, but
this doesn't work if the hardware affects the control directly.


Regards,
Clemens