Bug 498060

Summary: Sound does not work on hp tx25xx series laptops without model=toshiba parameter
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: itamar, kernel-maint, lpoetter, quintela
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-14 18:48:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Possible patch to add a quirk for this model
none
output of cat /proc/asound/card?/codec#? on an affected system none

Description Adam Williamson 2009-04-28 17:20:41 UTC 
Created attachment 341618 [details]
Possible patch to add a quirk for this model

This is a downstream report for upstream bug https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4121 , since the upstream bug has been open several months and Lennart Poettering tells me the ALSA bug tracker does not get much attention from developers.

As reported by two people there and several others elsewhere, many laptops in the HP tx25xx series don't give any sound output unless the 'model=toshiba' parameter for the snd-hda-intel module is used. The affected subsystem ID appears to be 0x103c 0x30f1 (codec is ALC268). The attached patch should 'fix' the problem, although it's probably not quite right, since the laptop isn't actually a Toshiba; I'm guessing a new ALC268 quirk for HP laptops needs to be added. The fix for this should obviously go upstream. I unfortunately can't confirm the fix once committed, as it wasn't my laptop where I saw the problem, and I forgot to take the owner's email address :(. I confirmed with my own ears that there was no sound out of the box and re-loading snd-hda-intel with the parameter 'model=toshiba' made it work, though.
Comment 1 Adam Williamson 2009-04-28 17:22:18 UTC 
Created attachment 341619 [details]
output of cat /proc/asound/card?/codec#? on an affected system
Comment 2 Chuck Ebbert 2009-04-29 04:07:20 UTC 
You may want to do something similar to commit 53eff7e1e0de1cde8e8cbe619f401d2578dde946 and change the line above the one you are adding to use a mask to match all models with the pattern 0x103c 0x30**
Comment 3 Adam Williamson 2009-04-29 04:16:11 UTC 
is there some kind of convention which would ensure that was always safe - i.e. some reason we can assume any 0x30xx implementation will always have this quirk?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Chuck Ebbert 2009-04-29 21:03:17 UTC 
(In reply to comment #3)
> is there some kind of convention which would ensure that was always safe - i.e.
> some reason we can assume any 0x30xx implementation will always have this
> quirk?
> 

No, not really. The whole setup is based on guesswork and if someone finds a model that doesn't work the wildcard can be overidden by placing a specific quirk before the generic one. It's going to make its own guess anyway if there's not something in the table...
Comment 5 Adam Williamson 2009-04-30 01:03:15 UTC 
OK. Well, I'll just leave my template patch as is, then, and let the guys who are actually allowed to make kernel commits decide what to do with it =)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Chuck Ebbert 2009-05-13 15:58:39 UTC 
Applied to 2.6.29.3-62, will send upstream too.
Comment 7 Adam Williamson 2009-05-14 18:48:46 UTC 
Thanks a lot. I think we'll have to go ahead and mark this as CLOSED RAWHIDE, because I forgot to take the email address of the guy who actually suffers from the bug, so I have no way to reproduce / test the fix. I can't see how anything could possibly go wrong ;)