Bug 16674 - [regression] RRScanOldConfig fails to associate output and crtc
Summary: [regression] RRScanOldConfig fails to associate output and crtc
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: xorg-7.4
  Show dependency treegraph
 
Reported: 2008-07-11 11:48 UTC by Julien Cristau
Modified: 2008-07-15 07:43 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
patch suggested by ajax (431 bytes, patch)
2008-07-14 13:42 UTC, Julien Cristau
no flags Details | Splinter Review
(unpatched) xorg log, for reference (44.85 KB, text/plain)
2008-07-14 13:45 UTC, Julien Cristau
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Cristau 2008-07-11 11:48:39 UTC
Using the vesa driver, the first call to a randr function calls RRScanOldConfig which is supposed to allocate a crtc and an output and hook them together.
This doesn't work on 1.5 rc5, because we end up with a NULL newMode so RRCrtcNotify is never called.
Reverting b4193a2eee80895c5641e77488df0e72a73a3d99 fixes this.

This makes gtk apps crash with gtk 2.13, which calls randr functions on startup and assumes that at least one output has an associated crtc.
Comment 1 Bryce Harrington 2008-07-11 11:54:08 UTC
This issue has cropped up in Ubuntu; bug report is here:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vesa/+bug/246585
Comment 2 Julien Cristau 2008-07-13 04:05:05 UTC
On Fri, Jul 11, 2008 at 11:48:40 -0700, bugzilla-daemon@freedesktop.org wrote:

> Reverting b4193a2eee80895c5641e77488df0e72a73a3d99 fixes this.

Actually that's wrong.  This fixes output->crtc, but the crtc structure
still doesn't get properly set up.
It seems that newMode doesn't get set in RRScanOldConfig() because
pScrPriv->rate is messed up.  What are pScrPriv->rate and pScrPriv->size
supposed to be?

