[00:00] <Galaxor> I get a black screen when trying to play video using Xv.  I can switch it to native X11 video just fine, and that's how I've been playing videos.  I've got enough cpu that it hasn't yet been an issue.  Still...
[00:02] <Galaxor> Oh, that was weird.  It was just that my contrast was set to -1000 in nvidia-settings.  I wonder how it got like that.  Oh well, that's fixed.
[00:02] <Galaxor> And that concludes the bugs.  My new computer now works perfectly.
[01:02] <RAOF> Sarvatt|gone: That's a fine idea, too.
[02:38] <bryceh> heya RAOF
[02:44] <RAOF> bryceh: Howdie
[05:03] <artfwo> Hello! I've stumbled upon a bug (actually 2 bugs), introduced by xserver-xorg-input-evdev 1:2.3.2-6ubuntu1. Could anyone experienced take a look?
[05:03] <artfwo> Bugs in question are bug 41301 and bug 583312
[05:03] <ubot4> Launchpad bug 41301 in xserver-xorg-input-evdev (Ubuntu) (and 2 other projects) "Mouse clicks stop working sporadically (affects: 41) (dups: 5) (heat: 270)" [Undecided,New] https://launchpad.net/bugs/41301
[05:03] <ubot4> Launchpad bug 583312 in xserver-xorg-input-evdev (Ubuntu) "Left mouse clicks not being processed (affects: 2) (heat: 16)" [Undecided,New] https://launchpad.net/bugs/583312
[05:03] <artfwo> Downgrading to xserver-xorg-input-evdev 1:2.3.2-6build1 solves the problem for me
[05:06] <RAOF> Hm, interesting.
[05:11] <artfwo> I'm almost certain, that the bug is introduced in debian/100-fix-touchup-problem-on-touchpads.patch
[05:12] <artfwo> because it does something with switching absolute/relative axes, and my mouse works with absolute axes, judging by Xorg.0.log
[05:12] <artfwo> but axes have nothing to do with buttons on the other hand, weird
[05:12] <RAOF> Indeed :)
[05:14] <artfwo> while I was experiencing the bug, switching mice actually helped
[05:14] <artfwo> here's what happens, when I plug in the "buggy" mouse http://pastebin.ubuntu.com/487615/
[05:15] <artfwo> and this is Xorg.0.log for "working" mouse http://pastebin.ubuntu.com/487616/
[05:16] <artfwo> anyway, A4tech mouse worked okay without the latest patch
[05:24] <artfwo> I'm thinking of perhaps opening a new bug report for the Maverick behaviour, is it reasonable?
[05:25] <RAOF> Yes, I think so.
[05:26] <RAOF> 20 mouse buttons!!!
[05:27] <artfwo> there are actually only 6 + the wheel :)
[05:28] <RAOF> I wonder if that's actually a kernel problem, then.
[05:29] <RAOF> I guess it shouldn't be, if switching evdev versions fixes it.
[05:31] <artfwo> well, the ubuntu patch could introduce a dependency on "kernel stuff done right"
[05:32] <artfwo> and in turn, triggered a bug, because of a kernel problem
[05:45] <RAOF> Hm.
[05:46] <RAOF> Your A4tech thing is a mouse, not a touchpad, isn't it.
[05:46] <RAOF> And you've only got one of them, right?
[05:47] <artfwo> right
[05:47] <artfwo> but the laptop has built-in touchpad
[05:51] <RAOF> It looks like X thinks both /dev/input/event12 and /dev/input/event13 are the A4Tech thingy.
[05:54] <artfwo> also /dev/input/js1 and dev/input/mouse3
[06:06] <RAOF> js1?
[06:06] <artfwo> js* are the joysticks
[06:06] <RAOF> Ah, right.
[06:07] <RAOF> And you've got one of those plugged in, I presume.
[06:09] <artfwo> no
[06:11] <artfwo> with all the USB stuff unplugged, I still get [ 15360.722] (II) config/udev: Adding input device A4Tech USB Full Speed (/dev/input/js0)
[06:11] <RAOF> Hm.
[06:11] <artfwo> looks like the mouse is detected as mouse, keyboard and joystick simultaneously
[06:12] <RAOF> And with 37 axes, and 20 buttons.
[06:12] <artfwo> but that seems unrelated, because my external USB keyboard also produces lines like [ 15468.588] (II) config/udev: Adding input device Logitech Logitech USB Keyboard (/dev/input/js1)
[06:12] <artfwo> when plugged in
[06:13] <artfwo> and... [ 15468.581] (II) Logitech Logitech USB Keyboard: Found 20 mouse buttons
[06:13] <RAOF> What does “udevadm info --query=all --name=/dev/input/js1” say?
[06:14] <artfwo> RAOF, http://pastebin.ubuntu.com/487633/
[06:15] <RAOF> Your keyboard doesn't happen to have a joystick-like thing on it?
[06:15] <artfwo> only a scrollwheel
[06:16] <artfwo> but the bug above happens without the keyboard, that's for sure
[06:16] <artfwo> *with or without
[06:18] <RAOF> Things just appear weird.
[06:18] <RAOF> Do you have the a4tech device plugged in now?
[06:18] <artfwo> yes, with evdev downgraded
[06:19] <RAOF> What event node is it?
[06:19] <RAOF> And can you grab the udevadm info for it?
[06:20] <artfwo> I can, but for which device - js0?
[06:20] <artfwo> here it is http://pastebin.ubuntu.com/487635/
[06:21] <RAOF> And, just for the record, this is a pure mouse, right?
[06:21] <RAOF> The fact that it's got ID_INPUT_KEYBOARD=1 set is a total lie?
[06:21] <artfwo> I guess so
[06:21] <artfwo> the mouse hasn't any builtin keyboard
[06:22] <artfwo> if I query /dev/input/mouse0 this string goes away
[06:22] <RAOF> Ah.
[06:24] <RAOF> And I'd wager that one of the (many!) /dev/input nodes has ID_INPUT_TOUCHPAD=1 set.
[06:24] <artfwo> /dev/input/mouse2 has it
[06:25] <RAOF> And is the A4tech mouse?
[06:25] <artfwo> no
[06:25] <artfwo> I think it's the builtin touchpad
[06:25] <RAOF> It's your honest-to-goodness touchpad?
[06:25] <artfwo> right
[06:30] <RAOF> None of the patches in evdev look particularly suspicious.
[06:31] <RAOF> This only starts happening after some period of time, yes?
[06:32] <RAOF> Not straight after startup?
[06:32] <artfwo> yes, in an absolutely random, but rather short period
[06:33] <artfwo> I think it's most often triggered by chromium and empathy windows, but also happens in nautilus and gimp
[06:36] <artfwo> the system is absolutely unusable afterwards. it behaves like the left mouse button is down all the time
[06:36] <artfwo> keeps selecting bunches of text, or dragging the windows
[06:36] <artfwo> right & middle continue to work, as well as the wheel
[06:37] <artfwo> I can alt+tab between windows, catch events in xev, etc.
[06:37] <artfwo> unplugging the mouse and clicking left button on the touchpad returns everything to normal
[06:59] <RAOF> artfwo: What architecture are you on?  I'd like to prepare a couple of packages to see which patch is breaking for you.
[07:59] <artfwo> RAOF, x86
[08:00]  * RAOF updates his i386 chroot
[08:12] <RAOF> artfwo: http://cooperteam.net/Packages/xserver-xorg-input-evdev_2.3.2-6ubuntu2~notouchupfix_i386.deb is a first hack at it.
[08:12] <artfwo> RAOF, installing right now
[08:15] <artfwo> RAOF, your package made the bug reappear almost immediately
[08:16] <RAOF> Ok; second one without gesture support.
[08:24] <RAOF> artfwo: http://cooperteam.net/Packages/xserver-xorg-input-evdev_2.3.2-6ubuntu2~nogestures_i386.deb
[08:25] <artfwo> okay, let me restart X...
[08:27] <artfwo> RAOF, it looks like everything's okay now
[13:41] <ScottK> Now I understand why my mini 10v looks like crap on Kubuntu Maverick: http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma-in-kde-workspaces-4-5/
[13:42] <ScottK> Any suggestions on how to usefully file bugs/troubleshoot compositing problems for this?
[13:43] <jcristau> get the kde people to talk to mesa driver devs?
[13:45] <ScottK> Unlikely to provide much relief on the maverick timeline.
[13:45] <jcristau> *shrug*
[13:54] <tseliot> ScottK: I think you can switch to Xrender instead of OpenGL for compositing (as a temporary workaround)
[13:55] <ScottK> tseliot: Thanks.  I'll try that.
[14:07] <Sarvatt> every time I read this guys blog I get the impression he thinks everyone not using nvidia proprietary drivers is doing it wrong :)
[14:09] <Sarvatt> and that its just a matter of getting drivers ready to do opengl 2.0 and not a hardware limitation of hardware thats still shipping today
[14:11] <jcristau> Sarvatt: and that driver bugs get fixed out of thin air, without anybody reporting issues to the devs
[14:11] <Sarvatt> yeah especially that
[14:13] <ScottK> tseliot: Much better.  Thanks.
[14:14] <tseliot> ScottK: np
[14:14] <Sarvatt> ScottK: can ya describe "looks like crap"?
[14:14] <tseliot> no desktop effects
[14:14] <tseliot> and KDE doesn't look extremely good without them
[14:15] <Sarvatt> oh they were just disabled completely? they added all that fallback infrastructure and only made it do GL->off instead of falling back to xrender?
[14:15] <tseliot> yep
[14:15] <ScottK> Sarvatt: Yes and then when I enable them manually the screen suffers from flashes and incomplete rendering.
[14:16] <Sarvatt> ScottK: it would be interesting if you could try this with gl composting - https://edge.launchpad.net/~sarvatt/+archive/mesa
[14:16] <ScottK> Is there anything we can do about getting it to fall back to xrender?  Compositing is pretty essential for the Plasma Netbook interface.
[14:16] <ScottK> Sarvatt: Sure.  That machine is expendable.
[14:26] <ScottK> Sarvatt: That machine had an X crash on logout too (945gme).  Could that be affected by the same issue we tested on 865 yesterday?
[14:26] <Sarvatt> ScottK: yup
[14:28] <Sarvatt> I've been struggling with fixing that patch but haven't had any luck yet, planning on spending all day today on it
[14:35] <Sarvatt> oh joy, the blacklists for broken features in KDE specifically don't include -devel in the mesa version string so that mesa might not work right even if it will once its released. if only we could get an RC here soon :(
[14:38] <Sarvatt> it looks like the only things that work right basically are proprietary drivers, nouveau, i965+ intel if you specifically blacklist blur, r300-r500 ati using gallium only and r600+ ati from mesa git
[14:40] <ScottK> Interesting experience.
[14:40] <ScottK> It seems like things are slower, but much smoother than the current mesa.
[14:40] <Sarvatt> KDE 4.6 is going to be even worse no doubt since it's going opengl 3 that no free drivers implement and backwards compatability isn't planned until 4.7? wow
[14:41] <ScottK> Sigh.
[14:42] <Sarvatt> interesting. I thought opengl compositing didn't work at all in 7.8.2?
[14:43] <ScottK> It was slow enough that I had to disable functionality checks to keep it from disabling effects for being too slow.
[14:43] <ScottK> No flickering though
[14:43] <ScottK> Actually after rebooting, its
[14:43] <Sarvatt> that was with mesa 7.9 that you had to do that?
[14:43] <ScottK> much better.
[14:44] <ScottK> Whatever was in your ppa
[14:45] <ScottK> Actually after rebooting instead of logging out, crashing X, and restarting it's quite snappy
[14:46] <ScottK> Large blurs will still cause it to suspend effects, but other than that, works reasonably well.
[14:47] <Sarvatt> what I have in that PPA is what we have in git and are going to try to file a FFe to get into maverick, it fixes quite a lot of bugs. it's due out in final release form by the end of september (and I'm very confident it will hit release on time) but there isn't a release candidate yet :(
[14:47] <Sarvatt> ScottK: that should be fixed once there is a release candidate of it so the version string doesn't say -devel, it's not applying the blacklist to fix blur because of that from what I'm reading
[14:48] <ScottK> OK.  That's cool.
[14:48] <ScottK> Feel free to mention Bug #628930 in your FFe request.
[14:48] <ubot4> Launchpad bug 628930 in kdebase-workspace (Ubuntu Maverick) (and 1 other project) "Desktop effects not active by default (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/628930
[14:49] <Sarvatt> ScottK: thanks, I was just going to ask if you knew of any bugs
[14:49] <Sarvatt> RAOF: ^
[15:13] <ScottK> Sarvatt: With just blur disabled and your new mesa the system works well again.  I think on the Kubuntu end of things we will pursue disabling just blur by default on netbooks (netbooks will ~all be affected by this).  That and your planned mesa update should get us into a releasable state.
[15:16] <Sarvatt> ScottK: thats a good idea in general, the blur only works properly on proprietary drivers apparently and that guy didn't want to disable that feature globally because he thinks the majority of people use those where it works :)
[15:17] <ScottK> There was about a week where it worked on intel.
[15:18] <Sarvatt> 965+ or your 945?
[15:18] <ScottK> 945
[15:18] <ScottK> He changed something between KDE 4.5 RC and final that killed it.
[15:19] <ScottK> I marked that bug to also affect mesa, FYI, so you have something to fix too.
[15:19] <Sarvatt> it's glsl only so I can't see how it ever worked on 945, hmm
[15:20] <ScottK> Dunno.  I sometimes have low standards for 'worked' when running the development release.
[15:26] <Sarvatt> wow, there are an amazing amount of INTEL_DEBUG env variables in mesa
[16:47] <Sarvatt> RAOF: oh sheesh, it's X: ../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. breaking sandybridge, didn't we have this problem before?
[16:48] <Sarvatt> oh hmm, i'm on the 31st iteration of screwing with 101_copy-fb.patch, best check with stock before I say that :)
[17:18] <ScottK> Sarvatt: mgraesslin says opengl 3 in KDE 4.7 and they aren't dropping any backward compatibility stuff in 4.6.
[17:32] <seb128> bryceh, hi there
[17:32] <seb128> bryceh, http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html
[17:32] <seb128> do you have an updated version of that?
[17:35] <Sarvatt> seb128: http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
[17:35] <bryceh> yeah sorry, I need to get rid of that old link
[17:36] <bryceh> Sarvatt, sorry I've not yet fixed up that graph...  totally forgot, been mesmerized by launchpad->bugzilla work
[17:37] <Sarvatt> bryceh: no worries at all man! it's not important or anything
[17:48] <ScottK> Sarvatt: Would you please have a look at http://blog.martin-graesslin.com/blog/2010/07/blacklisting-drivers-for-some-kwin-effects/ and give me a hand figuring out how to describe i945gme to blacklist the blur effect?
[17:59] <bjsnider> Sarvatt, will there be nouveau gallium3d in maverick?
[17:59] <Sarvatt> ScottK: can you blacklist wildcards? :) I bet he doesn't want that
[17:59] <Sarvatt> bjsnider: it is already, libgl1-mesa-dri-experimental
[18:00] <ScottK> Sarvatt: No idea.  I'd like to at least get mini 10v blacklisted properly.
[18:02] <Sarvatt> ugh, really stinks that its so strict, you can break it just using driconf that way :(
[18:03] <Sarvatt> ScottK: you get it from the OpenGL renderer: line of the glxinfo output
[18:05] <Sarvatt> i dont have 7.8.2 installed at the moment to give you an exact one
[18:05] <ScottK> Of course I don't either ....
[18:05]  * ScottK will revert first.
[18:06] <Sarvatt> oh there's a comment in the blog - grep KWin::CompositingPrefs::detectDriverAndVersion ~/.xsession-errors
[18:06] <Sarvatt> the GL renderer and GL version strings
[18:07] <Sarvatt> sudo ppa-purge -p mesa sarvatt will do it
[18:07] <Sarvatt> dont have to reboot to get the info
[18:10] <ScottK> OK.  Back in a few.  Now distracted by another task.
[18:10] <apparle> are video memory and gart size or different?
[18:10] <Sarvatt> [Blacklist][Blur]
[18:10] <Sarvatt> Intel=Mesa DRI Intel(R) 945GME GEM 20100328 2010Q1:-:1.4 Mesa 7.8.2
[18:10] <Sarvatt> [Blacklist][Lanczos]
[18:10] <Sarvatt> Intel=Mesa DRI Intel(R) 945GME GEM 20100328 2010Q1:-:1.4 Mesa 7.8.2
[18:11] <apparle> how to check what is my current video memory size (on board GPU)?
[18:55] <Sarvatt> ScottK: this is absolutely frigging ridiculous but here you go - http://sarvatt.com/downloads/kdeblacklist.txt
[18:55] <Sarvatt> thats *just* intel and *just* mesa 7.8.2
[18:55] <ScottK> Sarvatt: Thanks.
[18:56] <Sarvatt> GM45 is a weird one and affected by locale..
[18:56] <Sarvatt> Intel=Mesa DRI Mobile IntelÂ® GM45 Express Chipset GEM 20100328 2010Q1 x86/MMX/SSE2:-:2.1 Mesa 7.8.2 is what it should look like
[18:56] <Sarvatt> plus you have to duplicate every renderer string for every arch
[18:56] <Sarvatt> since it doesnt show x86/MMX/SSE2 on x64
[18:58] <Sarvatt> I dont think it'd be wrong at all to just disable it globally and let people enable it themselves if they want it even if upstream doesn't want that, just my opinion though
[18:58] <ScottK> I was about to ask about that.
[19:01] <Sarvatt> that way is so fragile, i can get 3 different opengl versions reported on 945GME by changing driconf values
[19:05] <ScottK> Next time I see him online, I'll ask him about it.
[19:51] <ScottK> Sarvatt: What's the correct ppa-purge incantation for your mesa ppa?
[19:51]  * ScottK has never used it before
[19:51] <Sarvatt> sudo ppa-purge -p mesa sarvatt
[19:51] <ScottK> Thanks
[19:52] <Sarvatt> or sudo ppa-purge ppa:sarvatt/mesa
[19:52] <Sarvatt> tormod added the ppa: handling, I forget its there
[20:02] <Sarvatt> RAOF: I really am drawing blanks here about this 101_copy-fb.patch. What do you think about just disabling it in the interim until we can get it fixed up? ScottK has confirmed it's screwing up server regeneration on other chipsets as well as it is now. (bug #628077)
[20:02] <ubot4> Launchpad bug 628077 in xserver-xorg-video-intel (Ubuntu) "[i865] Crash on logout with KDM (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/628077
[20:04] <ScottK> Sarvatt: I asked mgraesslin to join us to discuss the blacklist.
[20:05] <ScottK> Hello mgraesslin.
[20:05] <ScottK> Sarvatt is the one that proposed that blacklist based on our testing and your blog post.
[20:05] <ScottK> Sarvatt: mgraesslin says he doesnt think it needs to be so extensive.
[20:05] <Sarvatt> Heyo! I'm really not the right person to discuss it with, the people in#dri-devel would be much more knowledgeable about it :)
[20:06] <mgraesslin> yeah the blog post is unfortunately incomplete
[20:06] <mgraesslin> e.g. Intel=20100328 2010Q1:-:7.8.2 will work, too
[20:06] <Sarvatt> ScottK: I just added every intel string from mesa to the list for future reference, wasn't suggesting using all of that
[20:06] <ScottK> Sarvatt: OK.
[20:06] <mgraesslin> and there is only one line per driver - the different versions are comma separated
[20:07] <mgraesslin> now that I have such a list I can prepare an inclusion upstream
[20:07] <ScottK> Sarvatt: I'm stuck needing to produce a patch and not knowing enough.  Upstreams sort it out eventually doesn't work on the release timeline.
[20:07]  * Sarvatt nods
[20:08] <ScottK> Which is why I invited mgraesslin here so you two can tell me what I need to get done.
[20:08] <mgraesslin> btw: there are Intel drivers which work, so blacklisting just all, is wrong as well as it gives no possibility to the user to disable it
[20:09] <Sarvatt> someone would need to go through all the KDE bugs and find out what's broken and pick and choose from there, but there's only 3 or 4 generations out of all of those so if someone is broken on one it's safe to assume the others of that generation are broken too
[20:10] <ScottK> mgraesslin: Part of the problem I have is that plasma-netbook makes large assumptions that compositing will be available, so if it's not, the user experience is really unfortunate.  So I need to be rather conservative in where the more aggressive options are enabled.
[20:10] <Sarvatt> aka if 945GME is broken like ScottK says it is all of the opengl 1.4 ones should need blacklisting
[20:10] <Sarvatt> well maybe not the 8xx series ones but those are broken in everything else anyway :)
[20:10] <mgraesslin> opengl 1.4 does not need blacklisting as the effects require GLSL - that is 2.0
[20:11] <mgraesslin> ScottK: at least in 4.5.0 we had a problem that kwin's selfcheck failed on intel hardware
[20:11] <mgraesslin> it might be resolved in 4.5.1 but I am not sure
[20:11] <ScottK> OK.  I just updated my netbook to 4.5.1.  I'll check it.
[20:11] <mgraesslin> so you might want to disable kwin's functionality checks by default
[20:12] <ScottK> We'll ship with 4.5.1 +patches this cycle so maybe it's OK.
[20:13] <mgraesslin> problem is, that I have access to one Intel based device and there all issues are not reproducable
[20:14] <mgraesslin> selfcheck works, kwin does not freeze on settings change and blur is fast
[20:19] <ScottK> My results seem to be inconsistent.
[20:20] <ScottK> What does the device you have access to have?
[20:20] <ScottK> mgraesslin: ^^
[20:21] <mgraesslin> erm no idea to be honest
[20:25] <ScottK> OK.
[22:17] <bjsnider> Sarvatt, any ideas on this: http://pastebin.ca/1931994
[22:18] <Sarvatt> he booted an old kernel
[22:18] <bjsnider> no, he proved that's not so
[22:19] <Sarvatt> oh 256.53? he hasn't rebooted since updating then
[22:19] <bjsnider> i think this may be a flea power issue, where it's just stuck in memory
[22:19] <bjsnider> he did reboot
[22:19] <Sarvatt> don't know what to tell ya, 256.53 isn't installed for the kernel he's on obviously
[22:20] <Sarvatt> did he update to 2.6.35-20 in the same update?
[22:20] <bjsnider> no, -19
[22:21] <Sarvatt> what's his dkms status say?
[22:23] <bjsnider> it works now after another reboot
[22:23] <bjsnider> so it was a module staying in the ram even through a reboot or two
[22:35] <Sarvatt>  - Next week create a 7.9 release branch.
[22:35] <Sarvatt> \o/
[22:55] <achiang> does anyone know what happened to xserver-xorg-input-keyboard / kbd in lucid? did the package just go away?
[22:57] <jcristau> looks that way.
[22:58] <achiang> what happened to the code it used to contain? :)
[22:58] <achiang> perhaps now in xserver-xorg-input-evdev?
[22:58] <jcristau> the code is still in xf86-input-kbd, it's just not useful on linux because evdev replaces it
[22:59] <achiang> ah, ok, thanks
[23:03] <vish> how do i identify the chipset of an intel card?
[23:03] <jcristau> lspci -s 0:2.0
[23:05] <vish> so from http://launchpadlibrarian.net/54896374/Lspci.txt , it would be 945GME  ?
[23:06] <kklimonda> how does 10.04 cope with computers with 2 graphic cards?
[23:09] <vish> yup, [i945gme] seems it , found another bug about AAO with same title.. 
[23:14] <Sarvatt> thats the same machine i've used primarily for 2 years now :)
[23:15] <vish> Sarvatt: oh! the one i pasted above?
[23:15] <Sarvatt> vish: do you have one? the bios is extremely hackable to enable stuff like ahci, nx, more backlight levels, etc
[23:15] <Sarvatt> yeah
[23:16] <vish> hmm, havent hacked around the bios yet..
[23:16] <Sarvatt> it could be a different one, mine's an old AOA150
[23:16] <vish> Sarvatt: thats the one you've got unity running?
[23:17] <Sarvatt> i don't use that but it does work with CLUTTER_VBLANK=none
[23:17] <vish> ah , but unity works normally, only crashes X at times ;) 
[23:17] <vish> Bug 629814
[23:17] <ubot4> Launchpad bug 629814 in xserver-xorg-video-intel (Ubuntu) "[i945gme] Moving pointer over Unity's launcher crashes X and causes Unity to reload (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/629814
[23:18]  * vish tries with vblank..
[23:18] <Sarvatt> vish: different problem
[23:19] <vish> k.. :)
[23:19] <Sarvatt> vish: try this for me? https://launchpad.net/~sarvatt/+archive/sarvatt-graphics
[23:20] <vish> Sarvatt: for the intel  AAO , or   ATI ? 
[23:20] <Sarvatt> AAO
[23:20] <Sarvatt> it's just xserver-xorg-video-intel in there
[23:20] <vish> sure.. 
[23:20] <vish> yeah , just now saw the link! :D
[23:26] <Sarvatt> i think i'm going to hit the liquor store if that works. that patch makes me want some booze.
[23:30] <Sarvatt> well, it's the backtrace in your gdmlog2 that I'm thinking it'll fix, I didn't read the description :D
[23:31] <Sarvatt> did you log out when those server crashes happened?
[23:31] <vish> nope..
[23:31] <vish> only once, since my network manager crashed..
[23:32] <Sarvatt> is the xorglogold from a shutdown?
[23:32] <vish> hmm , might be.. i'm running unity from persistant usb stick on that one..
[23:33] <vish> oh, ho , somethign is eating my / !  running out of space on my laptop! , so if i crash out. :/
[23:35] <Sarvatt> vish: how many backlight levels do you have?
[23:36] <Sarvatt> on the AOA150
[23:36] <Sarvatt> if its not 9 check this out - http://macles.blogspot.com/2009/03/brightness-table.html
[23:37] <Sarvatt> (ignore the comments cus I fixed that in udev a long time ago)
[23:37] <vish> just a sec.. my backup , created its own folder in /media and started filling up my / :(
[23:38] <Sarvatt> I get an extra hour battery life with that new bios, there are 9 cell batteries you can pick up on ebay that last about 11 hours too :)
[23:38] <Sarvatt> for $30 or so
[23:41] <vish> wow! 11hrs of battery life! :)
[23:42] <vish> hmm , looks like i have 9 steps :s
[23:42] <Sarvatt> ah, not surprised, only the early AOA150's had the problem that made them not allow the lower levels
[23:44] <Sarvatt> http://cgi.ebay.com/New-ACER-Aspire-One-9-cell-7900mAh-battery-A110-AOA150-/200489675229?pt=Laptop_Batteries&hash=item2eae1da9dd#ht_1540wt_902
[23:44] <vish> hmm , well , the ppa works.. but doesnt solve the bug i mentioned above :)
[23:44] <Sarvatt> those things are about 10-11 hours, they make 12 cells too
[23:44] <Sarvatt> yeah, sorry about that, your logs exposed another bug that you probably dont notice cus it happens when you reboot :)
[23:45] <vish> np.. :)
[23:46] <Sarvatt> grep -r FreeClientResources /var/log/Xorg.* shouldn't return anything new anymore with that though 
[23:46] <Sarvatt> are you running a unity session or just running unity?
[23:47] <vish> unity regular! :D
[23:47] <Sarvatt> from what you said in the bug though X isn't crashing just unity?
[23:48] <Sarvatt> those X crashes are another bug?
[23:48] <vish> yeah , i dont get logged out of the session.. but only Unity is reloaded.. so might be two happening at the same time?
[23:49] <Sarvatt> yeah you'd know it if those X crashes in your log were related to unity reloading, the whole session would go down
[23:49] <vish> grep -r FreeClientResources /var/log/Xorg.*  gives an output only in the 0.log.old..
[23:49] <Sarvatt> vish: next reboot it shouldn't be in .old either
[23:50] <vish> cool!
[23:50] <Sarvatt> any chance you could confirm that so I can chalk it up as another bug caused by 101_copy-fb.patch in xserver-xorg-video-intel? :)
[23:51] <vish> yup , rebooting it :)
[23:51] <Sarvatt> thanks!
[23:54] <vish> Sarvatt: poof! gone :) , nil output for $ grep -r FreeClientResources /var/log/Xorg.* 
[23:54] <Sarvatt> thanks vish
[23:54] <vish> np..
[23:54] <Sarvatt> yours is identical to ScottK's then, ugh
[23:55] <Sarvatt> pretty safe to say all intel bugs on maverick with this backtrace are the same
[23:55] <Sarvatt> Backtrace:
[23:55] <Sarvatt> 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e83bb]
[23:55] <Sarvatt> 1: /usr/bin/X (0x8048000+0x5da8d) [0x80a5a8d]
[23:55] <Sarvatt> 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xa9640c]
[23:55] <Sarvatt> 3: /usr/bin/X (FreeClientResources+0xed) [0x808f04d]
[23:55] <Sarvatt> 4: /usr/bin/X (FreeAllResources+0x60) [0x808f120]
[23:55] <Sarvatt> 5: /usr/bin/X (0x8048000+0x1a5e6) [0x80625e6]
[23:55] <Sarvatt> 6: /lib/libc.so.6 (__libc_start_main+0xe7) [0x2a5ce7]
[23:55] <Sarvatt> 7: /usr/bin/X (0x8048000+0x1a191) [0x8062191]
[23:55] <Sarvatt> Segmentation fault at address 0x4
[23:58] <Sarvatt> I really think it would be a good idea to disable 101_copy-fb.patch until it can get worked out