[12:35] <bryce_> brb; more xorg multihead testing to do
[12:46] <ubotu> New bug: #144603 in xserver-xorg-video-ati (main) "resolution stuck at 640x480 with radeon driver" [Undecided,New]  https://launchpad.net/bugs/144603
[12:54] <bryce_> ahaha, triple screen works
[12:55] <bryce_> buggy but works
[04:50] <bryce_> http://people.ubuntu.com/~bryce/triple-head/100_1153.JPG
[04:51] <bryce_> got triple head on ati sort of working
[04:51] <bryce_> got a lot of corruption bugs, and lock ups now and then, and other issues
[07:10] <ubotu> New bug: #144666 in xserver-xorg-video-ati (main) "Failure to start X on PowerPC Mac Mini G4, ATI Radeon 9200." [Undecided,New]  https://launchpad.net/bugs/144666
[07:51] <ubotu> New bug: #19711 in xorg-server (main) "[dri]  constant bus activity due to DMAing everything" [Wishlist,Confirmed]  https://launchpad.net/bugs/19711
[08:12] <rawler> is bug #19711 known upstream? even if it's no bug for Ubuntu ATM (working by design), it probably is a major blocker for laptop-users
[08:12] <ubotu> Launchpad bug 19711 in xorg-server "[dri]  constant bus activity due to DMAing everything" [Wishlist,Confirmed]  https://launchpad.net/bugs/19711
[10:16] <ubotu> New bug: #144694 in xserver-xorg-video-intel (main) "xorg with intel driver SIGSEGV, subsequent bulletproof X fails" [Undecided,New]  https://launchpad.net/bugs/144694
[11:01] <ubotu> New bug: #144640 in ubuntu "middle mouse button will not scroll (dup-of: 107876)" [Undecided,New]  https://launchpad.net/bugs/144640
[12:55] <ubotu> New bug: #144726 in xresprobe (main) "weird display during gutsy installation just after xresprobe" [Undecided,New]  https://launchpad.net/bugs/144726
[02:55] <ubotu> New bug: #144760 in xorg (main) "Login fails, X crashes[Gutsy daily-live 20070925, AMD64] " [Undecided,New]  https://launchpad.net/bugs/144760
[03:07] <ubotu> New bug: #144594 in xresprobe (main) "Alternative install gets nvidia resolution wrong" [Undecided,New]  https://launchpad.net/bugs/144594
[04:10] <ubotu> New bug: #144777 in xorg (main) "xinerama xserver crash" [Undecided,New]  https://launchpad.net/bugs/144777
[05:15] <ubotu> New bug: #144802 in vte (main) "random image pixmaps in background (dup-of: 120858)" [Undecided,Invalid]  https://launchpad.net/bugs/144802
[05:38] <bdmurray> The Radeon Xpress 200M should work with a Live CD right?
[05:54] <tepsipakki> I think compiz should be disabled on it?
[05:56] <tepsipakki> hmm, no
[05:58] <tepsipakki> sorry, it is.. rs480
[05:59] <tepsipakki> but only a subset of them
[06:03] <tepsipakki> mvo: the list of pciid's on the compiz-wrapper seems to be incomplete. Grepping Xpress from the pci.lst shows a couple more
[06:06] <tepsipakki> mvo: ..blacklisted Xpress 200 pci-id's that is :)
[06:09] <mvo> tepsipakki: we started wit the rv480 iirc, I'm not sure about the others and if those are problematic
[06:09] <mvo> too little test hardware and feedback :/
[06:10] <tepsipakki> mvo: true..
[07:26] <ubotu> New bug: #144865 in xserver-xorg-video-ati (main) "freeze when setting GARTSize to "64"" [Undecided,New]  https://launchpad.net/bugs/144865
[07:49] <bryce_> rawler: it looks like it was recently reopened by Jan Gyselinck.  It would definitely be good to look in the upstream bug trackers (debian and xorg) to see if it's known there
[07:49] <bryce_> rawler: if not, then it would be good to get lspci, logs, conf files, etc. from Jan, and then take it upstream
[08:15] <rawler> bryce_: seems to be some buzz going on about it both in the kernel and in Xorg..
[08:16] <bryce_> got a link?
[08:16] <bryce_> tepsipakki: any ideas on 127008?
[08:18] <rawler> bryce_: added them to the bug.. (bug#19711)
[08:18] <bryce_> rawler: excellent
[08:19] <rawler> :)
[08:19] <rawler> I'll let someone else figure THAT out.. :)
[08:19] <rawler> I'm pondering bug #139726 though.. 
[08:19] <ubotu> Launchpad bug 139726 in xorg "[Gutsy} GDM is missing menu items" [Undecided,New]  https://launchpad.net/bugs/139726
[08:20] <bryce_> yeah I've wondered on that one too
[08:20] <rawler> the problem as far as I understand, is X runs under a larger virtual resolution than physical resolution..
[08:21] <rawler> is it a good idea to simply ask the user to regenerate their xorg.conf using dexconf, and see if that solves the problem?
[08:21] <rawler> what is usually used by ubuntu to generate the xorg.conf?
[08:22] <bryce_> there is a postinst script in the xorg package which handles most of the configuration
[08:22] <rawler> ok, so it's no a bad guess that John have altered the default xorg (either himself, or some script) which caused this?
[08:22] <bryce_> it uses dexconf but I notice that when I manually run dexconf, I get a slightly different result than what I get from the fresh install
[08:22] <bryce_> e.g., sometimes the bus id's are incorrect
[08:23] <rawler> oh, I see..
[08:23] <bryce_> so generally I don't ask people to run dexconf; instead we typically have them rerun apt reconfigure
[08:23] <rawler> oh, and that produces different result than dexconf?
[08:24] <bryce_> it seems to, but just slightly
[08:25] <rawler> interesting.. you'll have to explain why, some day.. :)
[08:25] <bryce_> heh, some day I plan to rip all this out ;-)
[08:25] <rawler> but now, will you ask John to regenerate the conf, or shall I?
[08:25] <bryce_> anyway, I'm not sure regenerating the xorg.conf will have any effect for him
[08:25] <rawler> I can imagine.. ;)
[08:25] <rawler> how so?
[08:26] <bryce_> if I understand gdm correctly (and I probably don't), it does not use xorg.conf but manages its own x session
[08:26] <bryce_> I *think* it uses the framebuffer, but I'm not sure
[08:26] <rawler> no GDM uses xorg.conf.. :)
[08:26] <bryce_> in any case, it's quite common to see completely different results when in gdm from when in x
[08:27] <tepsipakki> bryce_: could those xresprobe problems relate to the new intel driver? was it enabled for other chips other than those known to be broken?
[08:27] <bryce_> tepsipakki: it's possible...
[08:28] <bryce_> tepsipakki: we basically switched to -intel for everything
[08:28] <rawler> what COULD be the case, though (since John says nothing about problems while RUNNING the system) is that Xorg.conf has bad resolutions.. when gnome launches, though, it reads it's own config (some gnome-tool to change monitor resolution and orientation), and invokes XRandr, setting a useful resolution..
[08:29] <rawler> I experience a similar problem in a rotated-monitor-setup at work
[08:29] <tepsipakki> bryce_: right
[08:30] <rawler> btw, if you want to have fun for a couple of minutes, take a cheap widescreen lcd-tv (I hear plasma is even funnier for this), and flip it 90 degrees, and let it hang there for a year or so.. ;)
[08:30] <tepsipakki> bryce_: also, are all of those laptops? I have a desktop with i965 which doesn't suffer from this (and it has always used -intel)
[08:32] <bryce_> rawler: heh
[08:33] <bryce_> tepsipakki: it sounds like it...  I just got a 965gm board myself, and plan to check it once the system's put together
[08:33] <bryce_> tepsipakki: there's different kinds of 965 so possibly only the laptop variants of the chip have it or something?
[08:34] <tepsipakki> now sopranos -> (final season just started here, no spoilers please :)
[08:35] <bryce_> someone gets killed
[08:35] <bryce_> oops sorry
[08:35] <bryce_> heya tormod!
[08:35] <tormod> hi bryce :)
[08:36] <rawler> bryce_: running dpkg-reconfigure xserver-xorg gives me the (lengthy) dialog of all the settings etc.. am I missing something, I tought dexconf gave defaults without asking?
[08:36] <bryce_> that's correct
[08:37] <rawler> so, why am I getting the dialog? is that the expected behaviour? (confused)
[08:37] <bryce_> rawler: yes that's expected behavior.  (which is one of the reasons I usually just have users hand-edit the xorg.conf)
[08:38] <tormod> rawler: -phigh help a bit
[08:38] <rawler> hehe.. me to, I usually look over xorg by hand (which is why I know nothing about dexconf and friends), but I'm a bit unsure of what John should be looking for in his xorg?
[08:38] <rawler> tormod: ?
[08:39] <tormod> dpkg-reconfigure -phigh xserver-xorg  only asks a few questions
[08:39] <rawler> tormod: *ahh* I see.. :)
[08:41] <tormod> but the obscure thing is that it picks old values from the dexconf database - dexconf doesn't, IIRC
[08:41] <rawler> lovely.. sounds like all this needs a cleanup..
[08:41] <bryce_> dexconf also pulls from the debconf database
[08:41] <bryce_> rawler: indeed
[08:41] <tormod> so that "dpkg-reconfigure -phigh xserver-xorg" does not reconfigure from scratch...
[08:42] <rawler> what is done at installation, then?
[08:42] <tormod> bryce, you're right (of course)
[08:43] <tormod> rawler: dpkg-reconfigure -phigh xserver-xorg, but with an empty debconf I think.
[08:43] <rawler> but high still demands resolutions?
[08:43] <tormod> rawler: hmm I think I have seen that, yes.
[08:44] <rawler> oh, well.. I've given John a reply now, atleast.. let's see how it goes.. :)
[08:45] <tormod> on the Desktop cd, the X configuration is done in casper, at the "break=bottom" phase xorg.conf is done.
[08:45] <rawler> now I'm off for some REAL slacking, before going to bed.. (gotta get up at 03:45 tonight to perform a server-upgrade while our customers are asleep)
[08:45] <bryce_> no, at installation time, the xserver postinst script populates the debconf database
[08:46] <bryce_> if you're in the mood for a scare, some day apt-get source xorg and look at the xorg-server.postinst.in script
[08:46] <bryce_> it's a 2108-line bash script full of poorly maintained heuristics that "guess" at all sorts of things
[08:47] <rawler> bryce_: thank you, but I would like to keep my food in my stomach.. ;)
[08:47] <tormod> search for "resolution hell" (sic) :)
[08:47] <rawler> actually, I've seen worse.. ;)
[08:48] <rawler> well, actually, i saw worse RIGHT NOW: http://it.slashdot.org/article.pl?sid=07/09/24/2339203&from=rss
[08:55] <seb128> bryce_: do you need any data about that wrong intel resolution detection?
[08:55] <seb128> bryce_: I can change to the correct one with the gnome display tools (the simple one using xrandr), the resolutions are correctly listed
[08:56] <seb128> it's just using 1024x768 where is should use 1280
[09:00] <bryce_> seb128: I suspect it's just bug 49827 popping its head up again, but if you have earlier tribes available and can determine with which one it started failing, I could check into it from that angle
[09:00] <ubotu> Launchpad bug 49827 in xorg "Available resolutions incompletely set to 1024x768, 800x600, 640x480" [High,Confirmed]  https://launchpad.net/bugs/49827
[09:01] <seb128> not I don't
[09:01] <bryce_> seb128: often the source of the problem is xresprobe failures, you could run that and see if it gives proper output
[09:01] <seb128> I can download them but my dsl is no really fast so it'll take me some days
[09:02] <bryce_> ok, well no worries - as long as it can be fixed up properly in S&G, then for Gutsy I think that's an semi-okay approach for users
[09:02] <seb128> you mean that's not going to be fixed before gutsy?
[09:03] <bryce_> right
[09:03] <seb128> that's quite an ugly regression
[09:03] <bryce_> hmm, I'm not sure; we used i810 in feisty
[09:03] <seb128> from an user point of view that's a regression
[09:03] <bryce_> in fact I just booted a new 965gm board on a feisty cd and it came up with i810 in 640x480
[09:03] <seb128> this laptop used to work correctly with previous versions of Ubuntu
[09:04] <seb128> any reason it could not be fixed before gutsy, there is still some weeks
[09:04] <seb128> ?
[09:05] <bryce_> well, mostly just that I'm trying to focus on bugs that are preventing users from being able to complete an install, as the highest priorities.  We've several of these issues with intel chips and -ati
[09:05] <seb128> k
[09:05] <bryce_> however if it can be pinpointed when this issue started occuring, I could start looking from there
[09:05] <seb128> xresprobe indeed list 1024x768 only
[09:06] <seb128> what package is to downgrade?
[09:06] <bryce_> yeah I think a fix for this particular issue is going to require a good bit of C/asm hackery on xresprobe or lower tools
[09:06] <seb128> it's easier for me to downgrade something that to spend 1 week downloading iso for that
[09:06] <bryce_> I would suggest first testing i810 to see if it detects right
[09:07] <seb128> no it doesn't
[09:08] <seb128> that's weird
[09:08] <bryce_> there haven't been any changes to i810 for gutsy, so that would rule out driver issues
[09:08] <seb128> I've a gutsy installation on this laptop which is a feisty upgrade and has the right resolution
[09:08] <bryce_> which means either xserver or (maybe) xresprobe
[09:08] <seb128> though I didn't update it for some weeks
[09:09] <bryce_> you could compare the xorg.conf's of the two machines
[09:10] <seb128> that's the same machine ;)
[09:10] <bryce_> my guess is that the xorg xorg-server.postinst.in script in feisty generated a correct xorg.conf, but the one in gutsy did not
[09:10] <seb128> but yeah, will compare the installations
[09:11] <bryce_> if that's the case, then it would be interesting to see if xresprobe gives the same output on both (partitions? vmimages?)
[09:11] <seb128> partitions
[09:12] <seb128> the upgraded version list a bunch of 1280x800 modes in the xorg config
[09:12] <seb128> it lists those for Depth 1 4 8 15 16 24
[09:13] <seb128> xresprobe lists 1280x800 on the installation which is working correctly
[09:14] <seb128> let me update the installation
[09:17] <bryce_> yeah that's what I suspected
[09:18] <bryce_> interesting; I wonder what caused xresprobe to fail here?  perhaps this is related to the other general xresprobe failures we're seeing elsewhere?
[09:20] <tepsipakki> bryce_: you were right, some punk had it coming :)
[09:21] <bryce_> tepsipakki: hehe
[09:22] <seb128> bryce_: does xresprobe uses the xorg.conf?
[09:22] <bryce_> seb128: no
[09:22] <bryce_> seb128: it attempts to probe the hardware directly.  I think it uses the monitor edid to figure out resolutions
[09:22] <seb128> what could make it not work on the new install like it does on the upgrade?
[09:22] <tepsipakki> bryce_: re: xorg-server.postinst; it's going to be reduced dramatically in debian soonish, since their goal is to get rid of discover and xresprobe (and looking at the past discussions, should be ours too :)
[09:23] <seb128> I'm upgrading xserver-xorg-core at the moment
[09:23] <bryce_> seb128: there's a couple of things I can think of
[09:23] <bryce_> first, xresprobe is a wrapper around a few other lesser tools; possibly one of those went missing or became broken for some reason
[09:23] <tepsipakki> and that postinst is available on every system in /var/lib/dpkg/info/xorg-server.postinst
[09:24] <bryce_> second, this also uses some fairly low level platform-dependent code, so I could imagine that changes to like libc or the kernel might have affected that
[09:24] <bryce_> tepsipakki: awesome, that's exactly what I'd planned
[09:24] <tepsipakki> oops, make that /var/lib/dpkg/info/xserver-xorg.postinst
[09:24] <bryce_> tepsipakki: is there anything we could do to assist with that, or should we just cheer them on and wait?  :-)
[09:25] <tepsipakki> bryce_: I think jcristau can answer that :)
[09:25] <tepsipakki> also, I hope to get in touch with gravity while in Boston :)
[09:25] <bryce_> cool
[09:26] <seb128> bryce_: upgrading xserver-xorg-core makes no difference
[09:27] <bryce_> mmm, interesting
[09:27] <seb128> ah
[09:27] <seb128> intel is buggy now
[09:27] <bryce_> is xresprobe still working then?
[09:28] <seb128> it lists 1024x768 now for intel
[09:28] <seb128> still 1280x800 for i180 though
[09:28] <seb128> I just upgrade xserver-xorg and xserver-xorg-core
[09:28] <seb128> upgraded
[09:28] <seb128> let me downgrade
[09:31] <bryce_> the one change to xresprobe is that mjg added support for -intel about 6 weeks ago
[09:31] <bryce_> but that was just adding "intel" into a switch statement, nothing elaborate
[09:33] <bryce_> seb128: is your system a laptop, crt, or lcd?
[09:33] <seb128> laptop
[09:34] <bryce_> do you have laptop-detect installed?  does it return true when run?
[09:38] <bryce_> seb128: the tool xresprobe uses to get the resolutions is ddcprobe
[09:39] <seb128> bryce_: it's not installed on the beta installation, it is on the working upgrade
[09:42] <bryce_> aha
[09:43] <bryce_> ddcprobe is not on the beta installation?
[09:43] <bryce_> hmm, it should have been included in the xresprobe package
[09:43] <seb128> no
[09:44] <seb128> not installed
[09:44] <seb128> ok
[09:44] <bryce_> ok so that would be the problem
[09:44] <seb128> the bug happens when upgrading xserver-xorg-core
[09:44] <bryce_> weird, how can that even happens
[09:44] <seb128> no
[09:45] <seb128> with an uptodate xserver-xorg-core intel is wrongly detected on the upgrade
[09:45] <seb128> so that's not it
[09:45] <seb128> I'm looking for the version creating the issue now
[09:45] <seb128> 6ubuntu3 works correctly
[09:46] <seb128> xresprobe list correctly 1280x800 using xserver-xorg-core 3.0.0-6ubuntu3
[09:46] <seb128> it doesn't when I update to the current package
[09:46] <bryce_> ahh
[09:47] <bryce_> can you try 12ubuntu2?  that was the version immediately prior to the backports
[09:47] <seb128> downloading it
[09:47] <bryce_> if that works, then it is likely that either 12ubuntu3 or 12ubuntu4 caused the breakage
[09:48] <seb128> yes, this one works
[09:48] <seb128> let's try ubuntu3
[09:48] <bryce_> aha
[09:50] <seb128> works
[09:50] <seb128> let's try the next one ;)
[09:52] <seb128> bryce_: ok, upgrading from 2:1.3.0.0.dfsg-12ubuntu3 to 2:1.3.0.0.dfsg-12ubuntu4 creates the bug
[09:52] <bryce_> hmm, could be patch 136
[09:52] <bryce_>     - 136_fedora_xserver-1.2.0-honor-displaysize.patch:  Fixes issue if monitor
[09:52] <bryce_>       width and height have been specified, xserver would override them
[09:52] <bryce_>       with the hsize/vsize detected from DDC.
[09:52] <bryce_> 
[09:53] <seb128> dccprobe doesn't list 1280x800
[09:53] <bryce_> maybe 143
[09:54] <bryce_>     - 143_fedora_xserver-1.3.0-randr12-config-hack.patch:  Adds check to use
[09:54] <bryce_>       the screen's xrandr modes if a preferred mode was not specified.
[09:54] <seb128> k
[09:54] <seb128> it's getting late here
[09:54] <bryce_> none of the other patches jump out at me
[09:54] <seb128> but I can try tomorrow to rebuild without 136 and see if there bug is still there
[09:54] <seb128> and same for the 143 one
[09:54] <bryce_> ok cool, let me know how that goes
[09:54] <seb128> ok
[09:55] <bryce_> wow I think we got this tracked down pretty close
[09:55] <bryce_> damn fedora ;-)
[09:55] <seb128> ;)
[09:55] <seb128> maybe it'll be fixed for gutsy :p
[09:55] <bryce_> if it's just a matter of dropping a patch, we can count on it
[09:56] <ubotu> New bug: #125904 in displayconfig-gtk (main) "random crash (dup-of: 126561)" [Undecided,New]  https://launchpad.net/bugs/125904
[10:09] <bryce_> tormod or tepsipakki, -nvidia does not support xrandr, right?
[10:10] <bryce_> I notice in bug 144777 there's an error in -nvidia complaining about xinerama not being there; however I don't know why that'd break unless they'd switched to xrandr
[10:10] <ubotu> Launchpad bug 144777 in xorg "xinerama xserver crash" [Undecided,New]  https://launchpad.net/bugs/144777
[10:19] <tepsipakki> bryce_: it has it's own twinview-thingy
[10:21] <tepsipakki> besides, that's 1.0-9639
[10:23] <bryce_> tepsipakki: hmm, I could swear I used to run xinerama on -nvidia
[10:23] <tepsipakki> surely it supports that as well
[10:24] <tepsipakki> I guess twinview is comparable to the mergedfb-cruft that ati had?
[10:24] <bryce_> sounds like it
[10:25] <tepsipakki> btw, ati now defaults to 1280x1024 on my crt
[10:25] <tepsipakki> noticed the discussion on #u-d
[10:25] <bryce_> is that what it should be?
[10:25] <tepsipakki> well, it can do 1600x1200 just fine, but I don't think that's critical
[10:25] <tepsipakki> since the resolution can be changed by the user
[10:25] <tepsipakki> =me
[10:26] <tepsipakki> so maybe it's randr-1.2 enabled drivers that have these, ie. intel and ati?
[10:26] <tepsipakki> +issues
[10:26] <bryce_> maybe
[10:43] <seb128> bryce_: that's not the patch 136
[10:58] <seb128> bryce_: it's due to 143_fedora_xserver-1.3.0-randr12-config-hack.patch
[10:59] <seb128> bryce_: what is this one supposed to fix?
[10:59] <bryce_> aha
[10:59] <bryce_> it changes how x selects a default mode
[11:00] <seb128> right, I got that from the description and behaviour
[11:00] <seb128> but when is a preferred mode specified?
[11:01] <bryce_> you'd put in something like,  Option "Preferred Mode" "1680x1050_60.00"
[11:01] <bryce_> I don't expect users need to do that often, so am comfortable dropping the patch since it causes this breakage
[11:02] <bryce_> I gather the preferred mode allows you to specify what happens when issuing xrandr --auto
[11:07] <Matir> does anyone know of a way to modify xorg.conf to force -VSync -HSync
[11:09] <bryce_> Matir, you mean other than adding HorizSync       28-80  and   VertRefresh     48-75?
[11:09] <seb128> bryce_: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/144956
[11:09] <ubotu> Launchpad bug 144956 in xorg-server "incorrect screen resolution on gutsy beta using intel" [Undecided,New]  
[11:09] <Matir> bryce, that will make it use Negative polarity?
[11:09] <bryce_> seb128: ok thanks
[11:10] <seb128> you're welcome
[11:10] <bryce_> Matir, replace the numbers with whatever is appropriate for your monitor
[11:10] <tepsipakki> Matir: you want to set a custom Modeline
[11:10] <tepsipakki> ?
[11:11] <Matir> I suppose.... right now I'm having to use xrandr every time the machine starts to get X working... and I added the Modeline, but it will still using a built-in autodetected line
[11:12] <tepsipakki> http://www.intellinuxgraphics.org/dualhead.html
[11:12] <tepsipakki> doesn't Option PreferredMode help?
[11:13] <tepsipakki> Matir: umm, which driver?
[11:14] <Matir> ati
[11:14] <tepsipakki> so you are hit with the same bug that was just discussed :)
[11:15] <ubotu> New bug: #144956 in xorg-server (main) "incorrect screen resolution on gutsy beta using intel" [Undecided,New]  https://launchpad.net/bugs/144956
[11:16] <Matir> possibly... not sure
[11:16] <Matir> There's an outstanding bug for my issue, that I've been trying to help debug as best as I can.... https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/132716
[11:16] <ubotu> Launchpad bug 132716 in xserver-xorg-video-ati "ATI Driver Gets Black Screen on Radeon 7500 Mobile (Regression)" [High,Confirmed]  
[11:17] <tepsipakki> ah
[11:36] <tormod> just to make it clear: matir means the -VSync option to the modeline, not any ranges.
[11:36] <Matir> yes, i guess i may have been vague, sorry
[11:42] <bryce_> ah, yes I misinterpreted that, sorry
[11:43] <tormod> good night