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