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.
This issue has cropped up in Ubuntu; bug report is here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vesa/+bug/246585
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 #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>}}
Created attachment 17674 [details] [review] patch suggested by ajax ajax suggested the attached patch, which seems to have fixed the issue.
Created attachment 17675 [details] (unpatched) xorg log, for reference
Looks good. Applied, thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.