[00:09] <bryceh> Sarvatt, true, although now with nvidia-updates being expedited, and nvidia-experimental for the beta drivers, those needs should hopefully be addressed in-archive now
[00:16] <bryceh> Sarvatt, we don't have the same set up for fglrx but I think we could (and should).
[00:16] <bryceh> but we can't do that for Intel so easily, so I think the PPA route is the way to go.
[00:20] <bjsnider> doesn't intel change 100% of the code every 20 minutes?
[00:28] <bryceh> bjsnider, heh
[03:49] <tjaalton> has anyone tried nomodeset with intel? xserver loads with vesa, but hangs immediately
[04:10] <tjaalton> at least vesafb needs to be prevented from loading with nomodeset
[04:53] <tjaalton> bryceh: bh.org seems down?
[05:29] <mlankhorst> RAOF: well no longer I think, pretty sure it fails on prime
[05:36] <RAOF> mlankhorst: Surely not - manufacturers *will* ensure that the BIOS splash will show up, and if we don't touch the hardware state we should always be able to output text on that video mode, right?
[05:37] <mlankhorst> or at least Xorg failed to start on my prime setup because intel wasn't prime capable, I'm pretty sure that vesa and fbdev are neither, but modesetting would be
[05:37] <mlankhorst> so... no longer true :p
[05:37] <RAOF> Oh, I don't mean X.
[05:37] <RAOF> I don't really care if X doesn't start in recovery mode; that's not what it's for :)
[05:37] <mlankhorst> yeah but it kills any hope of having failsafe-x working
[05:37] <RAOF> Only if we have nomodeset set, right?
[05:38] <mlankhorst> yeah
[05:38] <mlankhorst> but I'm wondering if we shouldn't simply add a 'noaccel' to kernel instead
[05:38] <RAOF> Failsafe-x is only really important to kick in when the user boots normally, but X doesn't otherwise work.
[05:38] <RAOF> “noaccel” doesn't fix the case of “my screen turns off as soon as I start booting”
[05:38] <mlankhorst> true
[05:39] <RAOF> If we need to change recovery mode so that it doesn't try to start X, then that's what we should do.
[05:43] <bryceh> tjaalton, godaddy fail.
[06:14] <tjaalton> bryceh: ah
[06:15] <tjaalton> hum, should i915_dri work on >965gm?
[06:15] <tjaalton> meaning, could I still bisect what broke it
[06:15] <RAOF> I don't believe so
[06:15] <tjaalton> ok
[06:19] <tjaalton> yup, fails
[06:19] <tjaalton> forcing i915 results in a nice hang/crash
[06:20] <RAOF> Doesn't surprise me :)
[06:23] <tjaalton> had to try :)
[07:08] <mlankhorst> RAOF: yeah but I mean, wouldn't blacklist.drm=1 or something be better?
[07:09] <RAOF> mlankhorst: Yes, it would.
[07:13] <tjaalton> cool, llvmpipe crash reproduced
[07:13] <tjaalton> by closing a firefox window..
[07:14] <tjaalton> *compiz crash
[07:21] <mlankhorst> RAOF: hm, the official way would be modprobe.blacklist=i915,nouveau,radeon then instead, in that case it will not load any of the drivers unless you start X
[07:22] <mlankhorst> I'll check if failsafe-x would cause it to load or not
[07:35] <mlankhorst> RAOF: it seems to have worked
[07:36] <tjaalton> heh, looks like we get to close all/most of the i8xx bugs, since the kernel requires pae support from the cpu
[07:39] <mlankhorst> hm all ddx drivers finished?
[07:40] <mlankhorst> guess I'll copy it over
[08:33] <mlankhorst> tjaalton: well I re-pushed most packages now to the ppa
[08:35] <tjaalton> mlankhorst: cool
[08:36] <tjaalton> and oh how sick gnome-settings-daemon is in handling the touchpad enable/disable state..
[08:36] <tjaalton> and how synaptics is sick in having two properties for disabling the device..
[08:37] <mlankhorst> O_O
[08:37] <tjaalton> xinput disable/enable touches "Device Enabled" property, but g-s-d touches both that and "Synaptics Off" property
[08:37] <tjaalton> so once they get off sync you don't have a touchpad anymore
[08:39] <mlankhorst> can you touch the the synaptics on property if the device is xi disabled?
[08:39] <tjaalton> yes
[08:40] <tjaalton> so you can reset the value and get it back
[08:41] <tjaalton> wtf, a crash
[08:42] <tjaalton> ahah, don't have the patch for that
[08:48] <tjaalton> also "disable while typing doesn't seem to work at all
[08:48] <tjaalton> +"
[09:40] <tjaalton> hah, barking at the wrong tree.. it's acpi-support
[09:45] <tjaalton> /etc/acpi/asus-touchpad.sh and g-s-d fighting
[09:51] <tjaalton> both being triggered
[10:16]  * mlankhorst is fighting lockdep itself, more fun :)
[10:37] <maxb> Short of actually installing it and seeing if it works, is there a better way to tell if quantal has a working fglrx?
[10:37] <tjaalton> that it refuses to install
[10:37]  * maxb sadly has a laptop which overheats dreadfully without the proprietary driver
[10:37] <tjaalton> you should use a stable release then
[10:38] <tjaalton> because fglrx is broken every release
[10:39] <maxb> I am aware of this. Hence looking to time my upgrade to ASAP after a working fglrx arrives
[10:39] <tjaalton> like after quantal is released? :)
[10:41] <maxb> If absolutely necessary, yes. But I can hope.
[12:04] <mlankhorst> well just did a nouveau ddx 1.0.2 release \o/
[12:07] <tjaalton> nice, and I pushed intel 2.20.7 to git
[12:08] <mlankhorst> ah great, I'll push nouveau too which gives us some parts that are prime capable
[13:57] <mlankhorst> tjaalton: you should be able to pick upload nouveau from debian-experimental now?
[13:58] <tjaalton> mlankhorst: yup see it
[13:59] <mlankhorst> was a bit of work to get right :)
[14:03] <tjaalton> noticed :)
[14:24] <tjaalton> mlankhorst: ok so should I upload these?
[14:25] <mlankhorst> yeah :)
[14:32] <tjaalton> the watch file needed updating
[14:39] <tjaalton> uploaded
[14:39] <tjaalton> both
[15:27] <tjaalton> time to update my laptop to quantal I guess.. bugs I'm still seeing with precise are also on quantal, so.. :)
[15:27] <tjaalton> plus the hybrid crack to test
[15:28] <mlankhorst> tjaalton: yeah I need to bug airlied for the hack that makes the x server automatically bind it
[15:28] <tjaalton> he sent it to xorg-devel@
[15:30] <mlankhorst> oh indeed he has :)
[15:31] <mlankhorst> my previous bugging was succesful then, can you test it?
[15:31] <tjaalton> I'll test it once it's finished, yeah
[15:31] <tjaalton> the upgrade
[15:31] <tjaalton> some time later this evening
[15:43] <tjaalton> "mixed non-coinstallable and coinstallable package instances present"
[15:43] <tjaalton> stopped there
[15:44] <mlankhorst> is that english?
[15:45] <tjaalton> from dpkg
[16:02] <jcristau> bleh.  precise makes gitk look like crap because xfonts-{100,75}dpi got moved to universe.
[16:03] <tjaalton> looks ok here
[16:35] <mlankhorst> jcristau: add recommends for those to gitk? :D
[16:36] <jcristau> no
[16:37] <jcristau> gitk is client side.  these fonts are server side.
[16:37] <mlankhorst> I didn't even notice though, gitk looks like crap in either case :)
[16:47] <tjaalton> it uses some antialiased fonts here
[16:50] <mlankhorst> I mean it clashes horribly with the rest of my desktop
[16:51] <tjaalton> ah
[16:52] <tjaalton> that's tk for you :)
[17:40] <jcristau> well the rest of my desktop is a bunch of xterms, so..