some first impressions

[Mitch Bradley]

Apparently there is an alternative to calling amixer - you can use ALSA lib.

http://www.alsa-project.org/main/index.php/ALSA_Library_API

Jim Gettys wrote:
> Mitch,
>
> There are ALSA controls defined for the analog input features.  So we
> already have driver support.
>                            - Jim
>
>
> On Thu, 2007-08-16 at 09:24 -1000, Mitch Bradley wrote:
>   
>> Yoshiki Ohshima wrote:
>>     
>>>   Mitch,
>>>
>>>   
>>>       
>>>>>   Thank you.  As I wrote on http://dev.laptop.org/ticket/2800, what we
>>>>> would like to have is C functions.  Then, I can wrap them as Squeak
>>>>> primitives.  Probably I can just rip these functions from amixer, but
>>>>> if you can tell me which, that would be good!
>>>>>   
>>>>>       
>>>>>           
>>>> This is the relevant excerpt from the reference cited above.  The 
>>>> correspondence between this and C code should be obvious (os.system() -> 
>>>> system()), and it also implicitly answers the second question too.
>>>>     
>>>>         
>>>   Yes, I know. But calling system() is not quite nice in various ways.
>>> I'd rather would like to have a minimal C-code that can be a part of
>>> the Squeak VM.
>>>   
>>>       
>> The controls in question reside in registers that cannot be accessed 
>> directly from userland programs
>>
>> The mechanisms for accessing those registers are rather dependent on the 
>> programming environment and its facilities for interacting with the OS.
>>
>> The AC/DC control is the 0x02 bit in the Cs5536 GPIO register.    The 
>> GPIO output value register is a 32-bit register at location 0x1000 in 
>> I/O space. Conceptually, the operation you would have to perform is either:
>>
>>    outl(0x02, 0x1000);  // AC mode
>> or
>>   outl(0x02 << 16, 0x1000);   // DC mode
>>
>> The catch is that you can't do I/O space accesses from userland, unless
>>
>> a) You use iopl() to grant the process extra permissions
>> b) You use ioperm() to grant access to specific I/O registers (which 
>> doesn't work in this case because the register number is too high)
>> c) You access the I/O space via write() to /dev/port - which requires 
>> extra permissions to open.
>>
>> Which of these approaches is appropriate for your environement, I cannot 
>> guess.
>>
>> It might be nice if there were a driver to access the GPIO, but I didn't 
>> see one in a quick scan of the kernel source.
>>
>> The bias control is the 0x04 bit of codec register 0x76.  Accessing 
>> codec registers requires a complicated dance involving some protected 
>> (in the sense that they are not trivially accessible from userland) 
>> registers in the AC97 hardware block.
>>
>> As far as I know, the only extant C code for twiddling those registers 
>> is the alsamixer code, which I presume that you can read as easily as we 
>> can.
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>