On Tue, Oct 22, 2013 at 03:24:18PM +0200, Thomas Richter wrote: > Am 22.10.2013 14:03, schrieb Chris Wilson: > >Ah, /var/log/Xorg.0.log has greater verbosity than stdout/stderr. I am > >just curious where we reject the -intel driver and hence fail to init > >the screen. > > /var/logXorg.0.log is zero bytes long at this point. I wouldn't call > this "greater". (-; > Let it be as it is, I wouldn't consider this an acceptable reaction. > >>later when X is running, I do get a working X, but no picture on the > >>external monitor. The xrandr output is also attached. > >> From the xrandr, I can see the problem. LVDS1 can be on either CRTC, but > >VGA can only be on CRTC-0. At initialisation, LVDS1 is on CRTC-0 and so > >prevents the VGA from finding a CRTC. > > > >If you do: > >xrandr --output LVDS1 --off > >xrandr --output VGA1 --preferred > >xrandr --output LVDS1 --preferred > > > >it should work, or more compactly: > > > >xrandr \ > > --output VGA1 --preferred --crtc 0 \ > > --output LVDS1 --preferred --crtc 1 --primary --left-of VGA1 > > > >(adjust primary and position to taste) > > Sorry, not really. After a "xrandr --output LVDS1 --panning > 2048x1536" on the internal screen, I did a > > $ xrandr --output LVDS1 --off && xrandr --output VGA1 --preferred && > xrandr --output LVDS1 --preferred > > and the result was only: > > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 149 (RANDR) > Minor opcode of failed request: 29 (RRSetPanning) > Serial number of failed request: 26 > Current serial number in output stream: 26 If I understand the symptoms right, that should be fixed if you use SNA instead of UXA. Basically it thinks the intermediate stage exceeds the hardware limits. > So apparently, xrandr had problems carrying the panning parameters > over. Then, following that, I did a > > $ xrandr --output LVDS1 --preferred > $ xrandr --output VGA1 --preferred > > The result is a working LVDS display, but a nonworking external > display (non-stable, as if the sync is incorrect, but a signal). I'm > attaching the output of xrandr --verbose in this specific state. > > Then I did a > > $ xrandr --output VGA1 --off > $ xrandr --output VGA1 --auto > > and then I got a stable and working external display. > > Anyhow, something's screwed in the display setup. a) xrandr should > carry over the panning parameters just correctly instead of failing > and, b) > it should better get the sync timing right the first time, and not > the second. (Or actually third). That's a kernel bug, somewhere. > The "flicker on panning" remains here, but only on the external but > not on the internal. > > > > >Flickering is another problem altogether (who votes for DSPARB?). > >-Chris > > > Likely so... But there is at least still a problem with getting the > timing right on the external display. But at least we are reducing it down to known bugs! -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
