> From: Damien Couderc <open...@petrocore.eu> > Date: Fri, 1 May 2020 18:24:12 +0200 > > Le 01/05/2020 à 17:30, Stuart Henderson a écrit : > > On 2020/05/01 17:16, Damien Couderc wrote: > >> Le 01/05/2020 à 15:01, Mark Kettenis a écrit : > >>>> Date: Fri, 1 May 2020 14:17:56 +0200 > >>>> From: Alexandre Ratchov <a...@caoua.org> > >>>> > >>>> On Fri, May 01, 2020 at 01:11:16PM +0200, Damien Couderc wrote: > >>>>> > >>>>> Speaking of the hdmi-only devices that were disabled in 2009: does the > >>>>> project still stand on this position in 2020? I made a quick search and > >>>>> it > >>>>> seems that more than half of the screens are audio capable now. I > >>>>> understand > >>>>> the defaults back in 2009, but now is it still true? > >>>> > >>>> There's nothing wrong with hdmi-only devices. As long as audio works > >>>> by default with no tweaks, nobody will object to re-enabling > >>>> them. AFAIK, this was the only reason to disable them. > >>> > >>> Right. The main issue was that by default we only send output to > >>> audio0. On many machines the audio device associated with the HDMI > >>> port appears before the audio device that is associated with the > >>> speakers and/or headphone jack on our laptops. Therefore by default > >>> audio would go to an unconnected HDMI. Just enabling digital-only > >>> devices would not work. > >>> > >>> There are a couple things we could do here. > >>> > >>> 1. Make sndiod(8) responsible for picking a default output device. > >> > >> I thought it was the case with the -f and -F options: > >> > >> -F device > >> Specify an alternate device to use. If it doesn't work, the > >> one > >> given with the last -f or -F options will be used. For > >> instance, > >> specifying a USB device following a PCI device allows sndiod > >> to > >> use the USB one preferably when it's connected and to fall > >> back > >> to the PCI one when it's disconnected. > >> > >> -f device > >> Add this sndio(7) audio device to devices used for playing > >> and/or > >> recording. Preceding per-device options (-aberwz) apply to > >> this > >> device. Sub-devices (-s) that are applied after will be > >> attached > >> to this device. Device mode and parameters are determined > >> from > >> sub-devices attached to it. > >> > >> So if I'm not wrong it could be possible to set the -f option with the > >> analog device and the -F option with the digital-only one. > > > > These flags are to cope with a new audio device connected at runtime, > > for example so you can set it to use audio1 if the device is available, > > otherwise use audio0. > > > > The problem with HDMI audio is that the device *is* available but the > > output often doesn't go anywhere. This mechanism doesn't help that case. > > It's possible to sense it the HDMI is connected or not like what you can > see with mixerctl: > > outputs.digital-out_sou=dac-0:1 > outputs.digital-out2_so=dac-2:3 > outputs.digital-out3_so=dac-4:5 > outputs.digital-out4_so=dac-6:7 > outputs.digital-out5_so=dac-8:9 > outputs.digital-out6_so=dac-10:11 > outputs.digital-out_sen=plugged > outputs.digital-out2_se=unplugged > outputs.digital-out3_se=unplugged > outputs.digital-out4_se=unplugged > outputs.digital-out5_se=unplugged > outputs.digital-out6_se=unplugged > record.enable=sysctl > > In this case, the digital-out sensor is plugged. > > That said, I tried my proposition and it's not working. I suspect it's > related to the fact that the digital-out sensor is not checked or > something related.
There are tentacles in amdgpu(4), inteldrm(4) and radeondrm(4) that probably need to be hooked up properly to make that work.
