Make audio(9) get_props() optional, remove it from duplex drivers

The property bits of audio(9) are obsolete and ought to be removed
completely.

sys/dev/audio.c:audio_open() currently uses get_prop

Make audio(9) get_props() optional, remove it from duplex drivers

The property bits of audio(9) are obsolete and ought to be removed
completely.

sys/dev/audio.c:audio_open() currently uses get_props() to bail out if
read *and* write was requested on a non-duplex driver.

Drivers that currently support playing but not recording need adjustment
before the API can be cleaned up.

Drivers that advertise themselves as full duplex, i.e. those that always
return AUDIO_PROP_FULLDUPLEX unconditionally in their get_props() currently
always succeed this check.

As this is the only property, losen audio_open()'s DIAGNOSTIC check and only
do the duplex check if the driver provides get_props().

This allows for simple removal of get_props() from full-duplex drivers
without adding any other code or without changing functionality.

This includes all audio drivers under sys/dev/pci/ (maestro(4) being the
only unfinished exception here).

Other drivers as well as the API change can then follow in smaller diffs.

This builds on amd64, arm64, i386, macppc and sparc64.
amd64 with azalia(4) still plays, records as well as plays and records
at the same time on my X230 as tested with

$ aucat -i play.wav [-o rec.wav]

alpha and hppa tests by miod
OK ratchov miod

show more ...

Use C99 struct init for struct audio_hw_if

This audio(9) struct will lose a member, but drivers init their struct quite
inconsistently, most pre-C99 style.

Use C99 style everywhere, to get rid of a

Use C99 struct init for struct audio_hw_if

This audio(9) struct will lose a member, but drivers init their struct quite
inconsistently, most pre-C99 style.

Use C99 style everywhere, to get rid of all annoying differences and allow
for easy member removals/additions:
- don't change current order of members
- no explicit NULL members
- no comments or blank lines
- trailing comma in last member line

GENERIC.MP builds fine with this on arm64, amd64, i386 and sparc64.

macppc and alpha build-tested by miod
OK ratchov miod

show more ...

Constify struct {audio,midi,radio,video}_hw_if. No functional change.

ok mpi@ ratchov@ "More const is good" deraadt@

Constify struct cfattach.

ok miod@

Make room for a cookie argument passed to audio_attach_mi(). Currently
unused but intended to be used to correlate audio and wskbd devices.

ok ratchov@

Declare hw_{prod,serial,uuid,vendor,ver} in <sys/systm.h>.

OK deraadt@, mpi@

Move PowerBook5,4 audio from aoa(4) to snapper(4).

This adds the missing TAS3004 volume control. Before, I put my ear
near the speaker (to hear audio), because I had no way to turn up the
volume.

Move PowerBook5,4 audio from aoa(4) to snapper(4).

This adds the missing TAS3004 volume control. Before, I put my ear
near the speaker (to hear audio), because I had no way to turn up the
volume. Now, the default volume is much louder, so I use sndioctl(1)
to turn it down.

Check for the model string "PowerBook5,4". This model's device tree
has compatible = "AOAKeylargo" for the audio, doesn't show the TAS3004
in the same way as other models.

show more ...

Remove unused getdev() audio driver functions.

Remove drain(), query_encoding(), mappage() and get_default_params()
methods from all audio drivers and from the audio_if structure as they
are never called.

Do not do strncmp comparisons on dv_xname because longer device names which
look similar could arrive in the future. Instead, compare directly against
dv_cfdata->cf_driver->cd_name
Issue originally

Do not do strncmp comparisons on dv_xname because longer device names which
look similar could arrive in the future. Instead, compare directly against
dv_cfdata->cf_driver->cd_name
Issue originally spotted by miod

show more ...

input and volume twiddles
o set init data to match snapper_set_foo*
o set volume to 190 (audible compared to the default)
o set input to mic (most common usage)
ok jakemsr@

* use uint8_t instead of int to hold the value of an 8-bit register.
* for outputs.{bass,treble}, 0 dB corresponds to mixer value 128,
not 0.
* line-in is configured as the default recording source

* use uint8_t instead of int to hold the value of an 8-bit register.
* for outputs.{bass,treble}, 0 dB corresponds to mixer value 128,
not 0.
* line-in is configured as the default recording source; set
sc->sc_record_source accordingly.
* add missing register to initialization code.

from Marco (marco2z at arsystel com), thanks

testing/ok drahn@

show more ...

native default parameters for i2s devices instead of 8kHz
mulaw mono, which few can even do.

"Please just get this in." brad@

how about i commit what was actually approved? wrong tree, bad todd ;-(

o implement proper volume control table based on chipset docs
o attempt to make record work (but silence for now)
from drahn@, ok maja@, drahn@

allow low level audio drivers to specify a default sample format,
instead of 8-bit mono mulaw @ 8kHz.

this is just the infrastructure; no drivers are specifying a default
yet.

ok ratchov@, deanna@

rename drivers with numbers in them; ok gwk drahn

Fix totally bogus previous commit.

Make sure we match the correct driver for newer macppc systems.
tested by xsa@, ok joris@, brad@

some driver cleanup, ANSI/KNF and more consistency between the drivers.

ok joris@

update datasheet URL.

- add needed bass & treble glue in i2s;
- add support for bass & treble in snapper;

ok drahn@

add aoa audio support, found in several macppc machines
ok drahn@

kill unneeded node argument in snapper_init()
ok drahn@

add an i2s framework, which can be reused in new audio drivers
for macppc, as most modern Apple machines have i2s-based audio.

also let snapper use i2s.c right away;

tested by Antoine Jacoutot, dra

add an i2s framework, which can be reused in new audio drivers
for macppc, as most modern Apple machines have i2s-based audio.

also let snapper use i2s.c right away;

tested by Antoine Jacoutot, drahn@ and kettenis@
"yes, commit!" drahn@, ok kettenis@

show more ...