Bug 30067

Ok, that is scary the amplifier gives 3 display modes but claims no audio support. So that explains why it interferes with the output configuration on the laptop, but I'm left in a quandary as how to automatically detect an amp vs a display.

I think the answer will have to be some form of manual configuration. I'm going to have to read the audio specs to see if they have any guidance.

That is indeed scary :S

The exact amplifier model is Sony STR-DH510. The amplifier does allow connecting a display to its HDMI out connector, but I haven't got anything connected to it. (I also do not have anything I can connect to it.)
I would expect it would need to pass through the display information of the connected display when one is connected, so it surprises me it would already provide such information when nothing is connected.

Zhenyu mentioned he had a patch to add a force-audio property.

Maybe I could try the patch? Is there a reason audio isn't always forced out? I don't think this would cause any issues, since a user always needs to manually specify HDMI as the output device. The fact that it doesn't "just work" after that has been confusing in the past for people (I saw that on support sites).

Btw. with the amplifier connected, X.org starts up with 640x480 on the notebook screen (instead of 1280x800).

Could you try my branch at http://cgit.freedesktop.org/~zhen/drm-intel/log/?h=for-ickle-next?

It trys to detect device's audio capability through EDID, and added a 'force_audio' i915 param. So you can test by force it on/off.

If we always turn audio on, I know there has been problem with some monitors but I don't know the bug number. And you can force mode on your panel, amplifier normally doesn't return meaningful video modes.

Should the force_audio parameter appear for the i915 module?

I built the module in your GIT tree and overwrote the module from my kernel. modinfo does show the newer version, but it does not show the force_audio parameter. Should I indeed look at drivers/gpu/drm/i915/i915.ko or is the force_audio parameter in another module?

It's a param for i915 module, so 'i915.force_audio=1' should work.

Just a bit more background on the other issue, that of not being able to send an audio signal along HDMI without a display connection. It turns out that the audio signal is actually encoded within the vblank intervals (i.e. the surplus pixels that are not normally displayed) and so audio-over-HDMI requires a valid modeline (and it doesn't just seem to be simply due to the way our hardware is put together).

It seems I didn't have the right source tree at first. Getting the tar & compiling the module from there, gave me a version with the force_audio option.

I then created a file /etc/modprobe.d/i915.conf with
options i915 force_audio=1

Then after a reboot, I still had the issue that I needed to enable the HDMI output through xrandr to get audio output (and X.org started with 640x480).
Maybe I need to set the parameter in another way?

If some kind of display signal is needed, I wonder whether it would be a problem for the hardware to send a "dummy" signal without X.org being aware of that?


Another note, I saw in the manual there were multiple options configuring the HDMI settings. (Page 64 of: http://www.docs.sony.com/reflib/docget.asp?manualid=1073485&template_id=1&region_id=1&DL=',600,560,10,10 )
I'm not sure what the best settings would be in this case. Are there general recommendations for HDMI connected devices?

The manual also speaks of a control interface over HDMI. Maybe this also allows for some kind of detection of the amplifier? Maybe it would also allow controlling the amplifier volume from the Intel hardware or it would allow the hardware to receive info from the amplifier? The remote control that comes with the amplifier has loads of unused buttons (like play, pauze, stop, etc.). It seems (HDMI) devices like DVD players are supposed to pick those up.

Jesse is already fighting some nice ELD fallout on gm45 and other chips, reassigning to him.

Paulo Zanoni fixed up our hdmi infoframe support. Please retest with the drm-intel-next-queued branch from http://cgit.freedesktop.org/~danvet/drm-intel/

I'm running the mentioned kernel now. As far as I can see, not much is changed.

When I turn on my notebook and it displays the log-on screen, it uses some low resolution instead of the one of my notebook screen. I use KDE4 now which does correctly switch to 1280x800 after log-in and after exiting a fullscreen application.

When switching resolutions, the audio is interrupted. The audio being played back is not related to the application being switched, it's really the HDMI stream that is being interrupted.

And still the audio is dependent on the display device. I need to enable the phantom display to be able to hear audio. Due to this phantom display, I can also disable my notebook screen and end up without a working screen. I don't know if it's possible to get rid fully of this phantom display, I understand it's a problem with my amp, but I should at least be able to have audio without having to enable a display in X.org.

Is there any more information I could provide?

Created attachment 61530 [details]
xrandr --verbose

It seems that the EDID shown by xrandr --verbose is longer now than what was in the original attached Xorg.0.log. Here is the output with the longer EDID.

Created attachment 61531 [details]
Newer Xorg.0.log

Here is also the new Xorg.0.log. It seems it picks 800x600 as the default resolution. It should pick 1280x800 instead.

(In reply to comment #14)
> Here is also the new Xorg.0.log. It seems it picks 800x600 as the default
> resolution. It should pick 1280x800 instead.

Selecting 800x600 makes some sense because that's the only mode that works both on the HDMI output and the LVDS screen. I guess your amp just announces a bunch of default HDMI modes so that when you plug in a TV Things Just Work. Latest drm-next has a few patches though to automatically add some more modes (1280x800 included), so in 3.5 that problem should be fixed.

The problem with being forced to use a dummy display is unfixeable afaics - as Chris said hdmi audio is transferred in the vblank period, so when you don't have the display switched on you can't transfer audio. For similar reasons audio will stop when you change the output configuration.

To check: Does audio now work when you just enable the phantom display? I.e. is no other module/boot/whatever option required?

It seems that HDMI is still quite limited then as a standard :(
I indeed wonder what would happen when I connect a display to my amp. Unfortunately I do not have anything here to test, I would expect both devices to be detected separately...

Could the driver maybe send some dummy video data in the case only audio data is presented to the HDMI port? Right now, ALSA seems to think everything is alright in this case, but the sound is just mute in practice.

With the phantom display enabled, audio works. That was always the case. I'm not aware of and modules or module options that could alter the behavior.

I've looked through the hdmi specs again and we really need to have a valid video mode to be able to send audio. So that seems unfixable. The other thing is that for repeaters that forward only audio or video (like your amp likely does) the spec also says that when you plug in something on the other side, the repeater has to lower the HPD pin to signal a change in the device configuration. So audio interrupts seem to be a given. And I haven't found any way a hdmi sink could specify that it wants audio only - there are only flags to indicate that it supports audio.

In conclusion, I only see the problem of X picking a very-low default mode (to make clone possible) left, but that should be remedied in 3.5 (at least as much as we can fix that). And changing the resolution to what you want already works, so anything above and beyond what 3.5 can do is a policy problem in the userspace code.

Everything else seems to be unfixable because that's how the hw works, so I'll close this as notabug. Thanks anyway for reporting it.