Dne 10. 01. 20 v 10:56 Takashi Iwai napsal(a):
On Fri, 10 Jan 2020 10:43:26 +0100,
Jaroslav Kysela wrote:
Dne 18. 10. 19 v 9:38 Kai-Heng Feng napsal(a):
Nvidia proprietary driver doesn't support runtime power management, so
when a user only wants to use the integrated GPU, it's a common
dealing with a real struct device.
>>> - Better decoupling between gfx and audio side since registration is done
>>> at runtime.
>>> - We can attach drv private date which the audio driver needs.
>
> I think this would be another case where the interface framework[0]
&g
side waits until the gfx side has registered everything if it's not
>>>> there yet. I also haven't though about how the audio side could probe
>>>> for the right avsink node really ...
>>>
>>> Yes, I think doing it first in the gfx side makes sense, too.
>>>
>>>>>> - I agree that passing ELD and all the other information through
>>>>>> this new structure makes lot more sense than the current mess we
>>>>>> have with passing the ELD through some hardware buffer.
>>>>>
>>>>>> - Finally I think we should assign some identifier to this link
>>>>>> which will get exposed both on the drm side and in alsa, so that
>>>>>> userspace can figure out which display connects to which output.
>>>>>> With that media player could do the Right Thing and automatically
>>>>>> place the audio stream on the right pin in alsa.
>>>>>
>>>>> Is there something that blocks media player from doing the right thing
>>> now?
>>>>> For HD-Audio, the eld entries under /proc/asound/cardx expose the
>>>>> ELD info and can help user space to check if a monitor is usable on a
>>> pin.
>>>>> Current limitation is these eld entries cannot update if the audio
>>>>> controller is in D3, so we need the new infrastructure to notify
>>>>> audio driver to update them. But I'm not sure about embedded audio,
>>>>> maybe Takashi would like to share more info.
>>>>
>>>> ELD doesn't contain the serial number from the EDID, so if you have
>>>> two monitors of the same model userspace can't figure out which audio
>>>> output is connected to which screen.
>>>
>>> Right. And, comparing two different data just for knowing whether A
>>> and B are relevant is merely a pain.
>>
>> Thanks for clarification!
>> Maybe we can add output info (eg. display port number) to the eld entries
>> under /proc/asound/cardx. Is it okay?
>
> It's possible, but the proc file is just a help. It can't be the
> API. For accessing the information, we'll need some new API, or let
> inform via sysfs of the new device.
I agree here. From my view, the cleanest solution is to create an
universal API in the kernel for the shared state / binding information
and inter-communication. I believe, that other drivers may use this API
in the future like mentioned vga_switcheroo.
Jaroslav
>
>> And I have a question: how to assure the audio/gfx client find its right
>> peer?
>> On a x86 platform, there can be an integrated GPU and an discrete GPU. So
>> there can be two audio controllers and two GPUs.
>> We need to assure audio controller find the proper GPU, and vice versa.
>> Maybe we need the peer audio/gfx to register with a same identifier
>> (something like vendor ID) for peering.
>
> Yes, it's an open issue. So far, the binding with vga_switcheroo is
> done by a rough guess with PCI ID.
>
>
> Takashi
> ___
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
Jaroslav Kysela
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
