On 12/20/2010 04:00 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
* xorg-server 1.9.3 which includes RandR and a ton of stability fixes
Having connected two monitors (unequal sized) side-by-side (to a NVidia 8800-GT card in a MacPro) there are problems due to RandR, is there any method to disable this extension on X11-server startup? In this dual-head configuration 'xrandr -q' reports Screen 0: minimum 4480x1578, current 4480x1600, maximum 4480x1600 default connected 4480x1600+0+0 0mm x 0mm 4480x1578 1.0 4480x1600 2.0* which looks wrong at first sight (listing only ... the whole screen). In fact all of XDisplayWidth() / XDisplayHeight() XineramaQueryScreens() and XRRGetCrtcInfo() return occasionally conflicting panel- and full-screen geometry data. Though, it seems the above first two are consistent after a fresh X-server startup (as long as one doesn't fiddle with 'xrandr', or try rotating panels by "System Preferences -> Monitors"). Having upgraded to 2.6.0 today besides the attached crash report I don't have yet any particular diagnostic data, so keeping watching for now... :-) Greetings, Eeri Kask
On Dec 21, 2010, at 11:23, Eeri Kask wrote:
On 12/20/2010 04:00 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
* xorg-server 1.9.3 which includes RandR and a ton of stability fixes
Having connected two monitors (unequal sized) side-by-side (to a NVidia 8800-GT card in a MacPro) there are problems due to RandR, is there any method to disable this extension on X11-server startup?
In this dual-head configuration 'xrandr -q' reports
Screen 0: minimum 4480x1578, current 4480x1600, maximum 4480x1600 default connected 4480x1600+0+0 0mm x 0mm 4480x1578 1.0 4480x1600 2.0*
which looks wrong at first sight (listing only ... the whole screen).
Right. As discussed on this list over the past few months, the multi-monitor support is currently just supporting the two legacy modes (rootless and "fullscreen").
In fact all of
XDisplayWidth() / XDisplayHeight()
XineramaQueryScreens()
and
XRRGetCrtcInfo()
return occasionally conflicting panel- and full-screen geometry data.
Really? Can you provide me with a test case (and open a bug report for it)? This sounds like something for 2.6.1.
Though, it seems the above first two are consistent after a fresh X-server startup (as long as one doesn't fiddle with 'xrandr', or try rotating panels by "System Preferences -> Monitors").
Changes in System Preferences should be properly detected. If anything is broken wrt those changes, I'd suspect they were broken before RandR as well. Can you confirm if what you are seeing actually is a regression?
Having upgraded to 2.6.0 today besides the attached crash report I don't have yet any particular diagnostic data, so keeping watching for now... :-)
Weird. That crash is in handling a ProcCreateGlyphCursor. I haven't seen that before, but DRIPolyFillRect makes me curious. Are you able to reproduce this (and please file a bug report)? 11 X11.bin 0x0000000100034b1e fbFill + 342 12 X11.bin 0x000000010003519f fbPolyFillRect + 244 13 X11.bin 0x00000001000153f0 DRIPolyFillRect + 129 14 X11.bin 0x000000010007a2fd damagePolyFillRect + 548 15 X11.bin 0x00000001000d249e ServerBitsFromGlyph + 313 16 X11.bin 0x00000001000b93cc AllocGlyphCursor + 438 17 X11.bin 0x00000001000c206a ProcCreateGlyphCursor + 155
participants (2)
-
Eeri Kask
-
Jeremy Huddleston