=== zorael_ is now known as Zorael
[01:15] <Sarvatt> jbarnes: good news!!! figured out Zorael's crash when closing the lid. darn KDE!!
[01:16] <Zorael> :3
[01:16] <Sarvatt> in /usr/share/acpi-support/screenblank there is a call to lock the screen in KDE before dpms off
[01:16] <Sarvatt> elif [ `pidof dcopserver` ]; then
[01:16] <Sarvatt>         dcop kdesktop KScreensaverIface lock
[01:16] <Sarvatt> fi
[01:17] <Sarvatt> (then xset dpms force off
[01:17] <Sarvatt> apparently theres no way to adjust that and it always locks the screen on KDE because of that script
[01:23] <Sarvatt> thats pretty major and needs to get fixed up, i wonder how many of these bug reports regarding lid close hangs are in KDE
[02:08] <Sarvatt> https://bugs.edge.launchpad.net/bugs/390917
[02:08] <ubottu> Ubuntu bug 390917 in acpi-support "screenblank script unconditionally forces screen lock in KDE which causes crashing upon lid close under KMS." [Undecided,New]
[02:15] <jbarnes> Sarvatt: so what's the root cause of the hang in that case?
[02:15] <jbarnes> if it's a GPU hang it's still a driver bug
[02:15] <jbarnes> but if it's some other app locking things up...
[02:16] <RAOF> Oooh.  I think I might see that bug.
[02:16] <Sarvatt> theres a problem locking the screen in gnome too, someone was saying they get a huge amount of gem_objects adding up when they locked their screen
[02:20] <jbarnes> Sarvatt: ah that would be interesting
[03:04] <Sarvatt> jbarnes: looks like its a userland problem
[03:05] <Sarvatt> i had hcarty run  sudo xset dpms force off to see if it worked normally or if it crashed for him and it works normally, gnome-screensaver must be calling something else on top of it too
[03:05] <jbarnes> Sarvatt: ok thanks... please update the bug with whatever you find
[03:08] <Sarvatt> i'm just guessing gnome-screensaver is locking the screen/session after an extended period of idle, why locking when dpms is off is broken under KMS all around would be interesting to know if thats the case..
[03:18] <Sarvatt> argh, cant ever be cut and dry.. sudo xset dpms force off && sleep 50 && sudo xset dpms force on hung for him. the other guy was using the lidfix -intel driver and this guy is using the normal one
[03:24] <Sarvatt> having him update with the driver that has your patch from http://bugs.freedesktop.org/show_bug.cgi?id=22383 to see if that fixes it
[03:24] <ubottu> Freedesktop bug 22383 in Driver/intel "X server stuck in infinite loop on laptop lid close" [Critical,New]
[04:01] <hyperair> Sarvatt: but it seems fixed.
[04:01] <hyperair> i haven't tried the laptop lid thing
[04:01] <hyperair> will try it after thunderbird's done compiling.
[04:01] <hyperair> stupid enigmail dosen't have a x64 build for tb3
[06:37] <Sarvatt> oops, Estimated repository size: 1.8 GiB (88.00%) of 2.0 GiB
[06:37] <Sarvatt> not enough room to update the kernel in edgers, going to have to ask for more
[06:38] <RAOF_> You could probably out-of-tree the drm modules?
[06:42] <RAOF_> That's how I need to do the new nouveau-kernel-source package.
[07:08] <Sarvatt> libdrm is going to need updating before you upload if you're packaging nouveau up
[07:10] <Sarvatt> i dropped kernel-source completely and threw apw's kernel in here https://edge.launchpad.net/~xorg-edgers/+archive/nouveau -- there are some huge problems with it right now in that non KMS doesnt even work on any machine i've tested it on
[07:23] <RAOF_> Sweet.
[07:25] <RAOF_> I'm just aiming to get it to build out-of-tree right now, though.  That'll be a prerequisite of any package update :)
[07:31] <Sarvatt> i imagine thats going to break things for non-nouveau on karmic if you do get it working?
[07:34] <Sarvatt> that'll be odd for the intel/nvidia hybrids
[07:34] <RAOF_> No, I don't see why?
[07:34] <RAOF_> Ok, possibly.
[07:34] <RAOF_> How many intel/nvidia hybrids are there, anyway?
[07:35] <RAOF_> And they're already broken; the binary driver breaks everything anyway.
=== RAOF__ is now known as RAOF_13
=== RAOF_13 is now known as RAOF
[08:47] <RAOF> Ok.  Here's something that should build out-of-tree.  Let's try it on an actual nvidia-containing laptop!
[08:53] <hyperair> intel/nvidia hybrids? O_o
[08:53] <hyperair> you mean there are laptops with two gpus?
[08:54] <RAOF> Or desktops with integrated intel cards + an actual video card.
[08:56] <Ng> hyperair: yeah, e.g. some Vaios, they have a switch to flick between performance and battery life
[08:56] <Ng> I think there might even be a thinkpad with such a thing
[08:56] <hyperair> hey that's pretty damn cool
[08:57] <hyperair> for a moment i thought you could have separate X screens on them =\
[08:58] <RAOF> You'd have problems there already; X doesn't much like multi-card.
[08:59] <Ng> hyperair: I'm pretty sure it's not cool ;)
[09:00]  * RAOF wishes get-orig-source didn't have to clone a kernel repository.
[09:00] <hyperair> Ng: why not?
[09:00] <hyperair> Ng: only one is active at any one time right?
[09:02] <Ng> hyperair: yeah, but it's a bit of a nasty hack, it would make more sense for the chipsets to be able to scale themselves up and down, imho
[09:02] <hyperair> hmm yeah
[09:02] <hyperair> true
[09:10] <RAOF> The chipsets already _can_ do that.
[09:10] <hyperair> nvidia chipsets you mean?
[09:11] <RAOF> Certainly the nvidia ones can; I presume the intel ones can to.
[09:11] <hyperair> i'm not sure they can
[09:11] <hyperair> i'v never heard of any such thing
[09:11] <hyperair> at the very least, i don't think there are any knobs to tweak
[09:11] <RAOF> Why would there be?
[09:12] <hyperair> hmm so it's autoscaling?
[09:12] <RAOF> Well, care of the driver.
[09:12] <hyperair> er maybe i'd like to drain my battery extra fast =p
[09:12] <RAOF> You might want to try running under Windows; I'm fairly sure that exposes some Intel graphics powersave options.
[09:13] <hyperair> don't remember seeing it =\
[09:13] <hyperair> but then again that's a desktpo
[09:19] <RAOF> Yeah.  Amazingly enough, they don't tend to add crazy OMGBATTERYLIFE applications to desktops :)
[09:37] <hyperair> surely the driver is the same =\
[10:11] <Sarvatt> check out gmabooster hyperair :D
[10:11] <hyperair> what/s that? O_o
[10:11] <Sarvatt> gmabooster.com
[10:15] <hyperair> huh overclocking intel gpu O_O
[10:16] <Sarvatt> oh right you're using 965, sorry
[10:17] <hyperair> ._.
[10:17] <hyperair> you mean it doesn't work for 965?
[10:51] <Sarvatt> sweet, thJaeger fixed up wacom for xinput abi 7 and its working here. i really wish we had xorg-testing on the edgers team so other people could help me out without mailing me the packages :)
=== zorael_ is now known as Zorael
[12:26] <Sarvatt> man, this dpms problem is complicated
[12:32] <cwillu> question:  how long has x2i been in edgers (if it's there at all)?
[12:34] <Sarvatt> it hasnt been in edgers yet, i've been doing it on my own for the past month or so
[12:35] <Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/xorg-testing
[12:36] <cwillu> okay
[12:36] <cwillu> must be a gedit bug then that pasting and typing occasionally just happens to a previous cursor location
[12:36] <cwillu> seemed like something that might have been related :p
[12:38] <Sarvatt> any way you can reproduce it 100% so i can see if it happens to me? i havent noticed that
[12:39] <Sarvatt> any special plugins you have enabled?
[12:40] <cwillu> I can't discount a plugin screwup yet
[12:40] <cwillu> I'd just ignore that I said anything for now :p
[13:03] <hyperair> what's x2i?
[13:03] <hyperair> or did you mean xi2?
[13:24] <Unggnu> hi
[13:24] <Unggnu> Where can I download the Ubuntu X testing live cd?
[13:26] <Unggnu> With KMS and latest drivers?
[13:26] <Unggnu> Or is it already enabled in current Karmic daily cds for -intel?
[13:27] <Sarvatt> the kernel with KMS enabled default is 2.6.30-10 if you can find a file manifest for the livecd
[13:35] <Unggnu> Sarvatt: thx
[13:36] <Unggnu> Sarvatt: it is still not the default kernel so no chance with the daily live cd
[13:37] <Unggnu> I could try modprobe i915 modeset=1 but it doesn't work with Jaunty. Is anything else needed for kms except of the Kernel parameter?
[13:38] <Sarvatt> when you boot the livecd, press f6 i think it is so you can see the kernel boot options
[13:38] <Sarvatt> scroll all the way to the right on the big line of text, and right before you see the -- at the end
[13:38] <Sarvatt> add i915.modeset=1
[13:38] <Unggnu> If I enable kms in Jaunty with the 2.6.30 kernel I still can use x but couldn't change to console
[13:39] <Sarvatt> so it looks like blahblah casper blahblah root blahblah i915.modeset=1 --
[13:39] <Unggnu> Sarvatt: Ok, thx
[13:39] <Sarvatt> sounds like you were using the mainline kernels instead of the karmic kernels, you can use video=fbcon at boot time to fix that if you want to use mainline ones for some reason
[13:39] <Unggnu> yes, mainline in Jaunty
[13:40] <Sarvatt> use karmic's kernel instead, its alot better for this :)
[13:40] <Sarvatt> wont have that problem
[13:40] <Unggnu> But then I have to upgrade to Karmic I guess
[13:40] <Sarvatt> nope just grab the kernel
[13:40] <Sarvatt> do you use xorg-edgers?
[13:40] <Unggnu> Btw. my boottime dropped about 4 seconds with the new Karmic kernel
[13:40] <Unggnu> Sarvatt: yes, at least some packages
[13:41] <Sarvatt> if so, just sudo apt-get install linux-image-2.6.30-10-generic linux-headers-2.6.30-10-generic linux-headers-2.6.30-10
[13:41] <Unggnu> intel driver and what else is needed to get it running
[13:41] <Sarvatt> karmic kernel is in the PPA for jaunty
[13:41] <Sarvatt> you need to upgrade everything in there at the same time, its not meant to be used pick and choose 
[13:41] <Unggnu> ah ok
[13:41] <Unggnu> I still want to have a stable system ;)
[13:41] <Unggnu> So I know what to remove
[13:42] <Unggnu> -intel, libdrm2 and libdrm-intel
[13:43] <Unggnu> But the fbcon option sounds promising. I am going to test it
[13:44] <Sarvatt> you dont want to use edgers then, you really cant just pick and choose because everything in there is built against the other things in there and depends on that. ya really want to use a different PPA if you just want a subset of the things in there
[13:45] <Unggnu> :)
[13:45] <Unggnu> The deb packages know what they need so there should be anything missing
[13:45] <Sarvatt> i wish it was that simple
[13:45] <Unggnu> The updates repository is great too but I wanted to test the tearing free textured video output
[13:45] <Unggnu> Works for me :)
[13:46] <Sarvatt> the deb packages for -intel do not know they were built against dri2proto 2.1 which exposes a new code path at compile time in the driver
[13:46] <Sarvatt> same for xserver, same for mesa
[13:47] <Sarvatt> if you just use the intel/drm from there with the ubuntu mesa, things are broken
[13:47] <Unggnu> video=fbcon was the problem
[13:48] <Unggnu> The only problem I had was that I have to manually define -intel otherwise I get vesa
[13:48] <Unggnu> drm2 and drm-intel are installed and current mesa
[13:48] <Sarvatt> thats because you dont have the xserver in there
[13:48] <Unggnu> That's why I wanted to test it with Karmic to see if a bug report is needed but obviously not
[13:49] <Sarvatt> i really need to make the warning about this on the page bigger or something
[13:59] <cwillu> Sarvatt, re: my other suspend issue (yay acer), http://bugs.freedesktop.org/show_bug.cgi?id=20520#c54 is reported to help eliminate the other suspend bug that is confounding things a bit
[13:59] <ubottu> Freedesktop bug 20520 in Driver/intel "[945GM] display freezes a few minutes after resuming" [Critical,New]
[13:59]  * cwillu pokes jbarnes with a stick
[13:59] <Sarvatt> i'm bugged out right now
[13:59] <cwillu> np
[13:59] <Sarvatt> lol
[13:59] <Unggnu> Sarvatt: :)
[14:00] <Unggnu> I give Karmic a shoot so I can open bug reports if something doesn't work.
[14:00]  * hyperair just realized that Sarvatt's kernel doesn't have fuse!
[14:00] <cwillu> "Sarvatt, I tried kexecing to a 2.6.27 kernel with an ext4 root fs, and it broke my suspend"
[14:00] <Sarvatt> yes it does!
[14:00] <hyperair> no wait it does
[14:01] <hyperair> hmmmmmmmmmmmmmmmmmmm
[14:01] <Sarvatt> it has CUSE too
[14:01] <hyperair> then why oh why doesn't tomboy detect it?!
[14:01] <Unggnu> 2.6.27 and ext4?
[14:01] <cwillu> ext4dev :p
[14:01] <cwillu> it was a joke
[14:01] <Sarvatt> LOL
[14:01] <hyperair> ._.
[14:01] <Unggnu> Even the 2.6.28 Ubuntu ext4 backport is broken
[14:03] <Unggnu> Another reason to use the mainline kernel :)
[14:03] <Unggnu> Does anyone know what was the reason for the fast Gnome start time since Jaunty?
[14:03] <Sarvatt> i've been trying to figure out the unable to resume from dpms off problems with different people through alot of trial and error, its funny i found a fix for 2 of them because I screwed up
[14:04] <Unggnu> :)
[14:04] <hyperair> O-o
[14:04]  * hyperair configured g-p-m to never dpms off
[14:04] <Sarvatt> commented out a fi when i shouldnt have so i killed the rest of the script from running which actually made it work right
[14:05] <hyperair> xDD
[14:08] <hyperair> hmm 24 hours uptime, compiz crashed once 12 hours ago, and GEM usage at 400M. this is awesome =D
[14:27] <Unggnu> Sarvatt: If Karmic is shipped with 2.6.31 will KMS be enabled for Radeon too?
[14:28] <Sarvatt> depends on if they can actually make it work withOUT kms at the same time by then probably :)
[14:28] <jcristau> .31 sounds early for that
[14:28] <Sarvatt> agreed
[14:35] <Sarvatt> imagine if they shipped UXA/KMS in jaunty... they could have since 2.6.29 was released in about the same time span away from jaunty as .31 will be from karmic :D
[14:38] <Unggnu> Sarvatt: KMS doesn't need to be enabled for Radeon I guess
[14:39] <Unggnu> And there is a really annoying suspend bug in 2.6.30 which hopefully gets fixed in 2.6.31
[14:40] <Sarvatt> i saw a promising patch for suspend/resume problems earlier
[14:41] <Sarvatt> http://lists.freedesktop.org/archives/intel-gfx/2009-June/002963.html
[14:41] <Unggnu> This is not an Xorg problem in my case.
[14:42] <Unggnu> my whole system gets corrupted after resume
[14:42] <Unggnu> readonly file system and so on
[14:42] <Sarvatt> ?
[14:42] <Sarvatt> ah
[14:42] <Unggnu> many dmesg errors and reboot doesn't work
[15:07] <Sarvatt> Zorael: did I miss anything here? https://bugs.edge.launchpad.net/ubuntu/+source/acpi-support/+bug/390917/comments/4
[15:07] <ubottu> Ubuntu bug 390917 in acpi-support "screenblank script unconditionally forces screen lock in KDE which causes crashing upon lid close under KMS." [Undecided,New]
[15:14] <Unggnu> Sarvatt: You mentioned a dpms freeze. Does this still happen with curent -intel driver?
[15:24] <Sarvatt> yeah quite alot of reports about systems not coming back up from dpms off (be from a lid close or screen idle timeout) in the past few weeks, i was trying to wrap my head around how it works to find any workarounds until its fixed and found one so far but its specific to KDE
[15:26] <Sarvatt> need to find someone on gnome having the problem to try having CheckPolicy() always return 1 in /usr/share/acpi-support/policy-funcs and then commenting out the xset dpms force off in /usr/share/acpi-support/screenblank to see if that works too
[15:28] <Sarvatt> well after also changing all of the gnome settings to do nothing instead of blank screen too
[15:30] <Unggnu> maybe it has something to do with kwin in combination with dpms
[15:30] <Unggnu> and the driver of course
[15:35] <Sarvatt> the acpi-support CheckPolicy in that policy-funcs script doesnt even check kde's power manager right as far as i can tell, it always returns 1 and lets acpi-support handle the events and something tells me they are both trying to handle things at the same time :D
[15:35] <Sarvatt> debian has patches to it that make it check the right things for kde but we dont have that
[15:47] <Sarvatt> cwillu: wow really good feedback on the patch in the bug you listed
[15:48] <Sarvatt> have you tried it out yet? need a kernel deb?
[15:49] <cgregan> hello x team! I was wondering the best place to put the TapButton synclient commands so they are applied during each boot in Karmic?
[15:53] <Sarvatt> cgregan: sudo wget -O /etc/hal/fdi/policy/11-x11-synaptics.fdi http://sarvatt.com/downloads/11-x11-synaptics.fdi
[15:54] <cgregan> Sarvatt: excellent! Thanks
[16:01] <hyperair> Sarvatt: considering hal's going to be dropped, where's the next best place to put all that?
[16:02] <hyperair> Sarvatt: i'm particularly going to miss my emulate 3 buttons hack (enabled for touchpads, disabled for actual mice)
[16:02] <Sarvatt> wait a week for gnome-settings-daemon to be updated where you can change it directly in the mouse control panel applet :)
[16:02] <hyperair> a week O_o
[16:03] <hyperair> i'm interested to see how that goes
[16:03] <Sarvatt> i could package it for you right now if you want :)
[16:03] <hyperair> nevermind
[16:03] <hyperair> if i wanted it that badly, i'd package it myself ;)
[16:03] <hyperair> i'm just surprised it's coming so quickly
[16:04] <Sarvatt> you can just grab the source, disable the ubuntu touchpad extension patch, and add this http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=4eb9bd09219afbb56f114a2d10bc585e24db803e
[16:04] <Sarvatt> well this too maybe :D http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=19476de63d140bb178d79a318e1916ac59d9cda1
[16:05] <hyperair> hmm.. /me clicks
[16:06] <hyperair> cool. it works with syndaemon now eh
[16:10] <Sarvatt> by the time hal is actually gone there will probably be a ton of things to control it, didnt look like it'd be hard to add it to gpointing-device-settings when i was looking at it the other day before i saw it was added to g-s-d
[16:12] <Sarvatt> gotta reboot and see if g-s-d is fixed with xinput abi 7 now
[16:30] <Unggnu> Sarvatt: If I use kms it works but I get the wrong resolution
[16:30] <Unggnu> it gets automatically corrected after starting the Display options but not before
[16:30] <Unggnu> How can I influence the default resolution of kms?
[16:31] <Unggnu> It seems that KDE doesn't use the xrandr service anymore
[16:37] <jbarnes> cwillu: pong
[16:48] <Unggnu> Sarvatt: Got this dpms freeze again
[17:03] <jbarnes> Sarvatt: thanks for the summary on that dpms bug
[17:03] <jbarnes> really seems to point at a driver issue
[17:12] <Unggnu> Cpu usage seems to be much more better with X in Karmic than in Jaunty
[17:16] <Sarvatt> yeah for sure, desktop environment doesnt matter and it happened all at once recently.. just thought it was interesting that it could be avoided doing certain things but I couldnt figure out how to find out more info on whats happening. almost seemed like acpid and the desktop environment could be figting over control and both acting on the actions since the policy in there doesnt check for kde4 power management and always tells the ac
[17:16] <Sarvatt> pi-support scripts run
[17:17] <Sarvatt> machines up, nothing in the logs but the screen wont turn back on unless the xset dpms force off is removed from the lid close script
[17:26] <albert23> jbarnes: fwiw, I had a freeze when display went off with the same gpu dump as Ben Gamari. This patch fixed it for me: http://paste.ubuntu.com/202245/
[17:29] <jbarnes> albert23: ah that's what my !crtc->enabled patch was supposed to do
[17:29] <jbarnes> I guess the crtc is still enabled but has a dpms mode of off
[17:29] <jbarnes> I'll fix it up
[17:36] <Zorael> Sarvatt: checked bug description, don't think you missed anything
[17:42] <Sarvatt> bryce: 3 people now that mentioned having problems in irc since the KMS kernel went into karmic an hour ago and all were the fbdev problem
[17:45] <jbarnes> "the fbdev problem" ?
[17:45] <Sarvatt> http://cgit.freedesktop.org/xorg/xserver/commit/?id=aef6b904ebf0d7de6259058606c7c04ea177bda3
[17:45] <jbarnes> oh right
[17:46] <jcristau> would be nice to fix that properly some day..
[17:46] <Sarvatt> more common than i thought to not have an xorg.conf i guess
[17:47] <Sarvatt> is it odd that it only happens with KMS?
[17:48] <bryce> Sarvatt, ah interesting; I'll up that in my todo list for today
[17:48] <bryce> btw, looking at the -nv pci id stuff presently
[17:48] <jcristau> Sarvatt: without kms you don't have a fb device
[17:48] <jcristau> well
[17:48] <jcristau> at least it's less common
[17:51] <jcristau> Sarvatt: pretty sure if you boot with vesafb and ums, you get the same FatalError
[17:53] <jbarnes> albert23: posted an updated patch for the vblank related hang
[17:53] <jbarnes> should fix the video case too
[17:54] <jbarnes> though I think there's other code to handle that already
[17:58] <Sarvatt> ahh i guess i was just assuming usplash loaded a fb of some sort, that'd explain it then
[18:03] <Sarvatt> nice that they even went and packed intel_agp and i915 into the initrd so it looks nice 4 seconds in instead of 15 :D but usplash doesnt work with KMS so the fsck display and dm-crypt entry screens are tricky this way..
[18:24] <Duke`> will they do something about usplash and KMS? will they fix it for karmic?
[18:27] <jbarnes> Duke`: the boot will be so fast you won't want usplash slowing you down
[18:27] <Duke`> oh yeah :p
[18:30] <Sarvatt> its about 10 seconds slower on my bootcharts than jaunty was for me, but i get a cursor and panel starting to load a good 20-30 seconds earlier than i did before and it feels faster because of it
[18:33] <Sarvatt> but my x is pretty different than the one in karmic (using xserver 1.7 with some different options) so i dont know if the speedup is there or all the gnome improvements
[18:42]  * Sarvatt wishes debuild had an ignore .git option
[18:42] <bryce> Sarvatt, I think it does actually
[18:42] <bryce> or you can force it:    debuild -I".git" -sa -S
[18:42] <Sarvatt> wow i need to look into that then
[18:43] <bryce> I think there might be a config file or env var you can set or something
[18:43] <jcristau> '-I -i' works
[18:43] <superm1> create ~/.devscripts
[18:43] <superm1> and set DEBUILD_DPKG_BUILDPACKAGE_OPTS
[18:43] <bryce> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn -I.git"
[18:43] <bryce> aha
[18:44] <superm1> the one i use probably doesn't account for .git, but it's easily added:
[18:44] <superm1> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps|\{arch\}|\.arch-ids|\.arch-inventory|\.bzr|\.bzrignore|\.shelf)(?:$|/)' -ICVS -I.svn -I\{arch\} -I.arch-ids -I.arch-inventory -I.bzr -I.bzrignore -I.shelf"
[18:45] <bryce> superm1, you run into arch repos much?
[18:46]  * Sarvatt cheers!
[18:46] <Sarvatt> thanks for the tip!
[18:48] <Sarvatt> probably will save me 300MB/day bandwidth from fdo with that :)
[18:59] <jbarnes> bryce: do you think 352207 might be a dupe of the recent 945 resume bug?
[19:00] <jbarnes> ah no it's hibernate... nm
[19:08] <bryce> jbarnes, ah
[19:09] <jbarnes> trying to reproduce now
[19:10] <Sarvatt> i've seen the invisible x thing from that before possibly, happened just yesterday actually. somehow x got moved over to VT9 (?) so i thought it was invisible and vt8 became vt1 but that might not be the same :D
[19:22] <tormod> http://www.phoronix.com/forums/showthread.php?t=17812 :)
[19:26] <superm1> bryce, no :) I got that somewhere in #ubuntu-motu like 2 years ago and it's not failed me, so i've not changed it
[19:26] <bryce> superm1, just giving you a hard time.  ;-)
[19:27] <bryce> tormod, wow, that is like the total inverse of a bug report ;-)
[19:48] <jbarnes> Sarvatt: ok so there's some confirmation of the patch in http://bugs.freedesktop.org/show_bug.cgi?id=22383
[19:48] <ubottu> Freedesktop bug 22383 in Driver/intel "X server stuck in infinite loop on laptop lid close" [Critical,New]
[19:48] <jbarnes> sounds like jithin still has issues though, maybe a differnt problem
[20:46]  * Ng spied a blog post earlier about problems with 2.6.30-10 and the intel driver. not upgraded yet though
[20:50] <jbarnes> bryce: hah, whenever I add to that hibernate bug something happens right after I hit "commit"
[20:50] <bryce> jbarnes, heh, figures
[20:57] <Sarvatt> Ng are you using KMS now? you wont have problems if so
[20:59] <Ng> Sarvatt: yep
[20:59] <Ng> :)
[22:34] <jbarnes> Sarvatt, bryce: just updated https://bugs.freedesktop.org/show_bug.cgi?id=22383 with a new patch that works for me
[22:34] <ubottu> Freedesktop bug 22383 in Driver/intel "X server stuck in infinite loop on laptop lid close" [Critical,New]
[22:43] <Sarvatt> uploaded to the same place -- https://launchpad.net/~sarvatt/+archive/bugs
[22:44] <Sarvatt> well it'll  be there in a few minutes at least
[22:47] <Sarvatt> oops i referenced the wrong patch name in the changelog but its the kms one and the link is right
[22:48] <bryce> apw, did the kernel upload with i915.modeset=1 by default go in?
[22:49] <Sarvatt> yeah a few hours ago
[22:49] <Sarvatt> 2.6.30-10.12
[22:57] <bryce> jbarnes, ok cool, I don't know if we have a bug in launchpad on that issue, but if not will it be included in the 2.8 release?
[22:57] <jbarnes> yeah it should be in 2.8 assuming I get some more good feedback
[22:58] <bryce> ok cool.  looks like jithin is giving pretty quick feedback on patches
[22:58]  * bryce is working on the mesa intel memory fixes currently
[22:58] <jbarnes> yeah shuang came up with a bunch of good ones
[22:59] <bryce> these look suitable for backporting, but since they appear to be UXA bugs maybe not worth risking it for jaunty.  But we'll see how the testing goes in karmic.
[22:59] <jbarnes> some are generic I think
[23:00] <jbarnes> haven't looked too closely though, maybe they only affect dri2 paths
[23:10] <apw> bryce, yeah went up today finally
[23:11] <bryce> apw, sweet.  do you plan to put out an announce to ubuntu-devel?  If not, I can do it.
[23:12] <apw> makes just as much sense if you do it, if you are happy to do it, its late here
[23:12] <bryce> no prob