[00:00] <bryce> in any case, treating the bug as a driver-specific bug is more likely to be acted on upstream, than if it's left a generic xserver bug
[00:00] <bryce> see my comment on the bug report
[00:01] <Awsoonn> the OP has 5 machines though.
[00:01] <Awsoonn> xx
[00:01] <bryce> right, but since he included only one log, and no screenshots, he's not proven it's the same bug on each system
[00:01] <bryce> his report is vague
[00:02] <bryce> like, is he using the same xorg.conf on all of them?
[00:02] <bryce> is he using the same brand of monitor?  (in which case it could be a monitor bug)
[00:03] <bryce> he asserts, "The correct approach, to my understanding, is to hold all updates until the screen has finished its refresh cycle." but without a reference or detailed explanation that sounds speculative
[00:04] <Awsoonn> rock on, so on some computers, there is no tearing then?
[00:07] <bryce> well, maybe I'm misunderstanding the problem, but generally with a fast video card you don't notice things like that
[00:07] <bryce> (not to the degree that it'd show up in a screenshot anyhow)
[00:08] <bryce> if the complaint is simply the repainting algorithm that X uses... well that's probably more for a discussion upstream than a bug report against ubuntu
[00:11] <Awsoonn> is there a way that I might prove this in a driver issue? I want to tell x not to use the nvidia driver
[00:12] <bryce> sure, switch to "nv" in xorg.conf, or "vesa", and try reproducing it
[00:12] <bryce> or if you're using "nv", try the -nvidia binary driver
[00:12] <Awsoonn> I tried on another system with an older Gforce2 and got the same 'error' screenshot.
[00:12] <Awsoonn> will do
[00:12] <Awsoonn> I'll be back :) 
[00:33] <Awsoonn> bryce, something decently interesting happened, the screenshot shows tearing even with Vesa
[00:35] <Awsoonn> what else can I try to further pinpoint the bug? would you like my xorg.conf? 
[00:37] <Awsoonn> I also have an x700 ati card that could be tested as well if need be.
[00:37] <Awsoonn> I hope this isn't too bothersome, I am enjoying learning more about X. ^_^
[00:53] <bryce> Awsoonn: not sure, perhaps ask on the xorg-devel@ list?
[01:05] <bryce> Awsoonn: maybe one thing that would help would be to write up the description of the problem more specifically.
[01:05] <bryce> like, list out the exact steps to reproduce it
[02:14] <bryce> tjaalton: is vesa supposed to support xrandr 1.2 calls?
[06:30] <tjaalton> bryce: not sure but don't think so
[06:36] <bryce> tjaalton: I traced through the code on the -vesa gdk bug more today.  It's failing during an init_xrandr12 call
[06:37] <bryce> or, rather, the invalid data is entering during an init_randr12() call...  it crashes a little later on when it tries to dereference a pointer generated due to the invalid data
[06:38] <bryce> it's a bit perplexing how little return value checking there is in gdk amongst its x11 wrapper calls
[06:38] <bryce> anyway, I forwarded the bug with as much research as I'd done, up to debian.  deb #455884
[06:39] <bryce> no that's not right
[06:39] <bryce> Bug#490258
[06:43] <tjaalton> it will end up upstream..
[06:47] <tjaalton> but who knows
[06:48] <bryce> sure that's fine.  I almost sent it up to xorg myself but I'm not 100% sure it is X, vs. just gdk
[06:50] <tjaalton> debian doesn't have xserver 1.5 etc available yet, but other distros do. there doesn't seem to be a bug about it upstream yet
[06:54] <tjaalton> could be interesting to see if 1.3.0 patched to build has these problems
[09:13] <jcristau> the init_randr12 stuff was added in gtk 2.13
[09:17] <tjaalton> ah ok :)
[09:17] <jcristau> would be interesting to know exactly what XRRGetScreenResources() returns
[09:21] <jcristau> this is probably not a bug in the driver, fwiw
[10:01] <bryce> jcristau: here's the rep I was getting back:
[10:01] <bryce> (gdb) info locals
[10:01] <bryce> info = <value optimized out>
[10:01] <bryce> rep = {type = 1 '\001', status = 160 '�', sequenceNumber = 12, length = 8, timestamp = 2229926, crtc = 0, mmWidth = 0, 
[10:01] <bryce>   mmHeight = 0, connection = 0 '\0', subpixelOrder = 5 '\005', nCrtcs = 1, nModes = 4, nPreferred = 0, nClones = 0, 
[10:01] <bryce>   nameLength = 7}
[10:01] <bryce> nbytes = 28
[10:01] <bryce> nbytesRead = 28
[10:01] <bryce> xoi = <value optimized out>
[10:25] <jcristau> is the crash reproducible with Xephyr?
[11:01] <jcristau> i get sensible stuff from libXrandr on xephyr. guess i'll have to try with vesa. or find the bug in gtk.
[11:47] <Ng> how well would we expect to work on a Radeon HD3200?
[11:47] <Ng> (also called 780G in some circles, I'm told)
[11:48] <Ng> someone just installed on a machine with such a card and other than VESA, is either getting crashes or entire X failures depending on which driver they go with
[11:57] <tjaalton> Ng: hardy?
[12:17] <Ng> yeah
[12:22] <tjaalton> tormod has a backport of the -ati driver, maybe try that
[12:23] <Ng> ok, ta
[12:50] <joumetal> What could be done to bug 246557?
[12:50] <ubottu> Launchpad bug 246557 in meta-kde4 "ati 9200SE, DVI, vesa, KDE4 crashes on login" [Undecided,New] https://launchpad.net/bugs/246557
=== jcristau_ is now known as jcristau
[16:54] <jcristau> bryce: confirmed the bug, reassigned to the server
[17:30] <bryce> jcristau: thanks
[19:51] <jcristau> bryce: filed the bug upstream, https://bugs.freedesktop.org/show_bug.cgi?id=16674
[19:51] <ubottu> Freedesktop bug 16674 in Server/general "[regression] RRScanOldConfig fails to associate output and crtc" [Normal,New] 
[19:52] <bryce> jcristau: excellent, thanks