Some more info from gdb (with the revert, but the only thing that
changes is that pScrPriv->outputs[0]->crtc isn't NULL):

(gdb) p *pScrPriv
$2 = {rrSetConfig = 0x80f6499 <xf86RandRSetConfig>, 
  rrGetInfo = 0x80f5eb9 <xf86RandRGetInfo>, rrScreenSetSize = 0, 
  rrCrtcSet = 0, rrCrtcSetGamma = 0, rrOutputSetProperty = 0, 
  rrOutputValidateMode = 0, rrModeDestroy = 0, lastSetTime = {months = 0, 
    milliseconds = 61560251}, lastConfigTime = {months = 0, 
    milliseconds = 61560251}, CloseScreen = 0x80d89b0 <DPMSClose>, 
  changed = 0, configChanged = 0, layoutChanged = 0, minWidth = 1024, 
  minHeight = 768, maxWidth = 1024, maxHeight = 768, width = 1024, 
  height = 768, mmWidth = 302, mmHeight = 232, numOutputs = 0, outputs = 0x0, 
  numCrtcs = 0, crtcs = 0x0, pointerCrtc = 0x0, rotations = 1, 
  reqWidth = 1024, reqHeight = 768, nSizes = 1, pSizes = 0x87c4e88, 
  rotation = 1, rate = -2147483648, size = 0}
(gdb) p pScrPriv->pSizes[0]
$24 = {id = 0, width = 1024, height = 768, mmWidth = 302, mmHeight = 232, 
  nRates = 1, pRates = 0x878e2d8}
(gdb) p pScrPriv->pSizes[0]->pRates[0]
$26 = {rate = 0, mode = 0x87ba058}
(gdb) p *pScrPriv->crtcs[0]
$34 = {id = 96, pScreen = 0x8679cc8, mode = 0x0, x = 0, y = 0, rotation = 1,
  rotations = 1, changed = 0, numOutputs = 0, outputs = 0x0, gammaSize = 0,
  gammaRed = 0x0, gammaBlue = 0x0, gammaGreen = 0x0, devPrivate = 0x0}
(gdb) p *pScrPriv->outputs[0]
$35 = {id = 97, pScreen = 0x8679cc8, name = 0x878e94c "default", 
  nameLength = 7, connection = 0 '\0', subpixelOrder = 1 '\001', mmWidth = 0, 
  mmHeight = 0, crtc = 0x87c7458, numCrtcs = 1, crtcs = 0x878ebe0, 
  numClones = 0, clones = 0x0, numModes = 1, numPreferred = 0, 
  modes = 0x878e350, numUserModes = 0, userModes = 0x0, changed = 0, 
  properties = 0x0, pendingProperties = 0, devPrivate = 0x0}

Hope this helps,
Julien
Comment 3 Julien Cristau 2008-07-14 12:32:40 UTC
> --- Comment #2 from Julien Cristau <jcristau@debian.org>  2008-07-13 04:05:05 PST ---
> (gdb) p *pScrPriv
> $2 = {rrSetConfig = 0x80f6499 <xf86RandRSetConfig>, 
>   rrGetInfo = 0x80f5eb9 <xf86RandRGetInfo>, rrScreenSetSize = 0, 
>   rrCrtcSet = 0, rrCrtcSetGamma = 0, rrOutputSetProperty = 0, 
>   rrOutputValidateMode = 0, rrModeDestroy = 0, lastSetTime = {months = 0, 
>     milliseconds = 61560251}, lastConfigTime = {months = 0, 
>     milliseconds = 61560251}, CloseScreen = 0x80d89b0 <DPMSClose>, 
>   changed = 0, configChanged = 0, layoutChanged = 0, minWidth = 1024, 
>   minHeight = 768, maxWidth = 1024, maxHeight = 768, width = 1024, 
>   height = 768, mmWidth = 302, mmHeight = 232, numOutputs = 0, outputs = 0x0, 
>   numCrtcs = 0, crtcs = 0x0, pointerCrtc = 0x0, rotations = 1, 
>   reqWidth = 1024, reqHeight = 768, nSizes = 1, pSizes = 0x87c4e88, 
>   rotation = 1, rate = -2147483648, size = 0}

ok that rate seems messed up, so maybe this is a bug in the ddx after
all?
It's set by RRSetCurrentConfig(), called from xf86RandRGetInfo(), so
here's some more info from gdb:

(gdb) frame
#1  0x080f6001 in xf86RandRGetInfo (pScreen=0x87eecd0, rotations=0xbfe5ad9a)
    at ../../../../hw/xfree86/common/xf86RandR.c:95
95	in ../../../../hw/xfree86/common/xf86RandR.c
(gdb) p mode
$4 = (DisplayModePtr) 0x87ee468
(gdb) p *mode
$5 = {prev = 0x87ee468, next = 0x87ee468, name = 0x87ee508 "1024x768", 
  status = MODE_OK, type = 33, Clock = 0, HDisplay = 1024, HSyncStart = 0, 
  HSyncEnd = 0, HTotal = 0, HSkew = 0, VDisplay = 768, VSyncStart = 0, 
  VSyncEnd = 0, VTotal = 0, VScan = 0, Flags = 0, ClockIndex = -1, 
  SynthClock = 0, CrtcHDisplay = 0, CrtcHBlankStart = 0, CrtcHSyncStart = 0, 
  CrtcHSyncEnd = 0, CrtcHBlankEnd = 0, CrtcHTotal = 0, CrtcHSkew = 0, 
  CrtcVDisplay = 0, CrtcVBlankStart = 0, CrtcVSyncStart = 0, CrtcVSyncEnd = 0, 
  CrtcVBlankEnd = 0, CrtcVTotal = 0, CrtcHAdjusted = 0, CrtcVAdjusted = 0, 
  PrivSize = 12, Private = 0x87ed028, PrivFlags = 0, HSync = 0, VRefresh = 0}
(gdb) p xf86RandRModeRefresh(mode)
$6 = -2147483648

methinks either xf86RandRModeRefresh should handle this mode, or the
mode shouldn't be there in the first place...

(gdb) p scrp
$7 = {driverVersion = 4000, driverName = 0xb7a1a920 "vesa", 
  pScreen = 0x87eecd0, scrnIndex = 0, configured = 1, origIndex = 0, 
  imageByteOrder = 0, bitmapScanlineUnit = 32, bitmapScanlinePad = 32, 
  bitmapBitOrder = 0, numFormats = 0, formats = {{depth = 0 '\0', 
      bitsPerPixel = 0 '\0', scanlinePad = 0 '\0'}, {depth = 0 '\0', 
      bitsPerPixel = 0 '\0', scanlinePad = 0 '\0'}, {depth = 0 '\0', 
      bitsPerPixel = 0 '\0', scanlinePad = 0 '\0'}, {depth = 0 '\0', 
      bitsPerPixel = 0 '\0', scanlinePad = 0 '\0'}, {depth = 0 '\0', 
      bitsPerPixel = 0 '\0', scanlinePad = 0 '\0'}, {depth = 0 '\0', 
      bitsPerPixel = 0 '\0', scanlinePad = 0 '\0'}, {depth = 0 '\0', 
      bitsPerPixel = 0 '\0', scanlinePad = 0 '\0'}, {depth = 0 '\0', 
      bitsPerPixel = 0 '\0', scanlinePad = 0 '\0'}}, fbFormat = {
    depth = 24 '\030', bitsPerPixel = 32 ' ', scanlinePad = 32 ' '}, 
  bitsPerPixel = 32, pixmap24 = Pix24DontCare, depth = 24, 
  depthFrom = X_DEFAULT, bitsPerPixelFrom = X_PROBED, weight = {red = 8, 
    green = 8, blue = 8}, mask = {red = 16711680, green = 65280, blue = 255}, 
  offset = {red = 16, green = 8, blue = 0}, rgbBits = 8, gamma = {red = 1, 
    green = 1, blue = 1}, defaultVisual = 4, maxHValue = 0, maxVValue = 0, 
  virtualX = 1024, virtualY = 768, xInc = 8, virtualFrom = X_PROBED, 
  displayWidth = 1024, frameX0 = 0, frameY0 = 0, frameX1 = 1023, 
  frameY1 = 767, zoomLocked = 0, modePool = 0x0, modes = 0x87ee468, 
  currentMode = 0x87ee468, confScreen = 0x87ca070, monitor = 0x87ca148, 
  display = 0x87ecd50, entityList = 0x87ea5a0, numEntities = 1, widthmm = 300, 
  heightmm = 230, xDpi = 86, yDpi = 84, name = 0xb7a1a925 "VESA", 
  driverPrivate = 0x87eae88, privates = 0x87eb048, drv = 0x87e9700, 
  module = 0x87ea5f0, colorKey = 0, overlayFlags = 0, 
  chipset = 0xb7a1a920 "vesa", ramdac = 0x0, clockchip = 0x0, progClock = 1, 
  numClocks = 0, clock = {0 <repeats 128 times>}, videoRam = 8060928, 
  biosBase = 0, memPhysBase = 3489660928, fbOffset = 0, domainIOBase = 0, 
  memClk = 0, textClockFreq = 0, flipPixels = 0, options = 0x0, chipID = 0, 
  chipRev = 0, racMemFlags = 0, racIoFlags = 0, access = 0x87ea620, 
  CurrentAccess = 0x8230630, resourceType = MEM_IO, busAccess = 0x0, 
  vtSema = 1, pixmapPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0}, 
  silkenMouse = 0, clockRanges = 0x0, adjustFlags = 0, reservedInt = {
    0 <repeats 16 times>}, entityInstanceList = 0x87e96c0, reservedPtr = {
    0x0 <repeats 15 times>}, 
  Probe = 0xb7a1a6a0 <xf86ConfigIsaEntity@plt+11680>, 
  PreInit = 0xb7a19e30 <xf86ConfigIsaEntity@plt+9520>, 
  ScreenInit = 0xb7a19400 <xf86ConfigIsaEntity@plt+6912>, 
  SwitchMode = 0x80e246b <CMapSwitchMode>, 
  AdjustFrame = 0xb7a18cf0 <xf86ConfigIsaEntity@plt+5104>, 
  EnterVT = 0x80e23d3 <CMapEnterVT>, 
  LeaveVT = 0xb7a18950 <xf86ConfigIsaEntity@plt+4176>, 
  FreeScreen = 0xb7a17f00 <xf86ConfigIsaEntity@plt+1536>, 
  ValidMode = 0xb7a18dc0 <xf86ConfigIsaEntity@plt+5312>, 
  EnableDisableFBAccess = 0xb7a17d40 <xf86ConfigIsaEntity@plt+1088>, 
  SetDGAMode = 0x80e250a <CMapSetDGAMode>, 
  ChangeGamma = 0x80e3775 <CMapChangeGamma>, 
  PointerMoved = 0x80d42dc <xf86PointerMoved>, PMEvent = 0, HandleMessage = 0, 
  DPMSSet = 0xb7a191f0 <xf86ConfigIsaEntity@plt+6384>, 
  LoadPalette = 0xb7a17d90 <xf86ConfigIsaEntity@plt+1168>, SetOverscan = 0, 
  DriverFunc = 0, reservedFuncs = {0 <repeats 11 times>}}
Comment 4 Julien Cristau 2008-07-14 13:42:18 UTC
Created attachment 17674 [details] [review]
patch suggested by ajax

ajax suggested the attached patch, which seems to have fixed the issue.
Comment 5 Julien Cristau 2008-07-14 13:45:50 UTC
Created attachment 17675 [details]
(unpatched) xorg log, for reference
Comment 6 Adam Jackson 2008-07-15 07:43:53 UTC
Looks good.  Applied, thanks!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.