At Tue, 02 Feb 2010 11:08:10 +0100, Daniel Glöckner wrote:
On 01/28/2010 12:12 AM, Eliot Blennerhassett wrote:
I wonder if a patch implementing float ctl elements would be accepted? Note that the floats are not manipulated in the kernel at all, the values are just passed through from the hardware to userspace (?)
Adding something like:
#define SNDRV_CTL_ELEM_TYPE_FLOAT ((__force snd_ctl_elem_type_t) 7)
struct snd_ctl_elem_info { ... union { struct { float min; /* R: minimum value */ float max; /* R: maximum value */ float step; /* R: step (0 variable) */ } float; ... }
struct snd_ctl_elem_value { union { union { float value[128]; } float;
I see several issues here. There might be some day an architecture where float is not the IEEE 754 single precision type. Or there might be a compiler that insists on using floating point instructions to read those values from memory. Therefore I prefer __s32 here instead of float.
Drivers would have to check if a passed control value is in the range [min, max] and filter out INFs and NANs. So one needs to implement an in-kernel version of C99's fpclassify and isgreater working on floating point values kept in integer variables for all drivers to use.
Alsa-lib may need to convert the IEEE floats to the native floats if they are not the same. Just look at the issues with double on ARM. There the order of the two 32 bit halves in memory depends on the ABI IIRC.
Well, I think you see way too far unnecessarily :)
In the kernel level, we won't handle any FP operations. If any, the driver could, but it should be a specific way.
thanks,
Takashi