| 1 |
On Wed, Mar 28, 2007 at 04:49:25PM +0200, Jakub Moc wrote: |
| 2 |
> Daniel Drake napsal(a): |
| 3 |
> > Jakub Moc wrote: |
| 4 |
> >> - The in-kernel drivers seriously are not an equivalent alternative, let |
| 5 |
> >> alone the preferred one, for stuff like hda-intel or any similar drivers |
| 6 |
> >> that are under permanent heavy development, at least for now. |
| 7 |
> > |
| 8 |
> > If hda-intel (or any other driver) from the kernel sources does not work |
| 9 |
> > on your system then you should file a bug. Yes, there are drivers under |
| 10 |
> > heavily development, this also applies to many other kernel subsystems |
| 11 |
> > too. We live with it. It's not as bad as it sounds. |
| 12 |
> |
| 13 |
> It not only doesn't work for me, it doesn't work for majority of people |
| 14 |
> that have responded on this thread. So, something's wrong there I guess? :) |
| 15 |
Maybe because this thread is a lot more interesting for people that |
| 16 |
doesn't have working in-kernel drivers? For what it's worth I'm using |
| 17 |
in-kernel alsa drivers with hda-intel and it's always worked just fine |
| 18 |
for me. |
| 19 |
> |
| 20 |
> >> - This is not a duplicated maintenance effort, it's simply needed to |
| 21 |
> >> have external alsa-drivers ebuilds, and it's needed to have them |
| 22 |
> >> supported as ALSA upstream won't accept bugs about in-kernel drivers. |
| 23 |
> > |
| 24 |
> > That's not true. I have supported in-kernel ALSA drivers for a long time |
| 25 |
> > and have never seen this be the case. |
| 26 |
> |
| 27 |
> Hmmm, I'm not entirely sure what are you responding to here? What I said |
| 28 |
> was that "ALSA upstream won't accept bugs about in-kernel drivers" - now |
| 29 |
> how's that related to whether you (or kernel upstream) support them or not? |
| 30 |
Is it really important who supports it? I think most users would care |
| 31 |
about their drivers being supported or not instead of who supports them. |
| 32 |
> |
| 33 |
> Additionally - forcing people to upgrade kernel for their sound issues |
| 34 |
> is not a solution for many of them. Kernel upgrades tend to break lots |
| 35 |
> of stuff on every minor version bump (and it's not only external modules |
| 36 |
> that upstream seems to plain hate and ignore mostly). Not exactly what |
| 37 |
> users would like to see when all they are trying to get is working |
| 38 |
> sound. Plus it's lot easier (and faster) to get patches into external |
| 39 |
> drivers than get them accepted into kernel. |
| 40 |
I don't think anybody is trying to force anything. Daniel have stated |
| 41 |
that alsa-driver should be supported for a long time. |
| 42 |
> |
| 43 |
> > Interestingly in this case, the in-kernel driver is a touch newer than |
| 44 |
> > the hda-intel one. It includes support for a few more hardware devices. |
| 45 |
> > Again these are only very small differences though. |
| 46 |
> |
| 47 |
> As said, it's not about code being newer or older, it's about having two |
| 48 |
> different branches of the code. One works for someone, the other works |
| 49 |
> for someone else. What's exactly the benefit from trying to kill support |
| 50 |
> for upstream ALSA code and forcing people to use in-kernel drivers |
| 51 |
> (beyond what you see as 'duplicated' maintenance effort)? Users honestly |
| 52 |
> don't care much about 'duplicated' effort, they want a working sound on |
| 53 |
> their boxes. |
| 54 |
I'll just repeat myself here as you've basically just repeated your |
| 55 |
claim about forcing people to use in-kernel drivers.. |
| 56 |
|
| 57 |
Nobody is forcing anybody to use in-kernel drivers. |
| 58 |
|
| 59 |
Regards, |
| 60 |
Bryan Østergaard |
| 61 |
-- |
| 62 |
gentoo-dev@g.o mailing list |
Archives