1 |
Jakub Moc wrote: |
2 |
> Uhm... Sorry to see this issue brought up yet again. Just a couple of |
3 |
> brief notes: |
4 |
> |
5 |
> - The in-kernel drivers seriously are not an equivalent alternative, let |
6 |
> alone the preferred one, for stuff like hda-intel or any similar drivers |
7 |
> that are under permanent heavy development, at least for now. |
8 |
> |
9 |
> - This is not a duplicated maintenance effort, it's simply needed to |
10 |
> have external alsa-drivers ebuilds, and it's needed to have them |
11 |
> supported as ALSA upstream won't accept bugs about in-kernel drivers. |
12 |
> |
13 |
> - The two are basically different branches, and it's *not* about whether |
14 |
> the code is newer or older in one or the other at all. |
15 |
|
16 |
|
17 |
I completely disagree with your assessment of the in-kernel hda-intel |
18 |
state. My workstation uses one of those (labelled nVidia MCP 55, for the |
19 |
curious), and my experiences with in-kernel ALSA have been nothing but |
20 |
positive with the intel audio, whether compiled or as modules. |
21 |
|
22 |
For the record, the kernel and alsa team have gone back and forth on |
23 |
this for a long time -- and it's always been my task to update the ALSA |
24 |
guide for whichever "wins", or at least that's how it's been lately. The |
25 |
thing about ALSA upstream not accepting certain bugs -- I'm not sure |
26 |
Diego ever mentioned any such thing; is this really true? |
27 |
|
28 |
At the very least, this should cut down on spurious bug reports on our |
29 |
own bugzilla. However, it'd be nice from the point of view of the GDP if |
30 |
the kernel and ALSA maintainers would decide, once and for all, what |
31 |
should be supported and what shouldn't, whether in-kernel or |
32 |
alsa-drivers is recommended. Because it's been going back and forth for |
33 |
years as to which gets priority in the docs. Pick something for the |
34 |
users to install and stick with it, please. |