=== Sinnerman is now known as Cobalt
=== yofel_ is now known as yofel
=== L3ttuce is now known as Cobalt
[17:02] <Sarvatt> ok, how about a nonouveau (can anyone think of a better word?) boot option to blacklist the nouveau module so people can actually use vesa or nv without manually blacklisting it? noticing this is a pretty sore spot right now
=== L3ttuce is now known as Cobalt
[17:19] <Sarvatt> oh, blacklist=nouveau directly from the kernel command line looks like a valid option now that I'm digging through initramfs-tools, didn't know that
[17:36] <Sarvatt> http://bazaar.launchpad.net/~sarvatt/initramfs-tools/working/revision/163 is kind of pointless then if they can just do blacklist=nouveau, need to try that out
[17:40] <Sarvatt> i'm thinking it might be handy to have say, failsafex or the old xforcevesa as boot arguements. we could blacklist all KMS drivers in initramfs-tools and have the gdm upstart job pick failsafeX if it matches because its already checking the kernel command line for inhibitors
[17:44] <Sarvatt> then we could just extend the kernel command line check in /etc/init/gdm.conf to check for the command and set env XORGCONFIG=/etc/X11/xorg.conf.vesa and ship a new stock vesa xorg.conf?
[17:46] <Sarvatt> actually we could just make gdm exit1 if it matches, that'd automatically start a failsafe session
[17:53] <verbalshadow> what did i miss? booting with Mobility Radeon HD 4200 with KMS now freeze my system and won't boot with out disabling.
[18:14] <Sarvatt> verbalshadow: mind filing a bug so we can look at your logs?
[18:15] <Sarvatt> just ubuntu-bug xserver-xorg-video-ati and subscribe Sarvatt if you dont mind
[18:16] <Sarvatt> and whoa booting straight into failsafe is insanely fast compared to normal booting, menu was up in 11 seconds on this slow hdd netbook
[18:22] <verbalshadow> Sarvatt: filing now
[18:31] <verbalshadow> ok  now i need to file a bug on ubuntu-bug it thinks i don't have an internet connection and can't connect to the crash DB :(
[19:20] <Sarvatt> hmm, not having any luck adding the xforcevesa option to initramfs-tools. i added the option to Init and had it set blacklist=drm,i915,nouveau,radeon and quiet=n, and also tried adding a check for xforcevesa to scripts/init-top/blacklist and blacklist those modules explicitly in there 
[19:21] <Sarvatt> but plymouth seems to be loading drm/i915 and such on its own
[19:22] <Sarvatt> changed the gdm upstart job to exit 1 if it sees xforcevesa in /proc/cmdline to load failsafe and that part works but its using fbdev on top of KMS of course because drm and such is loaded for plymouth
[19:31] <Sarvatt> looks like i need to either extend plymouth to recognize xforcevesa as well or remove splash from the cmdline if xforcevesa is used
[20:02] <Sarvatt> no luck, removing splash doesn't stop i915 from loading. hmm
=== radoe_ is now known as radoe
[20:06] <bjsnider> is superm1 ever in here on weekends?
[20:08] <Sarvatt> verbalshadow: https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/538097
[20:08] <ubottu> Launchpad bug 538097 in launchpad "Apport cannot connect to crash database" [Undecided,Confirmed]
[20:09] <Sarvatt> maybe if you ping him and ask a question he might pop up :)
[20:21] <bjsnider> are there any useful dkms logs anywhere? there's one in /var/log but it's no help
[20:26] <albert23> bjsnider: there is a full build log like  /var/lib/dkms/nvidia/kernel-2.6.31-20-generic-x86_64/log/make.log
[20:47] <bjsnider> if the build didn't happen on that kernel that directory and log do not end up existing
[20:50] <bjsnider> all i get here is exit code 6
[22:36] <Sarvatt> anyone really familiar with compiz? i'm almost positive its one of our patches breaking resoluions where one side is the same as the max texture size, 010-disable-child-window-clipping.patch maybe? it's just 1 pixel thats the problem, 2047x1152 works for instance if the max texture size is 2048
[22:37] <RAOF> I used to be a bit familiar with compiz.
[22:41] <BUGabundo> RAOF: used to ?
[22:41] <RAOF> Compiz *has* been around a while :).
[22:41] <BUGabundo> ahh
[22:41] <BUGabundo> well, before compiz we had 
[22:42] <Sarvatt> we should probably adjust our max texture size checks in 060_move_checks_to_compiz.patch to max -1 though because people with 2048x1152 monitors are having all kinds of problems
[22:42] <BUGabundo> ... what was it called? ....
[22:42]  * BUGabundo blanks
[22:43] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/428769
[22:43] <ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor" [Undecided,Confirmed]
[22:43] <Sarvatt> i want to ask those people to try a fedora livecd and see if its different because they dont have most of our compiz patches :D
[22:43] <RAOF> Which lucky bugger has a 2048x1152 monitor? :)
[22:44] <Sarvatt> lots of mac people
[22:44] <RAOF> Aaah.
[22:49] <BUGabundo> ehe
[23:39] <MarcoPau> Hello, I just put xserver-no-backfill ppa in my sources.list but I don't get anything upgraded out of it. Any hint? Using karmic
[23:40] <libv> jcristau: ?
[23:40] <MarcoPau> the xorg-server package itself is not available
[23:40] <libv> jcristau: how does this affect compatibility over the different kernel versions?
[23:41] <libv> (from a separation pov, i like the move though, this drm/libdrm stuff is a right mess)
[23:49] <libv> nah, nm my question, the compat issue is just as bad from either side of the change
[23:50] <libv> there are only two solutions to this compatibility issue anyway
[23:50] <jcristau> meh.  whoever tries to make it work with different versions can fix things up
[23:51] <libv> yes :)
[23:51] <libv> it's an issue between developer and user, and the packager is between a rock and a hard place there
[23:53] <libv> unable to satisfy both in the current constellation