| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| Awsoonn | rock on, so on some computers, there is no tearing then? | 00:04 |
| 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:07 |
| 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:08 |
| 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:11 |
| 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:12 |
| Awsoonn | bryce, something decently interesting happened, the screenshot shows tearing even with Vesa | 00:33 |
| Awsoonn | what else can I try to further pinpoint the bug? would you like my xorg.conf? | 00:35 |
| 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:37 |
| bryce | Awsoonn: not sure, perhaps ask on the xorg-devel@ list? | 00:53 |
| 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 | 01:05 |
| bryce | tjaalton: is vesa supposed to support xrandr 1.2 calls? | 02:14 |
| tjaalton | bryce: not sure but don't think so | 06:30 |
| bryce | tjaalton: I traced through the code on the -vesa gdk bug more today. It's failing during an init_xrandr12 call | 06:36 |
| 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:37 |
| 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:38 |
| bryce | no that's not right | 06:39 |
| bryce | Bug#490258 | 06:39 |
| tjaalton | it will end up upstream.. | 06:43 |
| tjaalton | but who knows | 06:47 |
| 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:48 |
| 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:50 |
| tjaalton | could be interesting to see if 1.3.0 patched to build has these problems | 06:54 |
| jcristau | the init_randr12 stuff was added in gtk 2.13 | 09:13 |
| tjaalton | ah ok :) | 09:17 |
| jcristau | would be interesting to know exactly what XRRGetScreenResources() returns | 09:17 |
| jcristau | this is probably not a bug in the driver, fwiw | 09:21 |
| 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:01 |
| jcristau | is the crash reproducible with Xephyr? | 10:25 |
| jcristau | i get sensible stuff from libXrandr on xephyr. guess i'll have to try with vesa. or find the bug in gtk. | 11:01 |
| 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:47 |
| 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:48 |
| tjaalton | Ng: hardy? | 11:57 |
| Ng | yeah | 12:17 |
| tjaalton | tormod has a backport of the -ati driver, maybe try that | 12:22 |
| Ng | ok, ta | 12:23 |
| 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 | 12:50 |
| === jcristau_ is now known as jcristau | ||
| jcristau | bryce: confirmed the bug, reassigned to the server | 16:54 |
| bryce | jcristau: thanks | 17:30 |
| 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:51 |
| bryce | jcristau: excellent, thanks | 19:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!