I'm running a 3 monitor setup with a Radeon HD graphics card [Radeon HD 6000 Series]. I'm not using the proprietary drivers. Connectors are: 2 DVI and 1 HDMI. When I change the second DVI connection from a monitor to a projector and try to set the correct resolution (1920x1080) it fails with the following error message: [15189.014994] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL [15189.015008] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:12] It changes the resolution but there are black areas at the sides and at the bottom of the displayed picture. It only happens if I connect the projector, not when the usual monitor is connected. This problem does not exist with kernel version 3.6.11. $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux semkath-desktop 3.8.0 #1 SMP PREEMPT Wed Feb 20 18:31:08 CET 2013 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux Gnu C 4.7.2 Gnu make 3.82 binutils 2.23.1 util-linux 2.22.2 mount debug module-init-tools 12 e2fsprogs 1.42.6 Linux C Library 2.16 Dynamic linker (ldd) 2.16 Procps UNKNOWN Net-tools 1.60_p20120127084908 Kbd 1.15.5 Sh-utils 8.21 Modules Loaded snd_aloop kvm_amd firewire_ohci k10temp i2c_piix4 firewire_core
This is a hardware limitation. The hardware only has 2 PLLs for non-DisplayPort monitors. As such, the driver only supports 2 independent pixel clocks on non-DisplayPort monitors. If you have more than 2 non-DP monitors, it will only work if several of them share the same pixel clock (i.e., the monitors sharing a PLL have to display the same mode with the same pixel clock). Older kernels did not properly warn about exceeding these limitations.
That explains why the 3 monitor setup works, but 2 monitors plus a projector don't: two of the monitors are the same. Interestingly enough, it works completely fine for any kernel < 3.7.0. I have been using this setup since at least a year or so and never had any problems with 3 different display units (until 3.7.0). Considering what you said that confuses me, since it shouldn't have worked as problem-free as it did, should it?
(In reply to comment #2) > That explains why the 3 monitor setup works, but 2 monitors plus a projector > don't: two of the monitors are the same. Interestingly enough, it works > completely fine for any kernel < 3.7.0. I have been using this setup since at > least a year or so and never had any problems with 3 different display units > (until 3.7.0). Considering what you said that confuses me, since it shouldn't > have worked as problem-free as it did, should it? It probably worked by accident previously. Presumably the pixel clocks on the two monitors that were sharing a PLL were close enough that the monitors were ok with it. What modes are you running on the two monitors and projector?
As per xrandr (projector NOT connected): DVI-0: 1280x1024 60.0*+ DVI-1: 1920x1200 60.0*+ HDMI-0: 1920x1200 60.0*+ The output DVI-1 with the projector connected: 1920x1080 60.0*+ Worked fine until 3.7.0.
(In reply to comment #4) > As per xrandr (projector NOT connected): > DVI-0: 1280x1024 60.0*+ > DVI-1: 1920x1200 60.0*+ > HDMI-0: 1920x1200 60.0*+ > > The output DVI-1 with the projector connected: > 1920x1080 60.0*+ > > Worked fine until 3.7.0. Can you dump the full modelines with pixel clocks (xrandr --verbose)? I suspect the pixel clocks for 1920x1200 and 1920x1080 modes are close enough that one of the monitors was able to tolerate a slightly incorrect pixel clock. Some monitors are more tolerant than others. Projectors tend to be since they usually support a wide range of signals from various inputs.
Projector connected at DVI-1. Usually connected to DVI-1 is a monitor identical to the one connected at HDMI-0. DVI-0: 1280x1024 (0x59) 108.0MHz +HSync +VSync *current +preferred h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz HDMI-0: 1920x1200 (0x70) 154.0MHz +HSync -VSync *current +preferred h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 74.0KHz v: height 1200 start 1203 end 1209 total 1235 clock 60.0Hz DVI-1: 1920x1080 (0x72) 148.5MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz
1920x1200 (0x70) 154.0MHz 1920x1080 (0x72) 148.5MHz These two pixel clocks are close enough that your monitors seem to be able to deal with the slight difference. Unfortunately, not all monitors are so forgiving and and it wouldn't work if you picked a mode with a substantially different pixel clock. You just happened to get lucky.
I seem to have the exact same problem. :( I've been using 12.04, and earlier, in a 3 monitor setup for ages now, and I'm really disappointed that it's stopped working with 13.04. The clock description does ring true though because every now and again one of my monitors would say "Signal out of range", and I would shrug my shoulders, cycle it through the input settings, and it would work again. Is there any way to hack the driver to get back the near-enough solution? It's a bit dirty, but I'm not sure I want to shell out £250 to fix the problem the clean way. Where would I look? Can you point me at the patch that "broke" it, perhaps?
Alternatively, would switching a monitor from DVI to VGA or HDMI help? I currently have two DVI monitors, listed as "DisplayPort-1" and "DisplayPort-2", and one laptop display, listed as "LVDS". No two monitors have the same native resolution. xrandr --query suggests that "DisplayPort-0" and "VGA-0" are unused. I presume that maps to the HDMI and VGA ports?
Sounds like your oem has a rather strange setup. Please attach your dmesg output.
It's a Dell Precision M4600 sitting in the docking station. Apologies for the random Ubuntu version numbers. Not appropriate here. Unfortunately I don't actually know what kernel version I had before the upgrade. I've now tried a VGA cable. The good news is that nothing crashes, spits error messages, or otherwise goes unstable. The bad news is that the widescreen monitor stretches the picture and loses the right edge of the picture. This happens whichever way around I hook them up; the picture is wrong in a different way with DVI vs. VGA, but both are wrong. I don't have a HDMI cable handy to try. Anyway, I'll attach the dmesg data for you.
Created attachment 106911 [details] dmesg data from ams
The "problem" code appears to be in drivers/gpu/drm/radeon/atombios_crtc.c:radeon_get_shared_nondp_ppll or possibly radeon_get_shared_dp_ppll. I've tried making the clock matching code slightly more permissive, but no luck yet. I'm going to try a few more experiments.
More observations: About 1 time in 3 boots the driver will fail to allocate PPLLs at all, and Ubuntu 13.10 will not start lightdm login screen. Having failed, I tend to get a run of failures, but two or three reboots is usually sufficient to get a working setup once more. There just seems to be a random factor in there somewhere. Please note: in these instances I have one monitor configured to run in a reduced resolution, so clock matching should not be a problem. I suppose it might be less problematic were I running all three screens at their preferred, default resolution.
I fixed the problem now! (At least, for my own needs.) The patch turns out to be very simple. 1. Disregard the mode setting (why does the PPLL care?) 2. Allow a little leeway in the frequency matching. I've allowed 10%, but another figure might be better. I'll attach the patch in a moment. I'm not sure it's suitable for upstream without being configurable though?
Created attachment 108951 [details] Proposed patch
Created attachment 141471 [details] Proposed patch This updated patch uses integer-only arithmetic. Apparently, that's necessary in 3.15, at least on Arch.