Bug#660111: multiple, non-physically accesible, HDMI devices

On 09/29/2012 01:47 PM, Jonathan Nieder wrote: Shouldn't we consider reverting 384a48d71520 (ALSA: hda: HDMI: Support codecs with fewer cvts than pins, 2011-06-01) in wheezy if userspace hasn't caught up with the new order of things? I haven't looked deeply into this or tried it, but it seems at

Bug#660111: multiple, non-physically accesible, HDMI devices

Andres Cimmarusti wrote: > Has this been backported? Personally I think this bug should closed > whether it's been backported or not. The gain in backporting jack > detection is minimal because the GUI's haven't completely caught up > with this feature yet as David mentioned and the user still nee

Bug#660111: multiple, non-physically accesible, HDMI devices (Re: pulseaudio: pa can't handle multiple HDMI devices)

> You're correct; even if the information is there, it isn't advertised in > pavucontrol. I should probably implement that... > (If you're using Ubuntu 12.04, you will have a new sound settings UI that > hides unavailable devices. For upstreaming of this UI please see the > gnome-cc list.) > > What

Bug#660111: multiple, non-physically accesible, HDMI devices (Re: pulseaudio: pa can't handle multiple HDMI devices)

On 06/11/2012 02:40 AM, Andres Cimmarusti wrote: On Sun, Jun 10, 2012 at 8:25 PM, Andres Cimmarusti wrote: Andres, do you know of relevant commit ids? Can you describe the difference in behavior between 3.2.19-1 and 3.4.1-1~experimental.1 and whether it's worth backporting these changes? I

Bug#660111: multiple, non-physically accesible, HDMI devices (Re: pulseaudio: pa can't handle multiple HDMI devices)

On Sun, Jun 10, 2012 at 8:25 PM, Andres Cimmarusti wrote: >> Andres, do you know of relevant commit ids?  Can you describe the >> difference in behavior between 3.2.19-1 and 3.4.1-1~experimental.1 and >> whether it's worth backporting these changes? > > I will try the kernel from experimental and

Bug#660111: multiple, non-physically accesible, HDMI devices (Re: pulseaudio: pa can't handle multiple HDMI devices)

> Andres, do you know of relevant commit ids?  Can you describe the > difference in behavior between 3.2.19-1 and 3.4.1-1~experimental.1 and > whether it's worth backporting these changes? I will try the kernel from experimental and let you know if the changes are worth while. Unfortunately I have

Bug#660111: pulseaudio: pa can't handle multiple HDMI devices -- chooses wrong default

Andres Cimmarusti wrote: > PA 2.0 can handle all the HDMI outputs advertised by the kernel, but > one has to try all of them using pavucontrol to find the "correct" > one. > With kernel's 3.3 jack detection, this is done automatically. Presumably this means 01a61e12b460 ALSA: hda - Create jack

Bug#660111: multiple, non-physically accesible, HDMI devices (Re: pulseaudio: pa can't handle multiple HDMI devices)

Ben Hutchings wrote: > Do we still need to make kernel changes for wheezy, or does the new PA > together with the current kernel package (version 3.2.19-1) avoid this > problem? I think Andres mentioned some patches that expose detected jack status using kcontrols. Andres, do you know of relevan

Bug#660111: Bug#664653 pulseaudio: pa can't handle multiple HDMI devices -- chooses wrong default

> Do we still need to make kernel changes for wheezy, or does the new PA > together with the current kernel package (version 3.2.19-1) avoid this > problem? PA 2.0 can handle all the HDMI outputs advertised by the kernel, but one has to try all of them using pavucontrol to find the "correct" one.

Bug#660111: Bug#664653 pulseaudio: pa can't handle multiple HDMI devices -- chooses wrong default

On Sun, 2012-06-10 at 15:37 -0400, Andres Cimmarusti wrote: > fixed 664653 2.0-3 > thanks > > As I reported earlier, version 2.0 of pulseaudio can handle multiple > HDMI outputs. Bug# 664653 is completely fixed. I've tested it > successfully in my computer. Do we still need to make kernel changes

Bug#660111: Bug#664653 pulseaudio: pa can't handle multiple HDMI devices -- chooses wrong default

fixed 664653 2.0-3 thanks As I reported earlier, version 2.0 of pulseaudio can handle multiple HDMI outputs. Bug# 664653 is completely fixed. I've tested it successfully in my computer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Troub

Bug#660111: Bug#664653 pulseaudio: pa can't handle multiple HDMI devices -- chooses wrong default

tags 664653 fixed-upstream thanks Pulseaudio upstream version 1.99.1 (or master, specifically after commit e02cb7fb2e7865affed612693935c7fd698e3a6b) contains all the necessary bits to allow the user to select from several HDMI devices advertised by the kernel. Please consider packaging. Andres

Bug#660111: multiple, non-physically accesible, HDMI devices

block 660111 by 664653 quit Andres Cimmarusti wrote: > Done, see bug report: http://bugs.debian.org/664653 Thanks! I guess let's put backporting the kernel-side HDMI jack detection patches on hold until pulseaudio 2 gets packaged, unless you know of some easy alternative test for whether the ja

Bug#660111: multiple, non-physically accesible, HDMI devices

> Could you file a new report against pulseaudio summarizing the problem > and your suggested fix and mentioning > for background? Done, see bug report: http://bugs.debian.org/664653 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a su

Bug#660111: multiple, non-physically accesible, HDMI devices

tags 660111 + upstream # letting version tracking do its work tags 660111 - wheezy quit Hi Andres, Andres Cimmarusti wrote: > I've marked this bug as affecting pulseaudio. In fact, it seems (to > me) sufficient to get version 2.0 of pulseaudio into Debian to solve > this bug. > > With convenienc

Bug#660111: multiple, non-physically accesible, HDMI devices

retitle 660111 multiple, non-physically accesible, HDMI devices affects 660111 + pulseaudio tags 660111 + fixed-upstream wheezy thanks >> (but correct me if I'm wrong). However, I think Debian has decided to >> go with 3.2 kernel for the next stable release. This means no >> kcontrols. How is this

Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

On 03/16/2012 04:03 PM, Andres Cimmarusti wrote: Hello again, On Sat, Mar 3, 2012 at 9:43 PM, David Henningsson wrote: On 03/04/2012 12:36 AM, Andres Cimmarusti wrote: There is active work going on in this area. In fact, I just posted a patch to the PA mailinglist [1]. And yes, we already h

Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

Hello again, On Sat, Mar 3, 2012 at 9:43 PM, David Henningsson wrote: > On 03/04/2012 12:36 AM, Andres Cimmarusti wrote: >>> >>> There is active work going on in this area. In fact, I just posted a >>> patch >>> to the PA mailinglist [1]. And yes, we already have it in Ubuntu 11.10 >>> (to >>> pr

Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

At Sun, 04 Mar 2012 03:43:20 +0100, David Henningsson wrote: > > >> Let me also push for the hda-jack-retask [2] application, which is an > >> easy-to-use GUI for creating these types of firmware files. I advertised it > >> here a while ago [3] but it seems to have gone unnoticed. > > > > This sou

Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

On 03/04/2012 12:36 AM, Andres Cimmarusti wrote: There is active work going on in this area. In fact, I just posted a patch to the PA mailinglist [1]. And yes, we already have it in Ubuntu 11.10 (to probe multiple hdmi devices for Intel and NVidia), and the main reason it took until now to upstre

Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

> There is active work going on in this area. In fact, I just posted a patch > to the PA mailinglist [1]. And yes, we already have it in Ubuntu 11.10 (to > probe multiple hdmi devices for Intel and NVidia), and the main reason it > took until now to upstream that patch, was the decision to switch j

Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

David Henningsson wrote at Thursday, February 23, 2012 1:31 AM: > On 02/23/2012 01:01 AM, Andres Cimmarusti wrote: > >> If the new two pins can be never used, i.e. physically unreachable, > >> we may disable these pins by giving the proper default pin-config > >> values. Usually it's a job of BIOS

Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

On 02/23/2012 01:01 AM, Andres Cimmarusti wrote: If the new two pins can be never used, i.e. physically unreachable, we may disable these pins by giving the proper default pin-config values. Usually it's a job of BIOS. But if BIOS doesn't do it, user need to do it manually. Build your kernel w

Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

On 02/22/2012 08:44 AM, Takashi Iwai wrote: At Wed, 22 Feb 2012 01:43:44 -0500, Andres Cimmarusti wrote: [1] Dear Mr. Warren, I recently upgraded my laptop to Debian testing (from Debian stable + the longterm stable 3.0.x kernel). The newer kernel 3.2.x came with a regression that git bisect h

Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

Andres Cimmarusti wrote at Wednesday, February 22, 2012 5:02 PM: > First of all, thank you for your feedback. It's been quite helpful / > insightful ... > > There are ways to configure pulseaudio to allow the user to select which > > PCM device to use on a given sound card. David Henningsson made

Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

First of all, thank you for your feedback. It's been quite helpful / insightful > The biggest problem is that PA checks only the first HDMI device. > In that sense, this is no regression in the kernel side, although I > know it's annoying. I agree this seems more like a shortcoming of pulseaudio.

Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

Stephen Warren wrote: > As Takashi mentions, from a kernel perspective, this isn't really a > regression at all, but simply exposing all the features of the HW that > were previously hidden. Without that change, others can't use some HW > usefully at all. Unfortunately, pulseaudio makes some rathe

Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

Andres Cimmarusti wrote at Tuesday, February 21, 2012 11:44 PM: ... > Unfortunately with kernel 3.2.x and 3.1.x I get no sound out choosing the same > configuration in pulseaudio. Device is advertised correctly but > there's a bizarre multiplicity advertised: > > $ aplay -l > List of PLAYBACK

Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

At Wed, 22 Feb 2012 01:43:44 -0500, Andres Cimmarusti wrote: > > [1 ] > Dear Mr. Warren, > > I recently upgraded my laptop to Debian testing (from Debian stable + > the longterm stable 3.0.x kernel). The newer kernel 3.2.x came with a > regression that git bisect has traced down to one of your c

Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

Dear Mr. Warren, I recently upgraded my laptop to Debian testing (from Debian stable + the longterm stable 3.0.x kernel). The newer kernel 3.2.x came with a regression that git bisect has traced down to one of your commits in the early 3.1.x kernel development stage (git bisect output and git bise

Bug#660111: [3.0 -> 3.1.8 regression] intel ibexpeak hdmi no sound out

Found the first bad commit. It was the one you suspected all along! I will submit this issue upstream. Thanks for your invaluable help and demos! Cheers Andres 384a48d71520ca569a63f1e61e51a538bedb16df is the first bad commit commit 384a48d71520ca569a63f1e61e51a538bedb16df Author: Stephen Warren

Bug#660111: [3.0 -> 3.1.8 regression] intel ibexpeak hdmi no sound out

Hi Andres, Andres Cimmarusti wrote: >> To be clear, are you saying "git bisect" told you that 76531d4166 was >> the first bad commit? > > Not exactly. I told you I got confused on how to use git-bisect My bad. I forgot I hadn't given the git bisect demo. So, it works like this: git bi

Bug#660111: [3.0 -> 3.1.8 regression] intel ibexpeak hdmi no sound out

> To be clear, are you saying "git bisect" told you that 76531d4166 was > the first bad commit? Not exactly. I told you I got confused on how to use git-bisect, so I didn't use it (I didn't understand how is it supposed to check each commit, when another kernel is running). I simply used your firs

Bug#660111: [3.0 -> 3.1.8 regression] intel ibexpeak hdmi no sound out

Andres Cimmarusti wrote: > I found the patch that brings about the problem. It turns out it > happened quite early in the 3.1 kernel merge window. This the commit > that changes things: > > [...]76531d4166fb620375ff3c1ac24753265216d579 To be clear, are you saying "git bisect" told you that 76531d

Bug#660111: [3.0 -> 3.1.8 regression] intel ibexpeak hdmi no sound out

Thanks for the git crash course. I did not look at 'git-bisect' too much. It is more systematic, but how to test each commit confused me some. I found the patch that brings about the problem. It turns out it happened quite early in the 3.1 kernel merge window. This the commit that changes things:

Bug#660111: [3.0 -> 3.1.8 regression] intel ibexpeak hdmi no sound out

Andres Cimmarusti wrote: > How did you get that number you gave me before to use with git? > basically I'm asking how do I get it for this patch ? I'm going to > simply download the snapshot and try it for now. There are other > suspicious patches submitted around the same time. I shall try them a

Bug#660111: [3.0 -> 3.1.8 regression] intel ibexpeak hdmi no sound out

> Perhaps v3.1-rc2~4^2~47^2~89 (ALSA: hda: HDMI: Support codecs with > fewer cvts than pins, 2011-07-01) is the problematic patch.  Can you > check this guess, like so? That patch that you mention is included in the 3.0.x kernels as the matter of fact. Thus I don't think it would have caused the p

Bug#660111: [3.0 -> 3.1.8 regression] intel ibexpeak hdmi no sound out

Andres Cimmarusti wrote: > I installed two kernels from snapshots. Using date 2012-02-01 I was > able to pull in a 3.1.8 kernel that exhibited the same problem as > kernels 3.2.x. > I also used data 20111201 and pulled in a debian 3.0.x kernel. This > one didn't have the problem (as in the case of

Bug#660111: [3.0 -> 3.2.4 regression] intel ibexpeak hdmi no sound out

retitle 660111 [3.0 to 3.1 regression] HDMI 3 devices instead of 1 quit > Can you narrow down the regression range by a bisection search > through kernels at to find the first > broken one? I installed two kernels from snapshots. Using date 2012-02-01 I was able to p

Bug#660111:

retitle 660111 ALC269VB HDMI 3 devices detected instead of 1 quit -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#660111: [3.0 -> 3.2.4 regression] intel ibexpeak hdmi no sound out

Hi Andres, Andres Cimmarusti wrote: > Should a bug report be filed against pulseaudio for lacking the > capability to handle several HDMI outputs? Maybe, but I don't think this particular case warrants that. If I understand correctly you have only one HDMI output, and a kernel regression is cau

Bug#660111: more info

retitle 660111 [linux-image-3.2] ALC269VB HDMI single physical port -> multiple devices detected quit After some online searching for this card's codec alc269vb I found several reports (some very old...) of the problem in Arch Linux: https://bbs.archlinux.org/viewtopic.php?id=133222 They point t