mirror of
https://github.com/genodelabs/genode.git
synced 2024-12-27 09:12:32 +00:00
1336b0a751
The classes Genode::Mmio, Genode::Register_set, Genode::Attached_mmio, and Platform::Device::Mmio now receive a template parameter 'size_t SIZE'. In each type that derives from one of these classes, it is now statically checked that the range of each Genode::Register::Register- and Genode::Register_set::Register_array-deriving sub-type is within [0..SIZE). That said, SIZE is the minimum size of the memory region provided to the above mentioned Mmio classes in order to avoid page faults or memory corruption when accessing the registers and register arrays declared inside. Note, that the range end of a register array is not the end of the last item but the end of integer access that is used for accessing the last bit in the last item. The constructors of Genode::Mmio, Genode::Attached_mmio, and Platform::Device::Mmio now receive an argument 'Byte_range_ptr range' that is expected to be the range of the backing memory region. In each type that derives from on of these classes, it is now dynamically checked that 'range.num_bytes >= SIZE', thereby implementing the above mention protection against page faults and memory corruption. The rest of the commit adapts the code throughout the Genode Labs repositories regarding the changes. Note that for that code inside Core, the commits mostly uses a simplified approach by constructing MMIO objects with range [base..base+SIZE) and not with a mapping- or specification-related range size. This should be fixed in the future. Furthermore, there are types that derive from an MMIO class but don't declare any registers or register arrays (especially with Platform::Device::Mmio). In this case SIZE is set to 0. This way, the parameters must be actively corrected by someone who later wants to add registers or register arrays, plus the places can be easily found by grep'ing for Mmio<0>. Fix #4081 |
||
|---|---|---|
| .. | ||
| include/audio | ||
| lib | ||
| patches | ||
| ports | ||
| recipes | ||
| run | ||
| src | ||
| audio.list | ||
| README | ||
This repository contains device drivers ported from OpenBSD. Audio ##### The audio driver is ported from OpenBSD 7.3 and includes support for Intel HD Audio devices. The HDA driver works on real hardware and supposedly in VirtualBox. Usage and configuration ======================= You have to prepare the contrib sources for this repository by executing _./tool/ports/prepare_port dde_bsd_. Also you need to make sure to add the 'dde_bsd' repository to the REPOSITORIES variable in your 'etc/build.conf'. Reporting of the mixer state is enabled by adding the 'report_mixer' attribute to the drivers configuration and setting its value to 'yes'. The following snippets illustrates the format of the report: !<mixer_state> ! <mixer field="inputs.beep" value="108"/> ! <mixer field="outputs.hp_sense" value="plugged"/> ! <mixer field="outputs.master" value="128,128"/> ! <mixer field="outputs.mic_sense" value="unplugged"/> ! <mixer field="outputs.spkr_muters" value="hp,mic"/> !</mixer_state> The mixer state may expose other mixer fields as well, depending on the used sound card. The naming scheme of the attributes intentionally matches the naming scheme of OpenBSD's mixerctl(1) program. Each 'mixer' node can be used to configure the audio driver by using it in its configuration, e.g.: !<config report_mixer="yes"> ! <mixer field="outputs.master" value="255,255"/> !</config> This configuration will set the output volume to the highest possible value. Although it is now also possible to update the configuration at run-time it should not be done while the driver is currently playing or recording because it may provoke the generation of artefacts. The following configures the driver of playback and recording: ! <start name="audio_out_drv"> ! <resource name="RAM" quantum="8M"/> ! <provides> ! <service name="Audio_out"/> ! <service name="Audio_in"/> ! </provides> ! <config> ! <mixer field="outputs.master" value="255"/> ! <mixer field="record.enable" value="on"/> ! <mixer field="record.adc-0:1_source" value="mic3"/> ! <mixer field="record.volume" value="128"/> ! </config> ! </start> It is vital to enable recording by setting 'record.enable' to 'on' as otherwise only silence will be delievered to the Audio_in session. In addition to selecting the recording source, the playback as well as the recording volume are set. When a single value is given the same value is used for all channels. Depending on the used HDA device or rather the used codec the available fields might differ and a different recording source must be set for 'adc-0:1'. For example on a Thinkpad X220 the source must be set to 'mic3' to select the internal microphone. Information about the available mixers and settings in general may be obtained by setting the 'verbose' to 'yes' in the config node. Examples ======== Playback can be tested by executing the run script 'repos/dde_bsd/run/audio_out.run'. It will play a raw sample file in a loop. The file format is header less two channel float 32 at 44100 Hz. You may use the 'sox' utility to create such an audio file: ! sox -c 2 -r 44100 foo.wav foo.f32 Recording, on the other hand, can be tested by executing the run script 'repos/dde_bsd/run/audio_in.run'. It will use a simply audio monitor test component that records samples and plays them back immediately.