[01:50] <Sarvatt> chrisccoulson: we actually have newer ia32-libs in xorg-edgers that pull in all of the components at build time if you just need to test some gtk stuff in it
[01:51] <Sarvatt> gotta update that in there to make wine not suck with mesa :(
[01:55] <ScottK> Sarvatt and RAOF: Is there other stuff you guys need sponsored before RC?
[01:56] <RAOF> ScottK: I don't have anything queued up, but I suspect sarvatt might want an xserver-xorg-video-intel upload?
[01:56] <Sarvatt> ScottK: not that I'm aware of, the mesa release guy is in vegas at the moment..
[01:57] <ScottK> OK.  Considering the mesa revert was sitting there waiting, I thought I'd check.
[01:57] <ScottK> Thing have gone from totally unpleasant to good with a few warts for me now and I wanted to make sure there wasn't more stuff waiting to make it even better.
[01:58] <RAOF> Heh.
[01:58] <RAOF> The 7.9 release may fix more stuff but hasn't happened yet :)
[01:58] <RAOF> At least there's now a release branch, though.
[01:59] <RAOF> Hm.  This bug has a 26MiB Xorg.0.log.old attached.  I wonder what causes that?
[01:59] <RAOF> Aaaaah.  Stupid fbdev.
[01:59] <Sarvatt> that copyfb patch still needs fixing, I'm really stumped on it and am really swamped with 3 new machines to make work
[02:00] <RAOF> Didn't you just prevent that patch from activating on gen 6?
[02:00] <Sarvatt> yeah but its broken on all other intels at the moment..
[02:00] <RAOF> …?
[02:01] <RAOF> Is there some reason why my GM45 isn't affected, then?
[02:01] <Sarvatt> have you made it hang or logged out of KDE lately? :)
[02:01] <RAOF> Oh, _that_ :)
[02:01] <Sarvatt> it doesnt look like its actually hurting anything, just spewing a backtrace in the  log
[02:02] <RAOF> Right.
[02:02] <RAOF> Whereas not briging up X on sandybridge is a somewhat more important bug!
[02:06] <Sarvatt> blacklisting in compiz was a silly move, should have blacklisted i965_dri.so from the start but intel insists its going to be in a usable state for the Q3 release (7.9..)
[02:06] <Sarvatt> i think theres a big disconnect between the people I talk to and the people actually working on mesa :D
[02:06] <RAOF> :)
[02:14] <ScottK> Sarvatt or RAOF: If there's a release branch for 7.9 now, might it make sense to consider a snapshot update?  I'd be glad to help test it.
[02:15] <RAOF> Sarvatt's just told me that it fixes a trivially reproducible intel GPU hang, so I'll certainly look at it now.
[02:15] <Sarvatt> yeah it would, we were just discussing it actually
[02:16] <ScottK> OK.  Let me know when there's a package to test.
[02:17] <RAOF> Mesa would be so much less scary if there weren't hundreds of commits in the order of a couple of days.
[02:17] <RAOF> Damn those GPUs and their insane complexity :)
[02:19] <ScottK> As long as RAOF makes sure he's not running a patched clutter this time, I think we can test it out fine.
[02:19] <Sarvatt> hoping http://lists.freedesktop.org/archives/mesa-dev/2010-September/003183.html gets picked up but i'm not holding my breath, going to blacklist these GPU's from i965 anyway
[02:20] <ScottK> ;-)
[02:20] <RAOF> :`(
[02:20] <ScottK> Hey, stuff happens.  The story had a happy ending.
[02:20] <RAOF> Sorry about that - I should have documented that on the FFe bug and/or tracked the sponsorship request more.
[02:21] <Sarvatt> hey, at least it was an interesting day :)
[02:23] <Sarvatt> btw ScottK, what I feared looked to be true with that mesa patch for the KDE problem, horrible memory leaks :(
[02:23] <RAOF> How did you get that to apply to -0ubuntu3?
[02:23] <ScottK> Sarvatt: It's all about peeling the onion.
[02:23] <RAOF> The code it was patching disappeared.
[02:24] <Sarvatt> I didn't, someone else reported it on the bug
[02:26] <RAOF> And just for completeness, that bug *definitely* appears on -0ubuntu3, right?  I can't get it to hang locally - it just crashes :)
[02:26] <ScottK> RAOF: I can get it to hang.
[02:26] <RAOF> Ok.
[02:26] <RAOF> Again, my hardware is magical.
[02:26] <Sarvatt> screwing with drawable destruction voodoo is how we had that big memory leak at the last minute from that patch I added, anything touching that scares me now :)
[02:26] <ScottK> Or mine is, but in a bad way.
[02:27] <Sarvatt> err big memory leak in xserver on lucid at the last minute
[02:27] <RAOF> Yeah.  Problems in drawable destruction can lead to fun unreported memory leaks!
[02:27] <ScottK> RAOF: Mine is a Dell mini 10v, so it's stuffed with the cheapest they could find of whatever it absolutely had to have.  I'm not surprised it sucks in special ways.
[02:28] <ScottK> I'll have to try on some other hardware too.
[02:28] <RAOF> If it didn't mean rebooting my IRC server I'd try on my 945 netbook, too.
[02:28] <Sarvatt> so yeah, I reenabled vblank in mesa and it's still broken over a year later, I hope more netbooks aren't hitting this problem
[02:28] <RAOF> (Stupid “switchable” graphics that hides the device from the PCI bus entirely)
[02:29] <Sarvatt> all aspire one AOA1xx's are at least
[02:29] <RAOF> Sarvatt: by vblank do you mean flipping support?
[02:29] <Sarvatt> interrupts are screwed, if i run glxgears and dont move the mouse for instance it drops down to around 17fps
[02:29] <RAOF> Oh.  _That_
[02:30] <RAOF> There were drm patches for that, I thought?
[02:30] <Sarvatt> nope, still busted, someone just brought it up again on the intel-gfx list and i've  been trying the patches jbarnes is posting but no luck
[02:30] <Sarvatt> it makes for one horrible experience with unity and such though
[02:31] <RAOF> Do we have vblank disabled on those machines?
[02:31] <Sarvatt> its enabled in mesa unconditionally for dri2 on radeon and intel
[02:32] <RAOF> And we don't have a nice list of broken pciids/dmi data to blacklist it off in a patch?
[02:33] <Sarvatt> nope, that was the dri1 version back in intrepid or jaunty I think?
[02:33] <RAOF> Maybe we should do that.  Screen updates only when moving the mouse aren't my idea of a nice user experience :)
[02:38] <bryceh> Sarvatt, I finally fixed that broken graph.  It took 30 sec, I don't know why I bothered being so damn lazy about updating it, sorry.  http://localhost/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
[02:38] <bryceh> problem was just that the total had exceeded the bounds of the graph.
[02:38] <Sarvatt> hah!
[02:38] <bryceh> *sigh* and I could give the RIGHT link
[02:38] <Sarvatt> I can't even count the number of times I've done the same thing :)
[02:38]  * RAOF needs to learn more nouveau driver internals.  Or, alternatively, nouveau needs to grow some mortal-readable error messages.  “EvoCh 0 Mthd 0x0080 Data 0x00000000 (0x0005 0x05)” is not friendly.
[02:39] <Sarvatt> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick.svg a wrong link?
[02:39] <bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
[02:39] <Sarvatt> oh workqueue works, woot
[02:40] <Sarvatt> thanks bryceh!
[02:40] <bryceh> fixing the other too...
[02:40] <RAOF> Hello, intel!
[02:40] <Sarvatt> i've really been focusing on major specific bugs instead of mass bug work, those graphs are always depressing
[02:41] <bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick.svg
[02:41] <bryceh> Sarvatt, yeah I know
[02:41] <RAOF> Totals-maverick looks moderately broken.
[02:41] <bryceh> shift-reload
[02:41] <RAOF> Except for the part where we've got a big bunch of intel bugs, of course.
[02:41] <Sarvatt> at least I see a few jumps in intel where i found mass dupes of what i was working on there :D
[02:42] <Sarvatt> theres a crapload of apport crash bugs on intel
[02:42] <RAOF> That's true.
[02:42] <bryceh> intel always has a fair share, but this looks a bit anomolous that half of the bugs reported in maverick were against -intel... what's going on?
[02:42] <Sarvatt> apport hook being enabled at the start :)
[02:43] <bryceh> oh apport hmm
[02:43] <RAOF> The one with the best debugging tools gets the most reports.
[02:43] <RAOF> We didn't turn it off this time.
[02:45] <bryceh> are they valid crash/freeze captures?
[02:46] <RAOF> By and large, yes.
[02:46] <Sarvatt> i can't keep up with them, there are so many dupes but they take quite a long time to fully review unless I know specifically what the crash I'm looking for looks like (which happens a lot and they are very useful to have in that case)
[02:46] <bryceh> Sarvatt, yeah I've been sort of pondering giving up on mass bug management and just focus on specific priority bugs myself.  That's basically how I've been working on launchpad (which also has quite a few bug reports).  But I dunno
[02:47] <bryceh> mass bug management takes a considerable chunk of time, even with automation
[02:48] <bryceh> Sarvatt, don't you just want to say "SHUTUPSHUTUPSHUTUP!!!" ?  ;-)
[02:48] <RAOF> And generally doesn't produce a lot of value for us (at least, I'm not sufficiently efficient at manipulating launchpad to make it a positive time investment)
[02:49] <bryceh> I felt like I was able to squeeze value out of it, but mostly because of sending bug reports upstream
[02:49] <bryceh> and then cherrypicking the patches back
[02:49] <RAOF> Right.  That's something you're much better at than I am :)
[02:50] <RAOF> (still)
[02:50] <bryceh> yeah it tends to be kinda tedious work (hopefully my current work will be mitigating that some)
[02:52] <bryceh> I suppose with these graphs, the important thing is not so much the magnitudes but rather the slope
[02:53] <RAOF> Yeah.
[02:54] <RAOF> They're not a perfect metric, but the slope is the important one.
[02:54] <Sarvatt> someone went through and duped the huge amount of fglrx doesn't work in maverick bugs I see (thanks whoever that was!)
[02:56] <bryceh> yeah I've been surprised by the number of questions about fgrlx-vs-ati lately
[02:57] <bryceh> oh hey while you're both here... I fielded a question earlier today about whether fglrx+randr supports multi-card setups for >2 heads, or if it's limited to a single card like other drivers
[02:57] <bryceh> I figured it was probably 1-card, do either of you know differently?
[02:58] <RAOF> I don't know differently.  Offhand, I'd *suspect* that it would actually handle multi-card reasonably; it's the sort of thing that workstations with 3+ monitors would want.
[02:58] <RAOF> And given fglrx is targetted at workstations… :)
[02:58] <bryceh> also, I recall someone (airlied? ajax?) was working on multi-card support for -ati... but a few minutes googling didn't turn up any recent news on that front; know if there was any progress?
[02:59] <Sarvatt> 99% positive it does with evergreen at least, lemme see if I can dig anything up
[02:59] <Sarvatt> phoronix forums are actually really useful for wacky questions like that
[02:59] <RAOF> I think it should currently work, modulo strangeness.
[02:59] <RAOF> (Like having to pay the Xinerama tax)
[03:00] <Sarvatt> pretty sure I saw them getting >2 displays on a single evergreen card up a few weeks ago on #radeon
[03:00] <RAOF> Oh, that.
[03:00] <RAOF> That's Eyefinity, which works, yeah.
[03:01] <RAOF> As long as you've got DP outputs, apparently :)
[03:01] <Sarvatt> I have a hunch bryce is asking because he's looking to buy and might be able to accomplish what he wants with 1 card is why I mentioned it :D
[03:01] <RAOF> Aaah.  Yeah.
[03:01] <Sarvatt> oh yeah, whoops!
[03:01] <RAOF> 1 card + DP monitors or active DP→DVI connectors.
[03:01] <bryceh> yeah the config in question was an RV250 + RV710
[03:02] <RAOF> I *think* that's expected to work now, modulo requiring Xinerama (and hence disabling Composite).
[03:02] <bryceh> Sarvatt, no, actually it was via a canonical support customer question
[03:03] <bryceh> DP == DisplayPort?
[03:03] <RAOF> There was some brief discussion of Shatter at XDS; per-crtc pixmaps and such have landed already.
[03:03] <RAOF> Yeah.
[03:04] <RAOF> The one where adding an ‘e’ means “Doesn't work properly on Intel” :)
[03:05] <Sarvatt> that's a rough question because its most likely broken by different driver releases if it even does work knowing fglrx..
[03:05] <RAOF> Is there a release of fglrx supporting both RV250 and RV710?  I'd guess not.
[03:06] <RAOF> As I say, I believe it's expected to work with Xinerama, but you'll lose Composite & compiz and suchlike.
[03:08] <Sarvatt> wow, I think it's time to turn the brain off for the night here because it's obviously not working :) night guys
[03:08]  * Sarvatt fires up some minecraft!
[03:10] <RAOF> Civ V!
[03:10] <Sarvatt> MoM!
[03:12] <Sarvatt> never played civ 5, not a huge civilization fan but I loved master of magic and alpha centauri :)
[03:12] <RAOF> I've got Civ 5 wending it's merry way to me now.
[03:12] <bryceh> you'll have to tell me if it's good
[03:13] <RAOF> I most assuredly shall :)
[03:13] <bryceh> I looked at the screenshots but it looked awfully cluttery.  But then I'm not into eyecandy in video games so much ;-)
[03:14] <Sarvatt> yeah civ games always came off cluttery to me too, kinda like KDE
[03:14]  * Sarvatt hides
[03:14] <RAOF> Gerald the mesa build says: Time to make some coffee, sucker!  I'll be here all day!
[03:15] <Sarvatt> hmm wonder if that will run on sandybridge graphics, i have a distinct lack of working dedicated GPU's at the moment
[03:15] <Sarvatt> FFXIV sure as heck wont and it has similar requirements
[03:16] <Sarvatt> oh wow, looks nice
[03:17] <RAOF> Min spec suggests that my laptop's 7600 GT should do OK.
[03:17] <RAOF> And I get to test out whether r600g supports enough GL now to run it on a 4xxx!
[03:18] <Sarvatt> but but didn't it just get gears again a few days ago?
[03:18] <RAOF> Maybe?
[03:18] <Sarvatt> oh wait its mesa, a few days is a few thousand commits
[03:19] <RAOF> Yeah.
[03:19] <bryceh> heh
[04:09] <RAOF> ScottK: Oh, you were on i386 for your mesa, weren't yoU?
[04:10] <ScottK> RAOF: I was and am.
[04:10]  * RAOF fires up a i386 schroot, then.
[04:28] <Sarvatt> was going to say there's one on the VPS but had to delete it earlier to make room for a kernel build, which i couldn't make enough room for out of the 10GB.. :)
[04:28] <RAOF> :)
[04:31] <Sarvatt> did you already package it up then? dont want to step on your toes yet again in git :)
[04:31] <RAOF> Got the packages built, yeah.
[04:31] <RAOF> There's some cleaning up that still needs doing.
[04:32] <RAOF> And, obviously, actually testing it!
[04:34] <Sarvatt> i've been updating 7.9 branch packages daily just in case some obvious nasty bug creeps in, the egl kms/drm change was the only thing major i've noticed
[04:34] <RAOF> Yeah.  That's done.
[04:35] <RAOF> Hm.  I should have fired off this build in screen so I could spend some quality time crashing KWin on the new mesa.
[04:43] <RAOF> Sarvatt: Why are you versioning xorg-edgers packages as 7.10+git, by the way?  It should be 7.10~git :/
[04:44] <Sarvatt> not enough time to pay much attention to it + automated script that uploaded a + :(
[04:44] <RAOF> Eh; sok.
[04:45] <Sarvatt> i really need to fix that so it does a ~ if there's a version bump
[04:45] <RAOF> You'll need to ppa-purge regardless; it's not like upgrading from xorg-edgers is anything but explicitly disowed.
[04:48] <Sarvatt> I prefer that way of thinking regarding it :) there are some pretty drastic differences in there at some points, upgrading to a newer synaptics version in ubuntu with an older abi is a PITA
[04:48] <Sarvatt> like they dont bump the version in master for a few things and the stable branches have a higher version
[04:49] <RAOF> Sweetness.
[05:05] <ScottK> RAOF: Here's an odd one for you on this kwin settings thing: On my Dell mini 10v - change kwin settings and system freezes, reboot into a live session and try the same thing and it doesn't freeze, I get the kwin crash.
[05:05] <ScottK> Both are up to date maverick.
[06:04] <RAOF> ScottK: Because consistency in bugs is too easy!
[06:04] <ScottK> OK.
[06:04] <RAOF> ScottK: i386 packages up at http://cooperteam.net/Packages/
[06:05] <ScottK> Looking.
[06:05] <RAOF> (Again, you're after libgl1-mesa-{glx,dri})
[06:05] <ScottK> Just what I was typing a question about ....
[06:12] <ScottK> So far it didn't cause a fire.
[06:19] <ScottK> RAOF: My initial impressions are things seem subjectively slightly faster.  No new bugs immediately obvious.  Both the freeze on kwin setting change and the X crash on logout are still there (as one would expect).
[06:19] <ScottK> I'll try it on some other systems tomorrow.  It's well into very late here, so I need to get to sleep.
[06:26] <RAOF> Go for it!
[06:28] <RAOF> Heh.  The kwin crash is 177 stack frames deep.
[06:29] <ScottK> mgraesslin is coming to UDS, so you can get even there.
[11:21] <RAOF> Garh.  How have I killed kwin desktop effects?
[11:28] <tseliot> RAOF: with what driver?
[11:29] <RAOF> Intel.
[11:29] <tseliot> hmm...
[11:30] <RAOF> But I'm not entirely sure what I've done - they were working, then I applied the interesting parts of the patch on bug #628077 to the DDX, then everything broke.
[11:30] <ubot4> Launchpad bug 628077 in xserver-xorg-video-intel (Ubuntu Maverick) (and 1 other project) "[i865] Crash on logout with KDM (affects: 1) (heat: 169)" [High,Confirmed] https://launchpad.net/bugs/628077
[11:30] <RAOF> …but dropping back to the archive DDX hasn't fixed it.
[11:31] <RAOF> Hm.  I also enabled some debug in libdrm.  Let's see if that's it.
[11:32] <tseliot> RAOF: that's weird, I think kwin only checks the availability of certain extensions
[11:32] <RAOF> Yeah.
[11:33] <RAOF> The “disable functionality tests” checkbox doesn't do anything interesting, either.
[11:34] <tseliot> yes, I've noticed that
[11:34] <RAOF> Heh.
[11:34] <RAOF> I wonder if it's actually hooked up to anything, like that ‘save the session’ button gnome-session had at one point. :)
[11:34] <tseliot> RAOF: are you sure the cause is not some update of kdebase-workspace?
[11:35] <tseliot> ScottK: ^^
[11:35] <RAOF> I don't think so.
[11:37] <ScottK> tseliot: Sarvatt pretty well narrowed it down to something to do with that patch.  At one point he produces packages that didn't crash (they had other problems, so weren't directly suitable) and so it's pretty clearly in Ubuntu's X stack.
[11:38] <RAOF> ScottK: Did he find that it broke kwin?
[11:38] <ScottK> The patches he had me test did not, as I recall, but that was a while ago when we hat the old mesa, so things were pretty rough overall.
[11:39] <RAOF> I know what the interesting bit of that “applies to git” patch; it's mostly the FreeScratchPixmap.
[11:39] <RAOF> That fixes it.
[11:41] <ScottK> That sounds like good news.
[11:41] <tseliot> ah
[11:42] <RAOF> ScottK: With the small downside that it seems to break kwin for no obvious reason ;)
[11:43] <ScottK> Right.
[11:43] <ScottK> That would be a problem.
[11:44]  * RAOF does a bit of a restart dance.
[12:04] <RAOF> Ok.  Back to all stock Ubuntu packges, and kwin still refuses to enable GL effects.
[12:04] <RAOF> ScottK: Is there any knob to twiddle to make kwin work again?
[12:04] <ScottK> RAOF: It's got a safety valve where if you crash kwin too many times, it sets itself off for good.
[12:05] <ScottK> There will be some thing in ~/.kde/share/config/kwinsomething (probably kwinrc)
[12:06] <ScottK> You can just rm the kwin related config stuff and start over if you don't want to pick through it.
[12:06] <ScottK> (sorry I didn't remember that earlier)
[12:07] <RAOF> Aha.
[12:08] <RAOF> I suspect it might be the OpenGLIsUnsafe=true
[12:08] <RAOF> Is this the intended user experience?  You accidentally mess with kwin too much, and it will forevermore refuse to enable compositing?
[12:09] <RAOF> Sorry, that was a bit snarky.
[12:17] <tseliot> I guess they're just being overcautious ;)
[12:22] <RAOF> Well, that can now be deferred to tomorrow.
[12:23] <ScottK> It's meant to keep users from being overwhelmed by repeated crashers, but it's not particularly developer friendly.
[16:46] <jibel> Could a member of the ubuntu-x-swat have a look at bug 645064. Since it's a widely used ppa, it may causes issues when comes the time to upgrade to maverick.
[16:46] <ubot4> Launchpad bug 645064 in update-manager (Ubuntu) (and 1 other project) "nvidia-current from Ubuntu-X-Swat PPA is blocking the upgrade from Lucid to Maverick (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/645064
[16:49] <tseliot> mvo: maybe we should call "ppa-purge" on dist-upgrades to avoid these problems ^^
[16:54] <mvo> tseliot: I need to run, I have a look when I'm back (sorry)
[16:55] <tseliot> mvo: np. Thanks
[16:55] <mvo> thanks tseliot and jibel
[16:58] <Sarvatt> that's one of the reasons I'm not sure nvidia-current providing an artifical abi is a good idea since its compatible with both abi's and is causing package manager problems
[17:04] <bjsnider> but the lucid and maverick versions are providing the same abi, so why is it blocking the upgrade?
[17:12] <Sarvatt> they aren't, maverick is xserver-xorg-video-8
[17:16] <Sarvatt> its something to do with xserver-xorg-core having a breaks: on the old abi interacting with apt ordering, doesn't happen if the breaks are gone and not sure how to make it want to remove nvidia before trying to upgrade X
[17:17] <bjsnider> yes but that virtual package is provided by a lot more than just nvidia-current
[17:18] <bjsnider> there are 43 packages that provide xserver-xorg-video-6 in lucid, so why is nvidia-current causing this problem and not all the rest of them too?
[17:19] <bjsnider> and why isn't the package manager preferring to move the video-8 as a newer version, which the nvidia-current maverick package provides?
[17:20] <jibel> bjsnider, update-manager refuses to upgrade nvidia-current because the ppa is disabled at upgrade time. Since it's manually installed it puts it on hold and blocks the upgrade of the xserver.
[17:20] <jibel> bjsnider, I haven't dig further but it's the kind of scenario.
[17:20] <bjsnider> oh, right
[17:20] <bjsnider> and the ppa has a newer nvidia blob than maverick
[17:21] <jibel> bjsnider, right
[17:21] <bjsnider> so all the other 40-some video-8 packages upgrade because the maverick versions are available at that time
[17:22] <bjsnider> well i'm damned if i know how to fix that
[17:22] <Sarvatt> i put a note about needing to ppa-purge before upgrading on x-updates like there is on xorg-edgers for now, if anything i'm thinking maybe we can just drop the abi from the PPA versions
[17:23] <bjsnider> but if it disables the ppa then it should be purging it too
[17:23] <Sarvatt> it never has, thats why i made ppa-purge
[17:23] <Sarvatt> it's hell with xorg-edgers :(
[17:23] <bjsnider> is it possible to purge that ppa?
[17:23] <Sarvatt> yup
[17:24] <bjsnider> why is it necessary to provide the abi?
[17:24] <Sarvatt> sometimes they are late supporting a new ABI and its there to block upgrades
[17:26] <bjsnider> anyway, updae-manager could be changed to test for that ppa and if it's there, install ppa-purge and then proceed to purge it
[17:27] <tseliot> Sarvatt: BTW I made fglrx provide the ABI too... I wish there was a better way
[19:50] <barry> hi folks.  i saw that a new fglrx-modaliases was released, and indeed i've been able to successfully install the fglrx packages. but i still cannot enable desktop effects for my radeon hd 4670 in 64bit maverick
[19:51] <barry> should that be possible now or do i still have to wait? (fine if so)
[19:51] <barry> i can't find a log file of the attempt to enable it and don't see any errors in my Xorg.0.log
[20:04] <ScottK> New mesa snapshot seems to work well on Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
[20:18] <strycore> hello
[20:18] <strycore> #ubuntu-bugs
[20:18] <strycore> damnit :P
[20:20] <strycore> ok Maverick is coming soon and lately I have noticed a strange bug for almost every full screen game
[20:20] <strycore> the mouse pointer comes bask to it's original position every second or so
[20:20] <strycore> I guess it's related to Xinput
[20:25] <strycore> argh it's driving me crazy
[20:38] <strycore> ok , nevermind I found the guilty program
[20:38] <strycore> unclutter
[20:39] <strycore> I was suspecting either SDL or Xinput :P