On Sun, Nov 03, 2013 at 05:55:37PM +0100, Thomas Richter wrote: > Hi Daniel, dear intel experts, > > again trying to get the old Fujitsu laptop to work. The problem with > the latest drm-nightly built is that > the system again locks up - if the bios is configured to show an > image only on the internal display and > nothing on the external VGA. If the bios is configured to "shared > video", booting works fine. > > This seems to be related to the problem that, apparently, the bios > seems to prefer to connect the internal > display to pipe B and not pipe A, and hence during bootstrap just > configuring the dpll for pipe A is not enough. > > That being said, the following modifications for ns2501 will fix this: > > struct ns2501_priv need to get a new field int pll_b. In > enable_dvo(), the setting for the dpll_b needs to be > saved, too, and installed, too: > I915_WRITE(_DPLL_A, 0xd0820000); > I915_WRITE(_DPLL_B, 0xd0820000); > > It is absolutely unnecessary to overwrite the DVOC register, this is > configured fine. In "restore_dvo()", the dpll_b > configuration needs to be restored as well. The DVOC register need > not to be touched. In fact, the current > enable_dvo() has a bug in so far as it saves the wrong register. > > However, what is more stunning is how this bug is triggered. > Actually, intel_display.c computes the dpll register > value correctly (as it seems), but __intel_set_mode() (around line > 9356) is a bit strange: > > First, it disables the crtcs, then sets the mode, and the enables > the crtcs. Unfortunately, this cannot work with > with the ns2501 since a disabled PLL will block any communication > with with the DVO. I tried to move the "enable" > call above the intel_crtc_mode_set(), but this did not work either. > I do not know enough about the inner workings > of intel_display.c to fix this properly, but the problem seems to be > exactly that: An incorrectly configured DPLL > disables the communication with the DVO, hence the need for the workaround. Have you tried my patch to reorder the dvo sequence a bit? That /should/ get all these things right: http://www.spinics.net/lists/intel-gfx/msg34349.html > Last, a question: All I can get with the current intel driver is a > "shared display" between the internal and external > display. Is there any way (through xrandr) to get two different > configurations such that the external monitor is > using one configuration feed through pipe A, and the internal > display is feed through pipe B with another configuration? --above/below should achieve that, presuming there's not a different bug somewhere that prevents this from working correctly. > And finally: As the internal display is only a 6 bit display, is > there a way to enable dithering on the 835GM to avoid the banding > artifacts? Iirc we always send 8bit data over the dvo bus, so any dithering should be done in the dvo encoder. The built-in lvds encoder on i855gm and later has it's own dithering settting, and otherwise I'm not aware of any that would apply to gen2 graphics. Also: If you're running sna, have you checked that you indeed run X at 32bit depth? The default since a while is 15 bits. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
