* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series [not found] <4F35C191.9080401@gmail.com> @ 2012-02-11 2:05 ` Jonathan Woithe 2012-02-15 0:50 ` Raymond Yau 0 siblings, 1 reply; 23+ messages in thread From: Jonathan Woithe @ 2012-02-11 2:05 UTC (permalink / raw) To: joey.jiaojg, alsa-devel; +Cc: tiwai, pshou, kailang, jwoithe Hi Joey For future reference, please email reports like this to the alsa-devel list. The relevant developers are far more likely to respond to messages on the list than they are to messages sent privately. I have copied this to the list to maximise its distribution. On Sat, Feb 11, 2012 at 09:17:05AM +0800, joey.jiaojg wrote: > I'm reporting a bug related to ALSA and ALC260, which perhaps only > you can solve. Appreciate if you can check. > We got a lot of users using HP COMPAQ B1900 series which using ATI > SB450 and ALC260 for linux systems like Debian, Ubuntu and etc. The > problem is that there is no sound from speaker while enable > model=will can hear from earphone. The problem and alsa-info.txt is > reported here https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/186698, > which thought be a bug of ALC260 driver bug. > Hope you can check what we can do to solve it. >From the above I am not entirely sure what the problem is. You seem to be talking about two separate conditions. In the first (where I presume the module is loaded without any parameters you say there's no sound from the speaker. Do other aspects of the card work correctly in this case? The second situation is where "model=will" is specified as a module parameter. Here you say you can get audio from the headphone, but again what about other aspects of the soundcard - do they work normally? At a rough guess, it sounds like there are two underlying issues. The first is that this system requires some model-specific handing in order to map chip outputs correctly. The second is that if such model-specific details are required then the driver preferrably would activate these automatically without the need to specify "model=will". Another possibility is that there is something about this laptop system which is confusing the auto-probing of the alc260 codec code. I'm not sure what is the best way of proceeding here. I suspect other more active developers will have a streamlined approach to help rectify the trouble. In the first instance I would tend to load the module with "model=test" and experiment with the resulting alsamixer controls to determine what chip outputs are connected to which pins. However, this is quite "old school" now - while it's the approach I used when getting my system working, my impression is that its use has been mostly deprecated by the automatic parser which is now present. In the above-referenced launchpad report the question is asked about the ALC260 datasheet. This is readily available on the net. I doubt it is all that necessary now since I think the base infrastructure is pretty solid, but if you do need it and have difficulty finding it please contact me off-list. Regards jonathan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-11 2:05 ` Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series Jonathan Woithe @ 2012-02-15 0:50 ` Raymond Yau [not found] ` <CAKOmCvoS+tgvyPZJey4gfFFq=Uz01pnZY7YvGbxgQPpAzQ7KCA@mail.gmail.com> 0 siblings, 1 reply; 23+ messages in thread From: Raymond Yau @ 2012-02-15 0:50 UTC (permalink / raw) To: ALSA Development Mailing List; +Cc: tiwai, pshou, kailang, joey.jiaojg 2012/2/11, Jonathan Woithe <jwoithe@just42.net>: > Hi Joey > > For future reference, please email reports like this to the alsa-devel list. > The relevant developers are far more likely to respond to messages on the > list than they are to messages sent privately. > > I have copied this to the list to maximise its distribution. > > On Sat, Feb 11, 2012 at 09:17:05AM +0800, joey.jiaojg wrote: >> I'm reporting a bug related to ALSA and ALC260, which perhaps only >> you can solve. Appreciate if you can check. >> We got a lot of users using HP COMPAQ B1900 series which using ATI >> SB450 and ALC260 for linux systems like Debian, Ubuntu and etc. The >> problem is that there is no sound from speaker while enable >> model=will can hear from earphone. The problem and alsa-info.txt is >> reported here >> https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/186698, >> which thought be a bug of ALC260 driver bug. >> Hope you can check what we can do to solve it. > > From the above I am not entirely sure what the problem is. You seem to be > talking about two separate conditions. In the first (where I presume the > module is loaded without any parameters you say there's no sound from the > speaker. Do other aspects of the card work correctly in this case? > > The second situation is where "model=will" is specified as a module > parameter. Here you say you can get audio from the headphone, but again > what about other aspects of the soundcard - do they work normally? > > At a rough guess, it sounds like there are two underlying issues. The first > is that this system requires some model-specific handing in order to map > chip outputs correctly. The second is that if such model-specific details > are required then the driver preferrably would activate these automatically > without the need to specify "model=will". > > Another possibility is that there is something about this laptop system > which is confusing the auto-probing of the alc260 codec code. > > I'm not sure what is the best way of proceeding here. I suspect other more > active developers will have a streamlined approach to help rectify the > trouble. In the first instance I would tend to load the module with > "model=test" and experiment with the resulting alsamixer controls to > determine what chip outputs are connected to which pins. However, this is > quite "old school" now - while it's the approach I used when getting my > system working, my impression is that its use has been mostly deprecated by > the automatic parser which is now present. > > In the above-referenced launchpad report the question is asked about the > ALC260 datasheet. This is readily available on the net. I doubt it is all > that necessary now since I think the base infrastructure is pretty solid, > but if you do need it and have difficulty finding it please contact me > off-list. > The auto-parser require correct pin default Refer to alc260 General Description Realtek's proprietary impedance sensing and jack detect techniques allow device loads on inputs and outputs to be auto-detected. All analog IOs are input and output capable. Headphone amplifiers are also integrated at each analog output. All analog IOs can be re-tasked according to user's definitions, or automatically switched to suit the connecting device (Universal Audio Jack®). Reserve analog mixer architecture is backwards compatible with AC'97 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CAKOmCvoS+tgvyPZJey4gfFFq=Uz01pnZY7YvGbxgQPpAzQ7KCA@mail.gmail.com>]
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series [not found] ` <CAKOmCvoS+tgvyPZJey4gfFFq=Uz01pnZY7YvGbxgQPpAzQ7KCA@mail.gmail.com> @ 2012-02-15 1:29 ` Joey Jiao 2012-02-15 2:49 ` Raymond Yau 0 siblings, 1 reply; 23+ messages in thread From: Joey Jiao @ 2012-02-15 1:29 UTC (permalink / raw) To: Raymond Yau; +Cc: tiwai, pshou, ALSA Development Mailing List, kailang Btw, for the code modification, I modified model will in patch_realtek.c which works same as the hda-verb command. From: static const struct hda_verb alc260_will_verbs[] = { {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, {} }; To: static const struct hda_verb alc260_will_verbs[] = { {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, {0x01, AC_VERB_SET_GPIO_MASK, 0x01}, {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x01}, {} }; 在 2012年2月15日 上午9:18,Joey Jiao <joey.jiaojg@gmail.com> 写道: > Hi all, > I solved the speaker problem of B1900, and I have you can fix the > driver in next alsa release. > I use hda-verb tool to enable sound from speaker. > Commands as below: > sudo hda-verb /dev/snd/hwC0D0 0x01 0x716 0x01 > sudo hda-verb /dev/snd/hwC0D0 0x01 0x717 0x01 > > Perhaps you need to add a new model besides will. Meanwhile, auto > detect of headphone inserting is not function, so speaker and > headphone don't switch automatically. > > > 在 2012年2月15日 上午8:50,Raymond Yau <superquad.vortex2@gmail.com> 写道: >> 2012/2/11, Jonathan Woithe <jwoithe@just42.net>: >>> Hi Joey >>> >>> For future reference, please email reports like this to the alsa-devel list. >>> The relevant developers are far more likely to respond to messages on the >>> list than they are to messages sent privately. >>> >>> I have copied this to the list to maximise its distribution. >>> >>> On Sat, Feb 11, 2012 at 09:17:05AM +0800, joey.jiaojg wrote: >>>> I'm reporting a bug related to ALSA and ALC260, which perhaps only >>>> you can solve. Appreciate if you can check. >>>> We got a lot of users using HP COMPAQ B1900 series which using ATI >>>> SB450 and ALC260 for linux systems like Debian, Ubuntu and etc. The >>>> problem is that there is no sound from speaker while enable >>>> model=will can hear from earphone. The problem and alsa-info.txt is >>>> reported here >>>> https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/186698, >>>> which thought be a bug of ALC260 driver bug. >>>> Hope you can check what we can do to solve it. >>> >>> From the above I am not entirely sure what the problem is. You seem to be >>> talking about two separate conditions. In the first (where I presume the >>> module is loaded without any parameters you say there's no sound from the >>> speaker. Do other aspects of the card work correctly in this case? >>> >>> The second situation is where "model=will" is specified as a module >>> parameter. Here you say you can get audio from the headphone, but again >>> what about other aspects of the soundcard - do they work normally? >>> >>> At a rough guess, it sounds like there are two underlying issues. The first >>> is that this system requires some model-specific handing in order to map >>> chip outputs correctly. The second is that if such model-specific details >>> are required then the driver preferrably would activate these automatically >>> without the need to specify "model=will". >>> >>> Another possibility is that there is something about this laptop system >>> which is confusing the auto-probing of the alc260 codec code. >>> >>> I'm not sure what is the best way of proceeding here. I suspect other more >>> active developers will have a streamlined approach to help rectify the >>> trouble. In the first instance I would tend to load the module with >>> "model=test" and experiment with the resulting alsamixer controls to >>> determine what chip outputs are connected to which pins. However, this is >>> quite "old school" now - while it's the approach I used when getting my >>> system working, my impression is that its use has been mostly deprecated by >>> the automatic parser which is now present. >>> >>> In the above-referenced launchpad report the question is asked about the >>> ALC260 datasheet. This is readily available on the net. I doubt it is all >>> that necessary now since I think the base infrastructure is pretty solid, >>> but if you do need it and have difficulty finding it please contact me >>> off-list. >>> >> >> The auto-parser require correct pin default >> >> Refer to alc260 General Description >> >> Realtek's proprietary impedance sensing and jack detect techniques >> allow device loads on inputs and outputs to be auto-detected. All >> analog IOs are input and output capable. Headphone amplifiers are also >> integrated at each analog output. All analog IOs can be re-tasked >> according to user's definitions, or automatically switched to suit the >> connecting device (Universal Audio Jack®). >> >> Reserve analog mixer architecture is backwards compatible with AC'97 > > > > -- > -Joey Jiao -- -Joey Jiao _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 1:29 ` Joey Jiao @ 2012-02-15 2:49 ` Raymond Yau [not found] ` <4F3B761D.4060306@gmail.com> 0 siblings, 1 reply; 23+ messages in thread From: Raymond Yau @ 2012-02-15 2:49 UTC (permalink / raw) To: Joey Jiao; +Cc: tiwai, pshou, ALSA Development Mailing List, kailang 2012/2/15, Joey Jiao <joey.jiaojg@gmail.com>: > Btw, for the code modification, I modified model will in > patch_realtek.c which works same as the hda-verb command. > From: > static const struct hda_verb alc260_will_verbs[] = { > {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, > {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, > {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, > {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, > {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, > {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, > {} > }; > To: > static const struct hda_verb alc260_will_verbs[] = { > {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, > {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, > {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, > {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, > {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, > {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, > {0x01, AC_VERB_SET_GPIO_MASK, 0x01}, > {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x01}, > {} > }; > > > 在 2012年2月15日 上午9:18,Joey Jiao <joey.jiaojg@gmail.com> 写道: >> Hi all, >> I solved the speaker problem of B1900, and I have you can fix the >> driver in next alsa release. >> I use hda-verb tool to enable sound from speaker. >> Commands as below: >> sudo hda-verb /dev/snd/hwC0D0 0x01 0x716 0x01 >> sudo hda-verb /dev/snd/hwC0D0 0x01 0x717 0x01 >> >> Perhaps you need to add a new model besides will. Meanwhile, auto >> detect of headphone inserting is not function, so speaker and >> headphone don't switch automatically. >> >> >> 在 2012年2月15日 上午8:50,Raymond Yau <superquad.vortex2@gmail.com> 写道: >>> >>> The auto-parser require correct pin default >>> >>> Refer to alc260 General Description >>> >>> Realtek's proprietary impedance sensing and jack detect techniques >>> allow device loads on inputs and outputs to be auto-detected. All >>> analog IOs are input and output capable. Headphone amplifiers are also >>> integrated at each analog output. All analog IOs can be re-tasked >>> according to user's definitions, or automatically switched to suit the >>> connecting device (Universal Audio Jack®). >>> >>> Reserve analog mixer architecture is backwards compatible with AC'97 >> >> the function is_jack_detectable() has been changed to check AC_DEFCFG_MISC_NO_PRESENCE http://thread.gmane.org/gmane.linux.alsa.devel/90911/focus=91215 I guess Takashi Iwai expect you to provide a pin fixup patch which provide the pin location of the speaker , internal mic, headphone and external mic jack for the auto parser Refer to #25 >> Adding micphone detect: >> $ sudo hda-verb /dev/snd/hwC0D0 0x12 0xF09 0x0 >> nid = 0x12, verb = 0xf09, param = 0x0 >>value = 0x800000c8 does impedence sense require some delay to get the accurate reading ? it seem the microphone has a much higher impedenance than your result 0xc8 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <4F3B761D.4060306@gmail.com>]
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series [not found] ` <4F3B761D.4060306@gmail.com> @ 2012-02-15 9:22 ` Takashi Iwai 2012-02-15 9:31 ` joey.jiaojg 0 siblings, 1 reply; 23+ messages in thread From: Takashi Iwai @ 2012-02-15 9:22 UTC (permalink / raw) To: joey.jiaojg; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Wed, 15 Feb 2012 17:08:45 +0800, joey.jiaojg wrote: > > Well, now I have fully fixed the speaker/headphone issue for HP COMPAQ > B1900 by adding a new model=b1900 into patch_realtek.c which also can > automute by detect HP state. That's great. > As I cannot compile alsa-driver-1.0.25 on my ubuntu 11.10, so I modified > based on kernel-3.0.13 (alsa version 1.0.24) from ubuntu src. > Attached with stocked source and my updated one, please consider adding > into next alsa-driver. Could you simply give a patch file (with "diff -up")? Then I can check your changes more easily. thanks, Takashi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 9:22 ` Takashi Iwai @ 2012-02-15 9:31 ` joey.jiaojg 2012-02-15 9:40 ` Takashi Iwai 0 siblings, 1 reply; 23+ messages in thread From: joey.jiaojg @ 2012-02-15 9:31 UTC (permalink / raw) To: Takashi Iwai; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang [-- Attachment #1: Type: text/plain, Size: 720 bytes --] Here is the diff file. On 2012年02月15日 17:22, Takashi Iwai wrote: > At Wed, 15 Feb 2012 17:08:45 +0800, > joey.jiaojg wrote: >> Well, now I have fully fixed the speaker/headphone issue for HP COMPAQ >> B1900 by adding a new model=b1900 into patch_realtek.c which also can >> automute by detect HP state. > That's great. > >> As I cannot compile alsa-driver-1.0.25 on my ubuntu 11.10, so I modified >> based on kernel-3.0.13 (alsa version 1.0.24) from ubuntu src. >> Attached with stocked source and my updated one, please consider adding >> into next alsa-driver. > Could you simply give a patch file (with "diff -up")? > Then I can check your changes more easily. > > > thanks, > > Takashi [-- Attachment #2: patch_realtek_diff.c --] [-- Type: text/x-csrc, Size: 3752 bytes --] --- patch_realtek.c.bk 2012-02-15 17:29:44.851620661 +0800 +++ patch_realtek.c 2012-02-15 17:29:40.887601285 +0800 @@ -80,6 +80,7 @@ enum { ALC260_WILL, ALC260_REPLACER_672V, ALC260_FAVORIT100, + ALC260_B1900, #ifdef CONFIG_SND_DEBUG ALC260_TEST, #endif @@ -1323,6 +1324,34 @@ static void alc_inithook(struct hda_code alc_mic_automute(codec); } +/* toggle speaker-output according to the hp-jack state */ +static void alc260_b1900_automute(struct hda_codec *codec) +{ + unsigned int present; + + present = snd_hda_jack_detect(codec, 0x0f); + if (present) { + snd_hda_codec_write_cache(codec, 0x01, 0, + AC_VERB_SET_GPIO_MASK, 0); + snd_hda_codec_write_cache(codec, 0x01, 0, + AC_VERB_SET_GPIO_DIRECTION, + 0); + snd_hda_codec_write_cache(codec, 0x0f, 0, + AC_VERB_SET_PIN_WIDGET_CONTROL, + PIN_HP); + } else { + snd_hda_codec_write_cache(codec, 0x01, 0, + AC_VERB_SET_GPIO_MASK, 1); + snd_hda_codec_write_cache(codec, 0x01, 0, + AC_VERB_SET_GPIO_DIRECTION, + 1); + snd_hda_codec_write_cache(codec, 0x0f, 0, + AC_VERB_SET_PIN_WIDGET_CONTROL, + PIN_OUT); + } +} + + /* additional initialization for ALC888 variants */ static void alc888_coef_init(struct hda_codec *codec) { @@ -6899,6 +6928,18 @@ static const struct hda_verb alc260_will {} }; +static const struct hda_verb alc260_b1900_verbs[] = { + {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, + {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, + {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, + {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, + {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, + {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, + {0x0f, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | ALC880_HP_EVENT}, + {} +}; + + static const struct hda_verb alc260_replacer_672v_verbs[] = { {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, @@ -6941,6 +6982,12 @@ static void alc260_replacer_672v_unsol_e alc260_replacer_672v_automute(codec); } +static void alc260_b1900_unsol_event(struct hda_codec *codec, + unsigned int res) +{ + if ((res >> 26) == ALC880_HP_EVENT) + alc260_b1900_automute(codec); +} static const struct hda_verb alc260_hp_dc7600_verbs[] = { {0x05, AC_VERB_SET_CONNECT_SEL, 0x01}, {0x15, AC_VERB_SET_CONNECT_SEL, 0x01}, @@ -7431,6 +7478,7 @@ static const char * const alc260_models[ [ALC260_WILL] = "will", [ALC260_REPLACER_672V] = "replacer", [ALC260_FAVORIT100] = "favorit100", + [ALC260_B1900] = "b1900", #ifdef CONFIG_SND_DEBUG [ALC260_TEST] = "test", #endif @@ -7458,6 +7506,7 @@ static const struct snd_pci_quirk alc260 SND_PCI_QUIRK(0x152d, 0x0729, "CTL U553W", ALC260_BASIC), SND_PCI_QUIRK(0x161f, 0x2057, "Replacer 672V", ALC260_REPLACER_672V), SND_PCI_QUIRK(0x1631, 0xc017, "PB V7900", ALC260_WILL), + SND_PCI_QUIRK(0x103c, 0x007f, "HP COMPAQ", ALC260_B1900), {} }; @@ -7570,6 +7619,20 @@ static const struct alc_config_preset al .channel_mode = alc260_modes, .input_mux = &alc260_capture_source, }, + [ALC260_B1900] = { + .mixers = { alc260_will_mixer }, + .init_verbs = { alc260_init_verbs, alc260_b1900_verbs }, + .num_dacs = ARRAY_SIZE(alc260_dac_nids), + .dac_nids = alc260_dac_nids, + .num_adc_nids = ARRAY_SIZE(alc260_adc_nids), + .adc_nids = alc260_adc_nids, + .dig_out_nid = ALC260_DIGOUT_NID, + .num_channel_mode = ARRAY_SIZE(alc260_modes), + .channel_mode = alc260_modes, + .input_mux = &alc260_capture_source, + .unsol_event = alc260_b1900_unsol_event, + .init_hook = alc260_b1900_automute, + }, [ALC260_REPLACER_672V] = { .mixers = { alc260_replacer_672v_mixer }, .init_verbs = { alc260_init_verbs, alc260_replacer_672v_verbs }, [-- Attachment #3: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 9:31 ` joey.jiaojg @ 2012-02-15 9:40 ` Takashi Iwai 2012-02-15 9:45 ` joey.jiaojg 0 siblings, 1 reply; 23+ messages in thread From: Takashi Iwai @ 2012-02-15 9:40 UTC (permalink / raw) To: joey.jiaojg; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Wed, 15 Feb 2012 17:31:44 +0800, joey.jiaojg wrote: > > Here is the diff file. Thanks. > +/* toggle speaker-output according to the hp-jack state */ > +static void alc260_b1900_automute(struct hda_codec *codec) > +{ > + unsigned int present; > + > + present = snd_hda_jack_detect(codec, 0x0f); > + if (present) { > + snd_hda_codec_write_cache(codec, 0x01, 0, > + AC_VERB_SET_GPIO_MASK, 0); > + snd_hda_codec_write_cache(codec, 0x01, 0, > + AC_VERB_SET_GPIO_DIRECTION, > + 0); What actually this GPIO bit does on your device? To mute/unmute the speaker? If so, doesn't the speaker toggle work with just changing the pin-control of the corresponding pin? Takashi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 9:40 ` Takashi Iwai @ 2012-02-15 9:45 ` joey.jiaojg 2012-02-15 9:58 ` Takashi Iwai 0 siblings, 1 reply; 23+ messages in thread From: joey.jiaojg @ 2012-02-15 9:45 UTC (permalink / raw) To: Takashi Iwai; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang I have tried to enable each one of them separately, and the speaker doesn't work. I have to use these 3 write_cache to make switch and auto-detect work smoothly. On 2012年02月15日 17:40, Takashi Iwai wrote: > At Wed, 15 Feb 2012 17:31:44 +0800, > joey.jiaojg wrote: >> Here is the diff file. > Thanks. > >> +/* toggle speaker-output according to the hp-jack state */ >> +static void alc260_b1900_automute(struct hda_codec *codec) >> +{ >> + unsigned int present; >> + >> + present = snd_hda_jack_detect(codec, 0x0f); >> + if (present) { >> + snd_hda_codec_write_cache(codec, 0x01, 0, >> + AC_VERB_SET_GPIO_MASK, 0); >> + snd_hda_codec_write_cache(codec, 0x01, 0, >> + AC_VERB_SET_GPIO_DIRECTION, >> + 0); > What actually this GPIO bit does on your device? > To mute/unmute the speaker? > > If so, doesn't the speaker toggle work with just changing the > pin-control of the corresponding pin? > > > Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 9:45 ` joey.jiaojg @ 2012-02-15 9:58 ` Takashi Iwai 2012-02-15 10:06 ` joey.jiaojg 0 siblings, 1 reply; 23+ messages in thread From: Takashi Iwai @ 2012-02-15 9:58 UTC (permalink / raw) To: joey.jiaojg; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Wed, 15 Feb 2012 17:45:37 +0800, joey.jiaojg wrote: > > I have tried to enable each one of them separately, and the speaker > doesn't work. Sorry, it's not clear what you meant. Each of what separately? And what does GPIO do exactly? > I have to use these 3 write_cache to make switch and auto-detect work > smoothly. We need to know the reason why these must be needed. Takashi > On 2012年02月15日 17:40, Takashi Iwai wrote: > > At Wed, 15 Feb 2012 17:31:44 +0800, > > joey.jiaojg wrote: > >> Here is the diff file. > > Thanks. > > > >> +/* toggle speaker-output according to the hp-jack state */ > >> +static void alc260_b1900_automute(struct hda_codec *codec) > >> +{ > >> + unsigned int present; > >> + > >> + present = snd_hda_jack_detect(codec, 0x0f); > >> + if (present) { > >> + snd_hda_codec_write_cache(codec, 0x01, 0, > >> + AC_VERB_SET_GPIO_MASK, 0); > >> + snd_hda_codec_write_cache(codec, 0x01, 0, > >> + AC_VERB_SET_GPIO_DIRECTION, > >> + 0); > > What actually this GPIO bit does on your device? > > To mute/unmute the speaker? > > > > If so, doesn't the speaker toggle work with just changing the > > pin-control of the corresponding pin? > > > > > > Takashi > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 9:58 ` Takashi Iwai @ 2012-02-15 10:06 ` joey.jiaojg 2012-02-15 10:11 ` Takashi Iwai 0 siblings, 1 reply; 23+ messages in thread From: joey.jiaojg @ 2012-02-15 10:06 UTC (permalink / raw) To: Takashi Iwai; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang OK, the situation is 0x01 is to control GPIO0: 1. if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is speaker not work. 2. if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the result is speaker not work. 3. If I write step 1 & 2 together, speaker works when I reboot. 4. Then If I plugged in the headphone, the headphone doesn't work. It only works when I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP). 5. From step 3 & 4, it's similar for cases that I reboot with headphone plugged in. That is, if I remove headphone, speaker doesn't work automatically. If I write (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the auto-detection function works well can switch speaker/headphone automatically. I don't know why it's this case, and from alsa document, it seems only enable GPIO0 will work but actually not. On 2012年02月15日 17:58, Takashi Iwai wrote: > At Wed, 15 Feb 2012 17:45:37 +0800, > joey.jiaojg wrote: >> I have tried to enable each one of them separately, and the speaker >> doesn't work. > Sorry, it's not clear what you meant. Each of what separately? > And what does GPIO do exactly? > >> I have to use these 3 write_cache to make switch and auto-detect work >> smoothly. > We need to know the reason why these must be needed. > > > Takashi > > >> On 2012年02月15日 17:40, Takashi Iwai wrote: >>> At Wed, 15 Feb 2012 17:31:44 +0800, >>> joey.jiaojg wrote: >>>> Here is the diff file. >>> Thanks. >>> >>>> +/* toggle speaker-output according to the hp-jack state */ >>>> +static void alc260_b1900_automute(struct hda_codec *codec) >>>> +{ >>>> + unsigned int present; >>>> + >>>> + present = snd_hda_jack_detect(codec, 0x0f); >>>> + if (present) { >>>> + snd_hda_codec_write_cache(codec, 0x01, 0, >>>> + AC_VERB_SET_GPIO_MASK, 0); >>>> + snd_hda_codec_write_cache(codec, 0x01, 0, >>>> + AC_VERB_SET_GPIO_DIRECTION, >>>> + 0); >>> What actually this GPIO bit does on your device? >>> To mute/unmute the speaker? >>> >>> If so, doesn't the speaker toggle work with just changing the >>> pin-control of the corresponding pin? >>> >>> >>> Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 10:06 ` joey.jiaojg @ 2012-02-15 10:11 ` Takashi Iwai 2012-02-15 13:14 ` joey.jiaojg 0 siblings, 1 reply; 23+ messages in thread From: Takashi Iwai @ 2012-02-15 10:11 UTC (permalink / raw) To: joey.jiaojg; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Wed, 15 Feb 2012 18:06:39 +0800, joey.jiaojg wrote: > > OK, the situation is 0x01 is to control GPIO0: > 1. if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is > speaker not work. > > 2. if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the > result is speaker not work. > Sure, GPIO must be always set mask, direction and data all together. The question is, when you set GPIO mask/dir/data, the speaker starts playing, and if set to zero (e.g. only data), the speaker is muted? > 3. If I write step 1 & 2 together, speaker works when I reboot. Then GPIO is likely an external amp control. > 4. Then If I plugged in the headphone, the headphone doesn't work. It > only works when I write > (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP). This is normal. > 5. From step 3 & 4, it's similar for cases that I reboot with headphone > plugged in. That is, if I remove headphone, speaker doesn't work > automatically. If I write > (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the > auto-detection function works well can switch speaker/headphone > automatically. That's odd. If you don't change from PIN_HP, doesn't the unsolicited event work? Another question is, when you set PIN_WIDGET_CONTROL on the speaker pin (not sure which one is) to 0x00, does it mute the speaker, too? Takashi > I don't know why it's this case, and from alsa document, it seems only > enable GPIO0 will work but actually not. > > > On 2012年02月15日 17:58, Takashi Iwai wrote: > > At Wed, 15 Feb 2012 17:45:37 +0800, > > joey.jiaojg wrote: > >> I have tried to enable each one of them separately, and the speaker > >> doesn't work. > > Sorry, it's not clear what you meant. Each of what separately? > > And what does GPIO do exactly? > > > >> I have to use these 3 write_cache to make switch and auto-detect work > >> smoothly. > > We need to know the reason why these must be needed. > > > > > > Takashi > > > > > >> On 2012年02月15日 17:40, Takashi Iwai wrote: > >>> At Wed, 15 Feb 2012 17:31:44 +0800, > >>> joey.jiaojg wrote: > >>>> Here is the diff file. > >>> Thanks. > >>> > >>>> +/* toggle speaker-output according to the hp-jack state */ > >>>> +static void alc260_b1900_automute(struct hda_codec *codec) > >>>> +{ > >>>> + unsigned int present; > >>>> + > >>>> + present = snd_hda_jack_detect(codec, 0x0f); > >>>> + if (present) { > >>>> + snd_hda_codec_write_cache(codec, 0x01, 0, > >>>> + AC_VERB_SET_GPIO_MASK, 0); > >>>> + snd_hda_codec_write_cache(codec, 0x01, 0, > >>>> + AC_VERB_SET_GPIO_DIRECTION, > >>>> + 0); > >>> What actually this GPIO bit does on your device? > >>> To mute/unmute the speaker? > >>> > >>> If so, doesn't the speaker toggle work with just changing the > >>> pin-control of the corresponding pin? > >>> > >>> > >>> Takashi > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 10:11 ` Takashi Iwai @ 2012-02-15 13:14 ` joey.jiaojg 2012-02-15 13:21 ` Takashi Iwai 0 siblings, 1 reply; 23+ messages in thread From: joey.jiaojg @ 2012-02-15 13:14 UTC (permalink / raw) To: Takashi Iwai; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang Please check my reply below. On 2012年02月15日 18:11, Takashi Iwai wrote: > At Wed, 15 Feb 2012 18:06:39 +0800, > joey.jiaojg wrote: >> OK, the situation is 0x01 is to control GPIO0: >> 1. if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is >> speaker not work. >> >> 2. if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the >> result is speaker not work. >> > Sure, GPIO must be always set mask, direction and data all together. > The question is, when you set GPIO mask/dir/data, the speaker starts > playing, and if set to zero (e.g. only data), the speaker is muted? JOEY: I tried set data to 0 or 1 doesn't influence. when I set mask & dir to 1, speaker starts to work and to 0 speaker muted while headphone works if headphone plugged in. > >> 3. If I write step 1& 2 together, speaker works when I reboot. > Then GPIO is likely an external amp control. JOEY: YES. > >> 4. Then If I plugged in the headphone, the headphone doesn't work. It >> only works when I write >> (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP). > This is normal. JOEY: If I don't modify model=will. And headphone can play even without set AC_VERB_SET_PIN_WIDGET_CONTROL to PIN_HP. Of course, automute doesn't work as there is function implemented. > >> 5. From step 3& 4, it's similar for cases that I reboot with headphone >> plugged in. That is, if I remove headphone, speaker doesn't work >> automatically. If I write >> (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the >> auto-detection function works well can switch speaker/headphone >> automatically. > That's odd. If you don't change from PIN_HP, doesn't the unsolicited > event work? JOEY: the unsolicited works from the register I read also from the printk I previous added. But the audio path doesn't switch between speaker and headphone. I don't know why. It can works manually if I send any hda-verb command to codec, like hda-verb /dev/snd/hwC0D0 0x0F 0xF09 0x0; I think perhaps there needs to be some delay. But I wait seconds and it doesn't switch. Then if I run any hda-verb command, it will then switch. Then after I change from PIN_HP or from PIN_OUT, the automute (actually audio path switch) works. > Another question is, when you set PIN_WIDGET_CONTROL on the speaker > pin (not sure which one is) to 0x00, does it mute the speaker, too? JOEY: No, it doesn't mute the speaker. To mute the speaker, I just need to set 0 to dir or mask. Then audio path is to headphone. > > Takashi > > >> I don't know why it's this case, and from alsa document, it seems only >> enable GPIO0 will work but actually not. >> >> >> On 2012年02月15日 17:58, Takashi Iwai wrote: >>> At Wed, 15 Feb 2012 17:45:37 +0800, >>> joey.jiaojg wrote: >>>> I have tried to enable each one of them separately, and the speaker >>>> doesn't work. >>> Sorry, it's not clear what you meant. Each of what separately? >>> And what does GPIO do exactly? >>> >>>> I have to use these 3 write_cache to make switch and auto-detect work >>>> smoothly. >>> We need to know the reason why these must be needed. >>> >>> >>> Takashi >>> >>> >>>> On 2012年02月15日 17:40, Takashi Iwai wrote: >>>>> At Wed, 15 Feb 2012 17:31:44 +0800, >>>>> joey.jiaojg wrote: >>>>>> Here is the diff file. >>>>> Thanks. >>>>> >>>>>> +/* toggle speaker-output according to the hp-jack state */ >>>>>> +static void alc260_b1900_automute(struct hda_codec *codec) >>>>>> +{ >>>>>> + unsigned int present; >>>>>> + >>>>>> + present = snd_hda_jack_detect(codec, 0x0f); >>>>>> + if (present) { >>>>>> + snd_hda_codec_write_cache(codec, 0x01, 0, >>>>>> + AC_VERB_SET_GPIO_MASK, 0); >>>>>> + snd_hda_codec_write_cache(codec, 0x01, 0, >>>>>> + AC_VERB_SET_GPIO_DIRECTION, >>>>>> + 0); >>>>> What actually this GPIO bit does on your device? >>>>> To mute/unmute the speaker? >>>>> >>>>> If so, doesn't the speaker toggle work with just changing the >>>>> pin-control of the corresponding pin? >>>>> >>>>> >>>>> Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 13:14 ` joey.jiaojg @ 2012-02-15 13:21 ` Takashi Iwai 2012-02-15 14:45 ` joey.jiaojg 0 siblings, 1 reply; 23+ messages in thread From: Takashi Iwai @ 2012-02-15 13:21 UTC (permalink / raw) To: joey.jiaojg; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Wed, 15 Feb 2012 21:14:48 +0800, joey.jiaojg wrote: > > Please check my reply below. > > On 2012年02月15日 18:11, Takashi Iwai wrote: > > At Wed, 15 Feb 2012 18:06:39 +0800, > > joey.jiaojg wrote: > >> OK, the situation is 0x01 is to control GPIO0: > >> 1. if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is > >> speaker not work. > >> > >> 2. if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the > >> result is speaker not work. > >> > > Sure, GPIO must be always set mask, direction and data all together. > > The question is, when you set GPIO mask/dir/data, the speaker starts > > playing, and if set to zero (e.g. only data), the speaker is muted? > JOEY: I tried set data to 0 or 1 doesn't influence. when I set mask & > dir to 1, speaker starts to work and to 0 speaker muted while headphone > works if headphone plugged in. There is something wrong in tests. The direction bit controls only the direction, so yes, it must match with the value the hardware expected. Otherwise it won't work, thus it's turned off. > >> 3. If I write step 1& 2 together, speaker works when I reboot. > > Then GPIO is likely an external amp control. > JOEY: YES. > > > >> 4. Then If I plugged in the headphone, the headphone doesn't work. It > >> only works when I write > >> (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP). > > This is normal. > JOEY: If I don't modify model=will. And headphone can play even without > set AC_VERB_SET_PIN_WIDGET_CONTROL to PIN_HP. Of course, automute > doesn't work as there is function implemented. OK, this is because of model=will strange things. > >> 5. From step 3& 4, it's similar for cases that I reboot with headphone > >> plugged in. That is, if I remove headphone, speaker doesn't work > >> automatically. If I write > >> (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the > >> auto-detection function works well can switch speaker/headphone > >> automatically. > > That's odd. If you don't change from PIN_HP, doesn't the unsolicited > > event work? > JOEY: the unsolicited works from the register I read also from the > printk I previous added. But the audio path doesn't switch between > speaker and headphone. I don't know why. It can works manually if I send > any hda-verb command to codec, like hda-verb /dev/snd/hwC0D0 0x0F 0xF09 > 0x0; I think perhaps there needs to be some delay. But I wait seconds > and it doesn't switch. Then if I run any hda-verb command, it will then > switch. > Then after I change from PIN_HP or from PIN_OUT, the automute (actually > audio path switch) works. Is the effect only with this pin? In other words, if you change the pin control value of other pin, no similar effect? > > Another question is, when you set PIN_WIDGET_CONTROL on the speaker > > pin (not sure which one is) to 0x00, does it mute the speaker, too? > JOEY: No, it doesn't mute the speaker. To mute the speaker, I just need > to set 0 to dir or mask. Then audio path is to headphone. And you are sure that it's the right pin? Which pin did you test? The pin-control doesn't always turn off the output in some cases. But, we'd need to be sure whether we are looking at the right one. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 13:21 ` Takashi Iwai @ 2012-02-15 14:45 ` joey.jiaojg 2012-02-15 15:04 ` Takashi Iwai 0 siblings, 1 reply; 23+ messages in thread From: joey.jiaojg @ 2012-02-15 14:45 UTC (permalink / raw) To: Takashi Iwai; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang I think the only question below is about the automute, right? Then I did another test by modifying like below (so the result is same as sending any hda-verb cmd) -- The result is the auto-mute works too: if (present) { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 0); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 0); /*snd_hda_codec_write_cache(codec, 0x0f, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP);*/ snd_hda_codec_read(codec, 0x01, 0, AC_VERB_GET_GPIO_MASK, 0); } else { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 1); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 1); /*snd_hda_codec_write_cache(codec, 0x0f, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT);*/ snd_hda_codec_read(codec, 0x01, 0, AC_VERB_GET_GPIO_MASK, 0); } On 2012年02月15日 21:21, Takashi Iwai wrote: > At Wed, 15 Feb 2012 21:14:48 +0800, > joey.jiaojg wrote: >> Please check my reply below. >> >> On 2012年02月15日 18:11, Takashi Iwai wrote: >>> At Wed, 15 Feb 2012 18:06:39 +0800, >>> joey.jiaojg wrote: >>>> OK, the situation is 0x01 is to control GPIO0: >>>> 1. if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is >>>> speaker not work. >>>> >>>> 2. if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the >>>> result is speaker not work. >>>> >>> Sure, GPIO must be always set mask, direction and data all together. >>> The question is, when you set GPIO mask/dir/data, the speaker starts >>> playing, and if set to zero (e.g. only data), the speaker is muted? >> JOEY: I tried set data to 0 or 1 doesn't influence. when I set mask& >> dir to 1, speaker starts to work and to 0 speaker muted while headphone >> works if headphone plugged in. > There is something wrong in tests. The direction bit controls only > the direction, so yes, it must match with the value the hardware > expected. Otherwise it won't work, thus it's turned off. > >>>> 3. If I write step 1& 2 together, speaker works when I reboot. >>> Then GPIO is likely an external amp control. >> JOEY: YES. >>>> 4. Then If I plugged in the headphone, the headphone doesn't work. It >>>> only works when I write >>>> (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP). >>> This is normal. >> JOEY: If I don't modify model=will. And headphone can play even without >> set AC_VERB_SET_PIN_WIDGET_CONTROL to PIN_HP. Of course, automute >> doesn't work as there is function implemented. > OK, this is because of model=will strange things. > >>>> 5. From step 3& 4, it's similar for cases that I reboot with headphone >>>> plugged in. That is, if I remove headphone, speaker doesn't work >>>> automatically. If I write >>>> (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the >>>> auto-detection function works well can switch speaker/headphone >>>> automatically. >>> That's odd. If you don't change from PIN_HP, doesn't the unsolicited >>> event work? >> JOEY: the unsolicited works from the register I read also from the >> printk I previous added. But the audio path doesn't switch between >> speaker and headphone. I don't know why. It can works manually if I send >> any hda-verb command to codec, like hda-verb /dev/snd/hwC0D0 0x0F 0xF09 >> 0x0; I think perhaps there needs to be some delay. But I wait seconds >> and it doesn't switch. Then if I run any hda-verb command, it will then >> switch. >> Then after I change from PIN_HP or from PIN_OUT, the automute (actually >> audio path switch) works. > Is the effect only with this pin? In other words, if you change the > pin control value of other pin, no similar effect? > >>> Another question is, when you set PIN_WIDGET_CONTROL on the speaker >>> pin (not sure which one is) to 0x00, does it mute the speaker, too? >> JOEY: No, it doesn't mute the speaker. To mute the speaker, I just need >> to set 0 to dir or mask. Then audio path is to headphone. > And you are sure that it's the right pin? Which pin did you test? > > The pin-control doesn't always turn off the output in some cases. > But, we'd need to be sure whether we are looking at the right one. > > > thanks, > > Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 14:45 ` joey.jiaojg @ 2012-02-15 15:04 ` Takashi Iwai 2012-02-16 2:04 ` Joey Jiao 0 siblings, 1 reply; 23+ messages in thread From: Takashi Iwai @ 2012-02-15 15:04 UTC (permalink / raw) To: joey.jiaojg; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Wed, 15 Feb 2012 22:45:27 +0800, joey.jiaojg wrote: > > I think the only question below is about the automute, right? Not really. The most important thing is to understand what's doing what. Since your code can't be applied any longer at all to the latest code tree because of the fundamental code rewrite, we need to do it right. So, please check the following: 1. Does any pin correspond to the speaker output? Try to change the pin control of each pin between 0x10 and 0x19 via hda-verb while the speaker output is active. Does any pin change the speaker output? 2. Plug your headphone. Now the speaker is muted with your patch. What happens when you run like below? hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1 Does the speaker starts playing again? Then, what happens now with: hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0 ?? Takashi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-15 15:04 ` Takashi Iwai @ 2012-02-16 2:04 ` Joey Jiao 2012-02-16 3:41 ` joey.jiaojg 2012-02-16 9:35 ` Takashi Iwai 0 siblings, 2 replies; 23+ messages in thread From: Joey Jiao @ 2012-02-16 2:04 UTC (permalink / raw) To: Takashi Iwai; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang 1. I changed to model=will to test without headphone hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] Result: for sure not work as GPIO not open 2. I changed to model=b1900 to test without headphone hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 Result: speaker still works. It's for sure. 3. Then same condition as step 2 but change 0xC0 to 0x0 hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 Result: speaker doesn't work only when NID=0x0F; then I tried param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, speaker doesn't work. 4. Then I plugged in headphone. Now the param =0x40 for NID=0x0F. Result: Headphone works while speaker muted. Then I changed param=0x80. (same result when param=0xC0) Result: Headphone still works while speaker muted. 5. Then I reboot with headphone plugged in to test your step 2. YES, now the speaker muted while headphone works. Then I do your cmds: hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 Result: headphone muted, speaker works hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 Result: headphone works, speaker muted hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 Result: headphone muted, speaker works. Please noted the last two cmds, it's strange but it's true. Any additional tests? 在 2012年2月15日 下午11:04,Takashi Iwai <tiwai@suse.de> 写道: > At Wed, 15 Feb 2012 22:45:27 +0800, > joey.jiaojg wrote: >> >> I think the only question below is about the automute, right? > > Not really. The most important thing is to understand what's doing > what. Since your code can't be applied any longer at all to the > latest code tree because of the fundamental code rewrite, we need to > do it right. > > So, please check the following: > > 1. Does any pin correspond to the speaker output? Try to change the > pin control of each pin between 0x10 and 0x19 via hda-verb while > the speaker output is active. Does any pin change the speaker > output? > > 2. Plug your headphone. Now the speaker is muted with your patch. > What happens when you run like below? > > hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 > hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 > hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1 > > Does the speaker starts playing again? Then, what happens now > with: > > hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0 > > ?? > > > Takashi -- -Joey Jiao _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-16 2:04 ` Joey Jiao @ 2012-02-16 3:41 ` joey.jiaojg 2012-02-16 9:36 ` Takashi Iwai 2012-02-16 9:35 ` Takashi Iwai 1 sibling, 1 reply; 23+ messages in thread From: joey.jiaojg @ 2012-02-16 3:41 UTC (permalink / raw) To: Takashi Iwai; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang And now this code works: /* toggle speaker-output according to the hp-jack state */ static void alc260_b1900_automute(struct hda_codec *codec) { unsigned int present; present = snd_hda_jack_detect(codec, 0x0f); if (present) { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 0); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 0); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 1); } else { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_MASK, 1); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DIRECTION, 1); snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 0); } } On 2012年02月16日 10:04, Joey Jiao wrote: > 1. I changed to model=will to test without headphone > hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] > Result: for sure not work as GPIO not open > 2. I changed to model=b1900 to test without headphone > hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 > Result: speaker still works. It's for sure. > 3. Then same condition as step 2 but change 0xC0 to 0x0 > hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 > Result: speaker doesn't work only when NID=0x0F; then I tried > param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, > speaker doesn't work. > 4. Then I plugged in headphone. > Now the param =0x40 for NID=0x0F. > Result: Headphone works while speaker muted. > Then I changed param=0x80. (same result when param=0xC0) > Result: Headphone still works while speaker muted. > 5. Then I reboot with headphone plugged in to test your step 2. > YES, now the speaker muted while headphone works. > Then I do your cmds: > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 > Result: headphone works, speaker muted > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 > Result: headphone muted, speaker works > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 > Result: headphone works, speaker muted > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 > Result: headphone muted, speaker works. > Please noted the last two cmds, it's strange but it's true. > > Any additional tests? > > 在 2012年2月15日 下午11:04,Takashi Iwai<tiwai@suse.de> 写道: >> At Wed, 15 Feb 2012 22:45:27 +0800, >> joey.jiaojg wrote: >>> I think the only question below is about the automute, right? >> Not really. The most important thing is to understand what's doing >> what. Since your code can't be applied any longer at all to the >> latest code tree because of the fundamental code rewrite, we need to >> do it right. >> >> So, please check the following: >> >> 1. Does any pin correspond to the speaker output? Try to change the >> pin control of each pin between 0x10 and 0x19 via hda-verb while >> the speaker output is active. Does any pin change the speaker >> output? >> >> 2. Plug your headphone. Now the speaker is muted with your patch. >> What happens when you run like below? >> >> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 >> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 >> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1 >> >> Does the speaker starts playing again? Then, what happens now >> with: >> >> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0 >> >> ?? >> >> >> Takashi > > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-16 3:41 ` joey.jiaojg @ 2012-02-16 9:36 ` Takashi Iwai 0 siblings, 0 replies; 23+ messages in thread From: Takashi Iwai @ 2012-02-16 9:36 UTC (permalink / raw) To: joey.jiaojg; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Thu, 16 Feb 2012 11:41:10 +0800, joey.jiaojg wrote: > > And now this code works: > /* toggle speaker-output according to the hp-jack state */ > static void alc260_b1900_automute(struct hda_codec *codec) > { > unsigned int present; > > present = snd_hda_jack_detect(codec, 0x0f); > if (present) { > snd_hda_codec_write_cache(codec, 0x01, 0, > AC_VERB_SET_GPIO_MASK, 0); > snd_hda_codec_write_cache(codec, 0x01, 0, > AC_VERB_SET_GPIO_DIRECTION, > 0); > snd_hda_codec_write_cache(codec, 0x01, 0, > AC_VERB_SET_GPIO_DATA, > 1); > } else { > snd_hda_codec_write_cache(codec, 0x01, 0, > AC_VERB_SET_GPIO_MASK, 1); > snd_hda_codec_write_cache(codec, 0x01, 0, > AC_VERB_SET_GPIO_DIRECTION, > 1); > snd_hda_codec_write_cache(codec, 0x01, 0, > AC_VERB_SET_GPIO_DATA, > 0); > } > } The GPIO_MASK and GPIO_DIRECTION need to be set only once in the init verbs, both to 1. Then you just need to flip GPIO_DATA between 0 and 1 in the unsol event handler. Takashi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-16 2:04 ` Joey Jiao 2012-02-16 3:41 ` joey.jiaojg @ 2012-02-16 9:35 ` Takashi Iwai 2012-02-16 9:38 ` joey.jiaojg 1 sibling, 1 reply; 23+ messages in thread From: Takashi Iwai @ 2012-02-16 9:35 UTC (permalink / raw) To: Joey Jiao; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Thu, 16 Feb 2012 10:04:09 +0800, Joey Jiao wrote: > > 1. I changed to model=will to test without headphone > hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] > Result: for sure not work as GPIO not open > 2. I changed to model=b1900 to test without headphone > hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 > Result: speaker still works. It's for sure. > 3. Then same condition as step 2 but change 0xC0 to 0x0 > hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 > Result: speaker doesn't work only when NID=0x0F; then I tried > param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, > speaker doesn't work. > 4. Then I plugged in headphone. > Now the param =0x40 for NID=0x0F. > Result: Headphone works while speaker muted. > Then I changed param=0x80. (same result when param=0xC0) > Result: Headphone still works while speaker muted. > 5. Then I reboot with headphone plugged in to test your step 2. > YES, now the speaker muted while headphone works. > Then I do your cmds: > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 > Result: headphone works, speaker muted > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 > Result: headphone muted, speaker works > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 > Result: headphone works, speaker muted > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 > Result: headphone muted, speaker works. And, if you run again hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 I guess the speaker will be muted and the headphone start working again, right? > Please noted the last two cmds, it's strange but it's true. If my guess is correct, it's not strange at all. Your machine shares the same pin for both the headphone and the speaker outputs, but switches between them just by GPIO-out bit 0. It's _not_ the master amp. In addition, the HP-amp bit (0x80) of 0x0f seems controlling the speaker amp. Takashi > > Any additional tests? > > 在 2012年2月15日 下午11:04,Takashi Iwai <tiwai@suse.de> 写道: > > At Wed, 15 Feb 2012 22:45:27 +0800, > > joey.jiaojg wrote: > >> > >> I think the only question below is about the automute, right? > > > > Not really. The most important thing is to understand what's doing > > what. Since your code can't be applied any longer at all to the > > latest code tree because of the fundamental code rewrite, we need to > > do it right. > > > > So, please check the following: > > > > 1. Does any pin correspond to the speaker output? Try to change the > > pin control of each pin between 0x10 and 0x19 via hda-verb while > > the speaker output is active. Does any pin change the speaker > > output? > > > > 2. Plug your headphone. Now the speaker is muted with your patch. > > What happens when you run like below? > > > > hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 > > hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 > > hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1 > > > > Does the speaker starts playing again? Then, what happens now > > with: > > > > hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0 > > > > ?? > > > > > > Takashi > > > > -- > -Joey Jiao > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-16 9:35 ` Takashi Iwai @ 2012-02-16 9:38 ` joey.jiaojg 2012-02-16 9:41 ` Takashi Iwai 0 siblings, 1 reply; 23+ messages in thread From: joey.jiaojg @ 2012-02-16 9:38 UTC (permalink / raw) To: Takashi Iwai; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang YES, you are right on the assumption. I tried again many times of SET_GPIO_DATA between 0/1, speaker/headphone switches. So is possible to merge into next ALSA release? On 2012年02月16日 17:35, Takashi Iwai wrote: > At Thu, 16 Feb 2012 10:04:09 +0800, > Joey Jiao wrote: >> 1. I changed to model=will to test without headphone >> hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] >> Result: for sure not work as GPIO not open >> 2. I changed to model=b1900 to test without headphone >> hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 >> Result: speaker still works. It's for sure. >> 3. Then same condition as step 2 but change 0xC0 to 0x0 >> hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 >> Result: speaker doesn't work only when NID=0x0F; then I tried >> param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, >> speaker doesn't work. >> 4. Then I plugged in headphone. >> Now the param =0x40 for NID=0x0F. >> Result: Headphone works while speaker muted. >> Then I changed param=0x80. (same result when param=0xC0) >> Result: Headphone still works while speaker muted. >> 5. Then I reboot with headphone plugged in to test your step 2. >> YES, now the speaker muted while headphone works. >> Then I do your cmds: >> hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 >> Result: headphone works, speaker muted >> hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 >> Result: headphone muted, speaker works >> hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 >> Result: headphone works, speaker muted >> hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 >> Result: headphone muted, speaker works. > And, if you run again > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 > I guess the speaker will be muted and the headphone start working > again, right? > >> Please noted the last two cmds, it's strange but it's true. > If my guess is correct, it's not strange at all. Your machine shares > the same pin for both the headphone and the speaker outputs, but > switches between them just by GPIO-out bit 0. It's _not_ the master > amp. > > In addition, the HP-amp bit (0x80) of 0x0f seems controlling the > speaker amp. > > > Takashi > >> Any additional tests? >> >> 在 2012年2月15日 下午11:04,Takashi Iwai<tiwai@suse.de> 写道: >>> At Wed, 15 Feb 2012 22:45:27 +0800, >>> joey.jiaojg wrote: >>>> I think the only question below is about the automute, right? >>> Not really. The most important thing is to understand what's doing >>> what. Since your code can't be applied any longer at all to the >>> latest code tree because of the fundamental code rewrite, we need to >>> do it right. >>> >>> So, please check the following: >>> >>> 1. Does any pin correspond to the speaker output? Try to change the >>> pin control of each pin between 0x10 and 0x19 via hda-verb while >>> the speaker output is active. Does any pin change the speaker >>> output? >>> >>> 2. Plug your headphone. Now the speaker is muted with your patch. >>> What happens when you run like below? >>> >>> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 >>> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 >>> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1 >>> >>> Does the speaker starts playing again? Then, what happens now >>> with: >>> >>> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0 >>> >>> ?? >>> >>> >>> Takashi >> >> >> -- >> -Joey Jiao >> _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-16 9:38 ` joey.jiaojg @ 2012-02-16 9:41 ` Takashi Iwai 2012-02-16 9:42 ` Takashi Iwai 0 siblings, 1 reply; 23+ messages in thread From: Takashi Iwai @ 2012-02-16 9:41 UTC (permalink / raw) To: joey.jiaojg; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Thu, 16 Feb 2012 17:38:33 +0800, joey.jiaojg wrote: > > YES, you are right on the assumption. I tried again many times of > SET_GPIO_DATA between 0/1, speaker/headphone switches. > So is possible to merge into next ALSA release? Not ready for "merge". As mentioned, your patch can't be applied to the latest tree. I'll work on the better implementation of a quirk for the auto-parser later. Takashi > On 2012年02月16日 17:35, Takashi Iwai wrote: > > > At Thu, 16 Feb 2012 10:04:09 +0800, > > Joey Jiao wrote: > >> 1. I changed to model=will to test without headphone > >> hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 [NID=0x0F, 0x10~0x19, 0x1B] > >> Result: for sure not work as GPIO not open > >> 2. I changed to model=b1900 to test without headphone > >> hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0xC0 > >> Result: speaker still works. It's for sure. > >> 3. Then same condition as step 2 but change 0xC0 to 0x0 > >> hda-verb /dev/snd/hwC0D0 0x0F~0x1B 0x707 0x0 > >> Result: speaker doesn't work only when NID=0x0F; then I tried > >> param=0x40 and 0x80, when param=0x40, speaker works while param=0x80, > >> speaker doesn't work. > >> 4. Then I plugged in headphone. > >> Now the param =0x40 for NID=0x0F. > >> Result: Headphone works while speaker muted. > >> Then I changed param=0x80. (same result when param=0xC0) > >> Result: Headphone still works while speaker muted. > >> 5. Then I reboot with headphone plugged in to test your step 2. > >> YES, now the speaker muted while headphone works. > >> Then I do your cmds: > >> hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 1 > >> Result: headphone works, speaker muted > >> hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 1 > >> Result: headphone muted, speaker works > >> hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 > >> Result: headphone works, speaker muted > >> hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0 > >> Result: headphone muted, speaker works. > > And, if you run again > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 1 > > I guess the speaker will be muted and the headphone start working > > again, right? > > > >> Please noted the last two cmds, it's strange but it's true. > > If my guess is correct, it's not strange at all. Your machine shares > > the same pin for both the headphone and the speaker outputs, but > > switches between them just by GPIO-out bit 0. It's _not_ the master > > amp. > > > > In addition, the HP-amp bit (0x80) of 0x0f seems controlling the > > speaker amp. > > > > > > Takashi > > > >> Any additional tests? > >> > >> 在 2012年2月15日 下午11:04,Takashi Iwai<tiwai@suse.de> 写道: > >>> At Wed, 15 Feb 2012 22:45:27 +0800, > >>> joey.jiaojg wrote: > >>>> I think the only question below is about the automute, right? > >>> Not really. The most important thing is to understand what's doing > >>> what. Since your code can't be applied any longer at all to the > >>> latest code tree because of the fundamental code rewrite, we need to > >>> do it right. > >>> > >>> So, please check the following: > >>> > >>> 1. Does any pin correspond to the speaker output? Try to change the > >>> pin control of each pin between 0x10 and 0x19 via hda-verb while > >>> the speaker output is active. Does any pin change the speaker > >>> output? > >>> > >>> 2. Plug your headphone. Now the speaker is muted with your patch. > >>> What happens when you run like below? > >>> > >>> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_MASK 1 > >>> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DIR 1 > >>> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 1 > >>> > >>> Does the speaker starts playing again? Then, what happens now > >>> with: > >>> > >>> hda-verb /dev/snd/hwD0D0 0x01 SET_GPIO_DATA 0 > >>> > >>> ?? > >>> > >>> > >>> Takashi > >> > >> > >> -- > >> -Joey Jiao > >> > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-16 9:41 ` Takashi Iwai @ 2012-02-16 9:42 ` Takashi Iwai 2012-02-16 9:52 ` joey.jiaojg 0 siblings, 1 reply; 23+ messages in thread From: Takashi Iwai @ 2012-02-16 9:42 UTC (permalink / raw) To: joey.jiaojg; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang At Thu, 16 Feb 2012 10:41:32 +0100, Takashi Iwai wrote: > > At Thu, 16 Feb 2012 17:38:33 +0800, > joey.jiaojg wrote: > > > > YES, you are right on the assumption. I tried again many times of > > SET_GPIO_DATA between 0/1, speaker/headphone switches. > > So is possible to merge into next ALSA release? > > Not ready for "merge". As mentioned, your patch can't be applied to > the latest tree. > > I'll work on the better implementation of a quirk for the auto-parser > later. Oh, for that, could you give alsa-info.sh output? Attach the output file (don't paste) obtained with --no-upload option. thanks, Takashi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series 2012-02-16 9:42 ` Takashi Iwai @ 2012-02-16 9:52 ` joey.jiaojg 0 siblings, 0 replies; 23+ messages in thread From: joey.jiaojg @ 2012-02-16 9:52 UTC (permalink / raw) To: Takashi Iwai; +Cc: Raymond Yau, pshou, ALSA Development Mailing List, kailang [-- Attachment #1: Type: text/plain, Size: 1741 bytes --] Good news, anyway. Attached alsa-info.txt with model=b1900. And I followed to use only data for automute while set_gpio inside init_verb; which works. Below is the code (attached diff): /* toggle speaker-output according to the hp-jack state */ static void alc260_b1900_automute(struct hda_codec *codec) { unsigned int present; present = snd_hda_jack_detect(codec, 0x0f); if (present) { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 1); } else { snd_hda_codec_write_cache(codec, 0x01, 0, AC_VERB_SET_GPIO_DATA, 0); } } static const struct hda_verb alc260_b1900_verbs[] = { {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, {0x01, AC_VERB_SET_GPIO_MASK, 0x01}, {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x01}, {0x0f, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | ALC880_HP_EVENT}, {} }; On 2012年02月16日 17:42, Takashi Iwai wrote: > At Thu, 16 Feb 2012 10:41:32 +0100, > Takashi Iwai wrote: >> At Thu, 16 Feb 2012 17:38:33 +0800, >> joey.jiaojg wrote: >>> YES, you are right on the assumption. I tried again many times of >>> SET_GPIO_DATA between 0/1, speaker/headphone switches. >>> So is possible to merge into next ALSA release? >> Not ready for "merge". As mentioned, your patch can't be applied to >> the latest tree. >> >> I'll work on the better implementation of a quirk for the auto-parser >> later. > Oh, for that, could you give alsa-info.sh output? > Attach the output file (don't paste) obtained with --no-upload > option. > > > thanks, > > Takashi [-- Attachment #2: alsa-info.txt.43zkD2qbEy --] [-- Type: text/plain, Size: 24251 bytes --] upload=true&script=true&cardinfo= !!################################ !!ALSA Information Script v 0.4.60 !!################################ !!Script ran on: Thu Feb 16 09:48:25 UTC 2012 !!Linux Distribution !!------------------ Ubuntu 11.10 \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 11.10" !!DMI Information !!--------------- Manufacturer: Hewlett-Packard Product Name: Presario B1900 (RR178PA#AB2) Product Version: F.0A !!Kernel Information !!------------------ Kernel release: 3.0.13tiny Operating System: GNU/Linux Architecture: i686 Processor: i686 SMP Enabled: Yes !!ALSA Version !!------------ Driver version: 1.0.24 Library version: 1.0.25 Utilities version: 1.0.24.2 !!Loaded ALSA modules !!------------------- snd_hda_intel !!Sound Servers on this system !!---------------------------- Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes ESound Daemon: Installed - Yes (/usr/bin/esd) Running - No !!Soundcards recognised by ALSA !!----------------------------- 0 [SB ]: HDA-Intel - HDA ATI SB HDA ATI SB at 0xc0500000 irq 42 !!PCI Soundcards installed in the system !!-------------------------------------- 00:14.2 Audio device: ATI Technologies Inc IXP SB4x0 High Definition Audio Controller (rev 01) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!-------------------------------------------------------- 00:14.2 0403: 1002:437b (rev 01) Subsystem: 103c:30ba !!Modprobe options (Sound related) !!-------------------------------- snd-atiixp-modem: index=-2 snd-intel8x0m: index=-2 snd-via82xx-modem: index=-2 snd-usb-audio: index=-2 snd-usb-caiaq: index=-2 snd-usb-ua101: index=-2 snd-usb-us122l: index=-2 snd-usb-usx2y: index=-2 snd-cmipci: mpu_port=0x330 fm_port=0x388 snd-pcsp: index=-2 snd-usb-audio: index=-2 snd-hda-intel: model=b1900 !!Loaded sound module options !!-------------------------- !!Module: snd_hda_intel bdl_pos_adj : 32,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 beep_mode : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable_msi : -1 id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 model : b1900,(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) position_fix : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 power_save : 0 power_save_controller : Y probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 single_cmd : N !!HDA-Intel Codec information !!--------------------------- --startcollapse-- Codec: Realtek ALC260 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0260 Subsystem Id: 0x103c0000 Revision Id: 0x100400 No Modem Function Group found Default PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=4, o=0, i=0, unsolicited=1, wake=0 IO[0]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 Node 0x02 [Audio Output] wcaps 0x11: Stereo Device: name="ALC260 Analog", type="Audio", device=0 Converter: stream=5, channel=0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x03 [Audio Output] wcaps 0x211: Stereo Digital Control: name="IEC958 Playback Con Mask", index=0, device=0 Control: name="IEC958 Playback Pro Mask", index=0, device=0 Control: name="IEC958 Playback Default", index=0, device=0 Control: name="IEC958 Playback Switch", index=0, device=0 Control: name="IEC958 Default PCM Playback Switch", index=0, device=0 Device: name="ALC260 Digital", type="SPDIF", device=1 Converter: stream=8, channel=0 Digital: Enabled Digital category: 0x0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0x1e]: 16 20 24 32 formats [0x1]: PCM Node 0x04 [Audio Input] wcaps 0x10011b: Stereo Amp-In Control: name="Input Source", index=0, device=0 Control: name="Capture Switch", index=0, device=0 Control: name="Capture Volume", index=0, device=0 Device: name="ALC260 Analog", type="Audio", device=0 Amp-In caps: ofs=0x00, nsteps=0x23, stepsize=0x03, mute=1 Amp-In vals: [0x17 0x17] [0x17 0x17] [0x17 0x17] [0x17 0x17] [0x17 0x17] [0x17 0x17] [0x17 0x17] Converter: stream=1, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0x6]: 16 20 formats [0x1]: PCM Connection: 7 0x12 0x13 0x14* 0x15 0x16 0x0f 0x10 Node 0x05 [Audio Input] wcaps 0x10011b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x23, stepsize=0x03, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0x6]: 16 20 formats [0x1]: PCM Connection: 8 0x12 0x13 0x14* 0x15 0x16 0x07 0x0f 0x10 Node 0x06 [Audio Input] wcaps 0x100391: Stereo Digital Converter: stream=0, channel=0 SDI-Select: 0 Digital: Digital category: 0x0 PCM: rates [0x160]: 44100 48000 96000 bits [0x1e]: 16 20 24 32 formats [0x1]: PCM Unsolicited: tag=00, enabled=0 Connection: 1 0x19 Node 0x07 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Line Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Line Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="CD Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Control: name="CD Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Control: name="Beep Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=5, ofs=0 Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=5, ofs=0 Amp-In caps: ofs=0x23, nsteps=0x41, stepsize=0x03, mute=1 Amp-In vals: [0x33 0x33] [0x80 0x80] [0x3b 0x3b] [0x80 0x80] [0x33 0x33] [0x00 0x00] [0xa3 0xa3] [0xa3 0xa3] Connection: 8 0x12 0x13 0x14 0x15 0x16 0x17 0x0f 0x10 Node 0x08 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out Control: name="Master Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x2f 0x2f] Connection: 2 0x02 0x07 Node 0x09 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x00 0x00] Connection: 2 0x02 0x07 Node 0x0a [Audio Mixer] wcaps 0x20010e: Mono Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80] [0x80] Amp-Out caps: ofs=0x23, nsteps=0x41, stepsize=0x03, mute=0 Amp-Out vals: [0x00] Connection: 2 0x02 0x07 Node 0x0b [Audio Selector] wcaps 0x300101: Stereo Connection: 2 0x08* 0x09 Node 0x0c [Audio Selector] wcaps 0x300101: Stereo Connection: 2 0x08* 0x09 Node 0x0d [Audio Selector] wcaps 0x300101: Stereo Connection: 2 0x08* 0x09 Node 0x0e [Audio Selector] wcaps 0x300101: Stereo Connection: 2 0x08* 0x09 Node 0x0f [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001003f: IN OUT HP EAPD Detect Trigger ImpSense EAPD 0x2: EAPD Pin Default 0x01014110: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0xc0: OUT HP Unsolicited: tag=04, enabled=1 Connection: 1 0x08 Node 0x10 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001003f: IN OUT HP EAPD Detect Trigger ImpSense EAPD 0x2: EAPD Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0xc0: OUT HP Unsolicited: tag=00, enabled=0 Connection: 1 0x09 Node 0x11 [Pin Complex] wcaps 0x40010c: Mono Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00] Pincap 0x00000010: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x0a Node 0x12 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Control: name="Mic Jack Mode", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000133f: IN OUT HP Detect Trigger ImpSense Vref caps: HIZ 50 80 Pin Default 0x01a19c30: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x21: IN VREF_50 Unsolicited: tag=00, enabled=0 Connection: 1 0x0b Node 0x13 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000133f: IN OUT HP Detect Trigger ImpSense Vref caps: HIZ 50 80 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Connection: 1 0x0c Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Control: name="Line Jack Mode", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000133f: IN OUT HP Detect Trigger ImpSense Vref caps: HIZ 50 80 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x21: IN VREF_50 Unsolicited: tag=00, enabled=0 Connection: 1 0x0d Node 0x15 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000133f: IN OUT HP Detect Trigger ImpSense Vref caps: HIZ 50 80 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 1 0x0e Node 0x16 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x00000020: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Node 0x17 [Pin Complex] wcaps 0x400000: Mono Pincap 0x00000020: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Node 0x18 [Pin Complex] wcaps 0x400380: Mono Digital Pincap 0x00000014: OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Connection: 1 0x03 Node 0x19 [Pin Complex] wcaps 0x400280: Mono Digital Pincap 0x00000024: IN Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Node 0x1a [Vendor Defined Widget] wcaps 0xf00040: Mono Processing caps: benign=0, ncoeff=13 Node 0x1b [Volume Knob Widget] wcaps 0x600080: Mono Volume-Knob: delta=0, steps=64, direct=0, val=0 Unsolicited: tag=00, enabled=0 Connection: 0 Codec: Conexant ID 2bfa Address: 1 MFG Function Id: 0x2 (unsol 1) Vendor Id: 0x14f12bfa Subsystem Id: 0x103c30ba Revision Id: 0x90000 Modem Function Group: 0x2 --endcollapse-- !!ALSA Device nodes !!----------------- crw-rw----+ 1 root audio 116, 7 Feb 16 17:46 /dev/snd/controlC0 crw-rw----+ 1 root audio 116, 6 Feb 16 17:46 /dev/snd/hwC0D0 crw-rw----+ 1 root audio 116, 5 Feb 16 17:46 /dev/snd/hwC0D1 crw-rw----+ 1 root audio 116, 4 Feb 16 17:46 /dev/snd/pcmC0D0c crw-rw----+ 1 root audio 116, 3 Feb 16 17:48 /dev/snd/pcmC0D0p crw-rw----+ 1 root audio 116, 2 Feb 16 17:46 /dev/snd/pcmC0D1p crw-rw----+ 1 root audio 116, 1 Feb 16 17:46 /dev/snd/seq crw-rw----+ 1 root audio 116, 33 Feb 16 17:46 /dev/snd/timer /dev/snd/by-path: total 0 drwxr-xr-x 2 root root 60 Feb 16 17:46 . drwxr-xr-x 3 root root 220 Feb 16 17:46 .. lrwxrwxrwx 1 root root 12 Feb 16 17:46 pci-0000:00:14.2 -> ../controlC0 !!Aplay/Arecord output !!------------ APLAY **** List of PLAYBACK Hardware Devices **** card 0: SB [HDA ATI SB], device 0: ALC260 Analog [ALC260 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: SB [HDA ATI SB], device 1: ALC260 Digital [ALC260 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 ARECORD **** List of CAPTURE Hardware Devices **** card 0: SB [HDA ATI SB], device 0: ALC260 Analog [ALC260 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 !!Amixer output !!------------- !!-------Mixer controls for card 0 [SB] Card hw:0 'SB'/'HDA ATI SB at 0xc0500000 irq 42' Mixer name : 'Realtek ALC260' Components : 'HDA:10ec0260,103c0000,00100400 HDA:14f12bfa,103c30ba,00090000' Controls : 22 Simple ctrls : 13 Simple mixer control 'Master',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 64 Mono: Front Left: Playback 47 [73%] [-17.00dB] [on] Front Right: Playback 47 [73%] [-17.00dB] [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [0.00dB] Front Right: Playback 255 [100%] [0.00dB] Simple mixer control 'Line',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65 Mono: Front Left: Playback 59 [91%] [24.00dB] [on] Front Right: Playback 59 [91%] [24.00dB] [on] Simple mixer control 'Line Jack Mode',0 Capabilities: enum Items: 'Mic 50pc bias' 'Mic 80pc bias' 'Line in' 'Line out' 'Headphone out' Item0: 'Mic 50pc bias' Simple mixer control 'CD',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65 Mono: Front Left: Playback 51 [78%] [16.00dB] [on] Front Right: Playback 51 [78%] [16.00dB] [on] Simple mixer control 'Mic',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65 Mono: Front Left: Playback 51 [78%] [16.00dB] [on] Front Right: Playback 51 [78%] [16.00dB] [on] Simple mixer control 'Mic Jack Mode',0 Capabilities: enum Items: 'Mic 50pc bias' 'Mic 80pc bias' 'Line in' Item0: 'Mic 50pc bias' Simple mixer control 'IEC958',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Default PCM',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'Beep',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 65 Mono: Front Left: Playback 0 [0%] [-35.00dB] [on] Front Right: Playback 0 [0%] [-35.00dB] [on] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 35 Front Left: Capture 23 [66%] [23.00dB] [on] Front Right: Capture 23 [66%] [23.00dB] [on] Simple mixer control 'Digital',0 Capabilities: cvolume penum Capture channels: Front Left - Front Right Limits: Capture 0 - 120 Front Left: Capture 60 [50%] [0.00dB] Front Right: Capture 60 [50%] [0.00dB] Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Mic' 'Front Mic' 'Line' 'CD' Item0: 'Mic' !!Alsactl output !!------------- --startcollapse-- state.SB { control.1 { iface MIXER name 'Master Playback Volume' value.0 47 value.1 47 comment { access 'read write' type INTEGER count 2 range '0 - 64' dbmin -6400 dbmax 0 dbvalue.0 -1700 dbvalue.1 -1700 } } control.2 { iface MIXER name 'Master Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.3 { iface MIXER name 'Mic Playback Volume' value.0 51 value.1 51 comment { access 'read write' type INTEGER count 2 range '0 - 65' dbmin -3500 dbmax 3000 dbvalue.0 1600 dbvalue.1 1600 } } control.4 { iface MIXER name 'Mic Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.5 { iface MIXER name 'Mic Jack Mode' value 'Mic 50pc bias' comment { access 'read write' type ENUMERATED count 1 item.0 'Mic 50pc bias' item.1 'Mic 80pc bias' item.2 'Line in' } } control.6 { iface MIXER name 'Line Playback Volume' value.0 59 value.1 59 comment { access 'read write' type INTEGER count 2 range '0 - 65' dbmin -3500 dbmax 3000 dbvalue.0 2400 dbvalue.1 2400 } } control.7 { iface MIXER name 'Line Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.8 { iface MIXER name 'Line Jack Mode' value 'Mic 50pc bias' comment { access 'read write' type ENUMERATED count 1 item.0 'Mic 50pc bias' item.1 'Mic 80pc bias' item.2 'Line in' item.3 'Line out' item.4 'Headphone out' } } control.9 { iface MIXER name 'CD Playback Volume' value.0 51 value.1 51 comment { access 'read write' type INTEGER count 2 range '0 - 65' dbmin -3500 dbmax 3000 dbvalue.0 1600 dbvalue.1 1600 } } control.10 { iface MIXER name 'CD Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.11 { iface MIXER name 'Capture Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.12 { iface MIXER name 'Capture Volume' value.0 23 value.1 23 comment { access 'read write' type INTEGER count 2 range '0 - 35' dbmin 0 dbmax 3500 dbvalue.0 2300 dbvalue.1 2300 } } control.13 { iface MIXER name 'Input Source' value Mic comment { access 'read write' type ENUMERATED count 1 item.0 Mic item.1 'Front Mic' item.2 Line item.3 CD } } control.14 { iface MIXER name 'IEC958 Playback Con Mask' value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.15 { iface MIXER name 'IEC958 Playback Pro Mask' value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.16 { iface MIXER name 'IEC958 Playback Default' value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access 'read write' type IEC958 count 1 } } control.17 { iface MIXER name 'IEC958 Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.18 { iface MIXER name 'IEC958 Default PCM Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.19 { iface MIXER name 'Beep Playback Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 65' dbmin -3500 dbmax 3000 dbvalue.0 -3500 dbvalue.1 -3500 } } control.20 { iface MIXER name 'Beep Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.21 { iface MIXER name 'PCM Playback Volume' value.0 255 value.1 255 comment { access 'read write user' type INTEGER count 2 range '0 - 255' tlv '0000000100000008ffffec1400000014' dbmin -5100 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.22 { iface MIXER name 'Digital Capture Volume' value.0 60 value.1 60 comment { access 'read write user' type INTEGER count 2 range '0 - 120' tlv '0000000100000008fffff44800000032' dbmin -3000 dbmax 3000 dbvalue.0 0 dbvalue.1 0 } } } --endcollapse-- !!All Loaded Modules !!------------------ Module rfcomm bnep pci_stub vboxpci vboxnetadp vboxnetflt vboxdrv parport_pc ppdev binfmt_misc snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm arc4 snd_seq_midi joydev snd_rawmidi b43 snd_seq_midi_event radeon ttm drm_kms_helper snd_seq btusb mac80211 drm cfg80211 bluetooth snd_timer snd_seq_device snd video i2c_algo_bit r592 memstick psmouse serio_raw soundcore snd_page_alloc shpchp i2c_piix4 ssb ati_agp lp parport hid_a4tech usbhid firewire_ohci sdhci_pci 8139too firewire_core hid sdhci 8139cp crc_itu_t sata_sil pata_atiixp !!Sysfs Files !!----------- /sys/class/sound/hwC0D0/init_pin_configs: 0x0f 0x01014110 0x10 0x411111f0 0x11 0x411111f0 0x12 0x01a19c30 0x13 0x411111f0 0x14 0x411111f0 0x15 0x411111f0 0x16 0x411111f0 0x17 0x411111f0 0x18 0x411111f0 0x19 0x411111f0 /sys/class/sound/hwC0D0/driver_pin_configs: /sys/class/sound/hwC0D0/user_pin_configs: /sys/class/sound/hwC0D0/init_verbs: /sys/class/sound/hwC0D1/init_pin_configs: 0x73 0x016a0000 /sys/class/sound/hwC0D1/driver_pin_configs: /sys/class/sound/hwC0D1/user_pin_configs: /sys/class/sound/hwC0D1/init_verbs: !!ALSA/HDA dmesg !!------------------ [ 18.903636] [drm] Initialized radeon 2.10.0 20080528 for 0000:01:05.0 on minor 0 [ 19.178879] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 19.179002] HDA Intel 0000:00:14.2: irq 42 for MSI/MSI-X [ 19.706997] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro [-- Attachment #3: diff.txt --] [-- Type: text/plain, Size: 3518 bytes --] --- /usr/src/linux/sound/pci/hda/patch_realtek.c.bk 2012-02-14 22:04:36.351729299 +0800 +++ /usr/src/linux/sound/pci/hda/patch_realtek.c 2012-02-16 17:41:59.022196749 +0800 @@ -80,6 +80,7 @@ enum { ALC260_WILL, ALC260_REPLACER_672V, ALC260_FAVORIT100, + ALC260_B1900, #ifdef CONFIG_SND_DEBUG ALC260_TEST, #endif @@ -1323,6 +1324,24 @@ static void alc_inithook(struct hda_code alc_mic_automute(codec); } +/* toggle speaker-output according to the hp-jack state */ +static void alc260_b1900_automute(struct hda_codec *codec) +{ + unsigned int present; + + present = snd_hda_jack_detect(codec, 0x0f); + if (present) { + snd_hda_codec_write_cache(codec, 0x01, 0, + AC_VERB_SET_GPIO_DATA, + 1); + } else { + snd_hda_codec_write_cache(codec, 0x01, 0, + AC_VERB_SET_GPIO_DATA, + 0); + } +} + + /* additional initialization for ALC888 variants */ static void alc888_coef_init(struct hda_codec *codec) { @@ -6899,6 +6918,20 @@ static const struct hda_verb alc260_will {} }; +static const struct hda_verb alc260_b1900_verbs[] = { + {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, + {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, + {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, + {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, + {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, + {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, + {0x01, AC_VERB_SET_GPIO_MASK, 0x01}, + {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x01}, + {0x0f, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | ALC880_HP_EVENT}, + {} +}; + + static const struct hda_verb alc260_replacer_672v_verbs[] = { {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, @@ -6941,6 +6974,12 @@ static void alc260_replacer_672v_unsol_e alc260_replacer_672v_automute(codec); } +static void alc260_b1900_unsol_event(struct hda_codec *codec, + unsigned int res) +{ + if ((res >> 26) == ALC880_HP_EVENT) + alc260_b1900_automute(codec); +} static const struct hda_verb alc260_hp_dc7600_verbs[] = { {0x05, AC_VERB_SET_CONNECT_SEL, 0x01}, {0x15, AC_VERB_SET_CONNECT_SEL, 0x01}, @@ -7431,6 +7470,7 @@ static const char * const alc260_models[ [ALC260_WILL] = "will", [ALC260_REPLACER_672V] = "replacer", [ALC260_FAVORIT100] = "favorit100", + [ALC260_B1900] = "b1900", #ifdef CONFIG_SND_DEBUG [ALC260_TEST] = "test", #endif @@ -7458,6 +7498,7 @@ static const struct snd_pci_quirk alc260 SND_PCI_QUIRK(0x152d, 0x0729, "CTL U553W", ALC260_BASIC), SND_PCI_QUIRK(0x161f, 0x2057, "Replacer 672V", ALC260_REPLACER_672V), SND_PCI_QUIRK(0x1631, 0xc017, "PB V7900", ALC260_WILL), + SND_PCI_QUIRK(0x103c, 0x007f, "HP COMPAQ", ALC260_B1900), {} }; @@ -7570,6 +7611,20 @@ static const struct alc_config_preset al .channel_mode = alc260_modes, .input_mux = &alc260_capture_source, }, + [ALC260_B1900] = { + .mixers = { alc260_will_mixer }, + .init_verbs = { alc260_init_verbs, alc260_b1900_verbs }, + .num_dacs = ARRAY_SIZE(alc260_dac_nids), + .dac_nids = alc260_dac_nids, + .num_adc_nids = ARRAY_SIZE(alc260_adc_nids), + .adc_nids = alc260_adc_nids, + .dig_out_nid = ALC260_DIGOUT_NID, + .num_channel_mode = ARRAY_SIZE(alc260_modes), + .channel_mode = alc260_modes, + .input_mux = &alc260_capture_source, + .unsol_event = alc260_b1900_unsol_event, + .init_hook = alc260_b1900_automute, + }, [ALC260_REPLACER_672V] = { .mixers = { alc260_replacer_672v_mixer }, .init_verbs = { alc260_init_verbs, alc260_replacer_672v_verbs }, [-- Attachment #4: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2012-02-16 9:52 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4F35C191.9080401@gmail.com>
2012-02-11 2:05 ` Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series Jonathan Woithe
2012-02-15 0:50 ` Raymond Yau
[not found] ` <CAKOmCvoS+tgvyPZJey4gfFFq=Uz01pnZY7YvGbxgQPpAzQ7KCA@mail.gmail.com>
2012-02-15 1:29 ` Joey Jiao
2012-02-15 2:49 ` Raymond Yau
[not found] ` <4F3B761D.4060306@gmail.com>
2012-02-15 9:22 ` Takashi Iwai
2012-02-15 9:31 ` joey.jiaojg
2012-02-15 9:40 ` Takashi Iwai
2012-02-15 9:45 ` joey.jiaojg
2012-02-15 9:58 ` Takashi Iwai
2012-02-15 10:06 ` joey.jiaojg
2012-02-15 10:11 ` Takashi Iwai
2012-02-15 13:14 ` joey.jiaojg
2012-02-15 13:21 ` Takashi Iwai
2012-02-15 14:45 ` joey.jiaojg
2012-02-15 15:04 ` Takashi Iwai
2012-02-16 2:04 ` Joey Jiao
2012-02-16 3:41 ` joey.jiaojg
2012-02-16 9:36 ` Takashi Iwai
2012-02-16 9:35 ` Takashi Iwai
2012-02-16 9:38 ` joey.jiaojg
2012-02-16 9:41 ` Takashi Iwai
2012-02-16 9:42 ` Takashi Iwai
2012-02-16 9:52 ` joey.jiaojg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).