[00:03] <Sarvatt> hmm, still randomly getting this on boot (II) XINPUT: Adding extended input device "PS/2 Generic Mouse" (type: MOUSE)
[00:04] <Sarvatt> instead of (II) XINPUT: Adding extended input device "SynPS/2 Synaptics TouchPad" (type: TOUCHPAD)
[00:05] <Sarvatt> [   12.798399] atkbd.c: Spurious NAK on isa0060/serio0. Some program might be trying access hardware directly.
[00:08] <Sarvatt> only getting it on the ubuntu kernels, wonder if its related to the mac mouse button emulation that i disable in mine
[00:09] <Sarvatt> glad psmouse isnt built into the kernel at least, sudo rmmod psmouse && sudo modprobe psmouse fixes it
[02:51] <Sarvatt> hmm, so about the idle screen blanks even when you arent idle..
[02:51] <Sarvatt> in power management preferences, on battery power I have it set to put the display to sleep when inactive for 5 minutes and 5 minutes after starting g-p-m it idles no matter what
[02:53] <Sarvatt> i wonder if its reading the GDM session's idle timer maybe?
[02:53] <Sarvatt> g-p-m and devicekit-power dont work for me when they start with my session, but it works fine if i kill them and restart
[02:54] <Sarvatt> restart devkit-power-daemon and gnome-power-manager that is
[02:54] <Sarvatt> exactly 2 minutes after starting g-p-m I get this
[02:54] <Sarvatt> TI:21:39:00	TH:0x8cee608	FI:gpm-idle.c	FN:gpm_idle_idletime_alarm_expired_cb,377
[02:55] <Sarvatt>  - idletime alarm: 1
[03:01] <Sarvatt> ohh didnt see there was a blog post about it by the g-p-m guy http://blogs.gnome.org/hughsie/2009/07/30/accidental-blanking-and-gnome-power-manager/
[03:33] <Sarvatt> so are ya planning on switching to --enable-xselinux in xserver once libaudit-dev is in main tjaalton?
[03:47] <Sarvatt> bryce: 182_fedora_quirk_pea.patch is already in xserver 1.6.3 in debian git
[04:03] <Sarvatt> since I'm not on pkg-xorg yet -- http://sarvatt.com/downloads/0001-debian-control-adjust-build-dep-epoch-numbers-to-the.patch
[04:04] <Sarvatt> little problem with the package versions in debian/control for xserver since the last debian merge
[04:14] <Sarvatt> applied for pkg-xorg, put that off for too long
[04:16] <Sarvatt> ahh nice, looks like they fixed up dmx on xserver master now too so that might compile again
[04:34] <Sarvatt> would it be worthwhile to create new branches on things for experimental packages on alioth maybe? like ubuntu-experimental or something, to put future updates in so the main branch can stay close to the release?
[04:36] <Sarvatt> just thinking it would be nice to be able to move all this xorg 7.5 stuff into git somewhere so I wouldnt have to have such complicated scripts to alter the current releases, some things need a huge amount of changes
[04:36] <Sarvatt> maybe I should look into doing it via bzr as much as I would prefer git, might be intruding on things too much doing that
[04:37] <Sarvatt> alot of the packages dont even have ubuntu branches in the first place
[04:53] <Sarvatt> so many options, i dont know what would work.. ideally i'd like to just have debian/ for about 20 packages somewhere that I can dump on top of fdo git to build packages from
[05:07] <Sarvatt> anyone familiar with bzr and git both? is it possible to set it up so I can merge remote git repo tags into a bzr branch somehow?
[05:15] <Sarvatt> bryce_away: dont know if you saw, but xorg-server isnt building on karmic because of the libaudit-dev not being in main thing, it's built with --disable-selinux so even if it got in main it'd still be unused so maybe you want to just comment the build-dep out?
[05:17] <Sarvatt> libaudit-dev is only used for the xselinux extention
[05:20] <virtuald> sarvatt: maybe bzr-git in universe
[05:23] <Sarvatt> yeah i'm looking at that now. cant find any documentation on it but it looks like i can just interact with the git repo with bzr commands, it added the bzr directory under .git
[05:24] <virtuald> ok
[05:26] <Sarvatt> thanks for the tip :)
[05:28] <virtuald> 8]
[06:29] <Sarvatt> ahh i dont get bzr.. started making branches on ~xorg-edgers with just debian/ for things but like theres no projects set up for the libs to push to
[06:30] <Sarvatt> like bzr push bzr+ssh://sarvatt@bazaar.launchpad.net/~xorg-edgers/xorg-server/git-packaging worked, but bzr push bzr+ssh://sarvatt@bazaar.launchpad.net/~xorg-edgers/libx11/git-packaging doesnt because theres no libx11 project, not sure what the right way to do it would be
[06:32] <Sarvatt> guess it should be ~xorg-edgers/xorg-server/libx11/git-packaging
[06:37] <Sarvatt> ah think i got it worked out, will use the xorg-server project for everything and just commit the branches as xorg-server/<package>
[07:52] <tjaalton> Sarvatt: no need to bump those :)
[07:53] <tjaalton> Sarvatt: and the selinux-thing should be fixed in debian too
[07:53] <tjaalton> it's waiting for audit to be moved in main, yes
[07:53] <tjaalton> a MIR has been filed, and it should be handled this week
[07:56] <tjaalton> bryce: an idea; the package versions page doesn't show epochs, but maybe it could? add those after comparing the version to upstream
[07:57] <tjaalton> Sarvatt: well, most of the epochs are bumped in debian too
[07:57] <bryce> tjaalton, I think I took them out because it bloated the size of the page; out of curiosity why do you need them?
[07:57] <tjaalton> bryce: ok, just to see which were different, but maybe it's not too important
[07:58] <tjaalton> iow, scratch that
[07:59] <bryce> okie
[08:08] <Sarvatt> we have alot of stuff with epochs bumped above debian though, dont want to bump them in build deps? i went through and checked every versioned dep in there and those were the ones we had a higher epoch on. noticed it because i have to be alot pickier with xserver master because like, we need libxi >=1.2.99.1 and our 2:1.2.1-2ubuntu1 is higher than libxi-dev (>= 1:0.99.1)..
[08:08] <tjaalton> Sarvatt: check again, there aren't that many
[08:09] <tjaalton> those were never bumped in the debian version either
[08:11] <Sarvatt> because debian has the lower epochs and doesnt need it bumped? i'm confused
[08:11] <Sarvatt> most all of the libs are 2: on ubuntu and 1: in debian
[08:11] <tjaalton> no, for instance x11proto-fixes-dev has epoch in debian too
[08:12] <tjaalton> +an
[08:12] <tjaalton> I bumped those in debian ~2 years ago
[08:12] <tjaalton> some remained, since they never had new releases, like some protos
[08:12] <Sarvatt> i didnt touch anything that wasnt a higher epoch in ubuntu than debian, checked every versioned package in the build deps
[08:13] <Sarvatt> (in http://sarvatt.com/downloads/0001-debian-control-adjust-build-dep-epoch-numbers-to-the.patch)
[08:13] <Sarvatt> ah i see what you mean
[08:14] <Sarvatt> sorry, its late and i'm slow :)
[08:14] <tjaalton> heh
[08:15] <tjaalton> only x11proto-damage-dev from that list has an epoch in ubuntu where debian doesn't
[08:16] <tjaalton> and that's waiting in git
[08:16] <tjaalton> waiting for a reason to upload it, since there hasn't been a new version in ages
[08:17] <Sarvatt> looks like i was adjusting build dep versions without bumping the epochs for a few things on xserver master last month then, shoot
[08:17] <Sarvatt> yep  libxi-dev (>= 1:1.2.99.1) ugh
[10:11] <tseliot> bryce, tjaalton, jcristau: shouldn't zapping be on by default now?  It's not on in Karmic, and I don't seem to be able to change its behaviour through xkb
[10:12] <tseliot> http://lists.freedesktop.org/archives/xorg-devel/2009-April/000626.html
[10:16] <tjaalton> tseliot: should be yes
[10:16] <tjaalton> I can't make it work either.. hmm
[10:16] <tseliot> setxkbmap -option terminate:ctrl_alt_bksp should do it but it doesn't
[10:17] <jcristau> that's because karmic has an old server
[10:17] <tseliot> so I was wondering if some package has to be updated first
[10:17] <tseliot> aah, my assumption was right then
[10:17] <tjaalton> jcristau: it's not on 1.6.x?
[10:17] <jcristau> it's in 1.6.2
[10:17] <tjaalton> heh
[10:18] <jcristau> so it's kees' fault ;)
[10:18]  * tseliot thought we already had 1.6.2...
[10:19] <jcristau> xserver-xorg-core | 2:1.6.1.901-2ubuntu2 |        karmic | amd64, i386
[10:19]  * tseliot nods
[10:19] <tjaalton> maybe I'll merge 1.6.3 and drop the audit dep for now, since selinux-support is disabled anyway :)
[10:20] <tseliot> tjaalton: 1.6.3 would be nice to have. It should be just a few bug fixes (which are more than welcome)
[10:21]  * tseliot thinks it would be wise for Karmic to have 1.6.3 instead of 1.7.x
[10:22] <tjaalton> could be
[10:22] <bryce> tseliot, yeah I think it's pretty clear we should stick with 1.6.3
[10:22] <tseliot> ;)
[10:23] <bryce> I've queried a bunch of people / driver maintainers / etc. and no one seems to have a strong interest in 1.7
[10:24] <tseliot> XI2 is very interesting but definitely not critical for Karmic
[10:24]  * tseliot has yet to study XI2...
[10:25] <tseliot> s/critical for/critical to/
[10:31] <jcristau> Sarvatt: added to pkg-xorg.  i'm assuming you'll work with timo/bryce for the ubuntu branches.  if at some point you want to get something in one of the debian branches, best is to get in touch with #debian-x on oftc.  have fun! :)
[10:49] <tjaalton> bryce: if we decide here and now that karmic will stick to 1.6.3, I'll upgrade my desktop right away :)
[10:49] <tjaalton> er, 1.6.x
[10:54] <bryce> tjaalton, ok let's make it official.
[10:55] <bryce> tjaalton, I've run it by pitti and he thumbs-upped it too
[10:55] <bryce> tjaalton, if you want to merge in 1.6.3 this week go for it, otherwise I'll try to get to it either later this week or next
[10:56] <bryce> not getting so much done here at the sprint, because people keep asking for X help ;-)
[10:57] <jcristau> tjaalton: removing the build dep makes sense to me, if you're not enabling xselinux :)
[11:00] <bryce> new -fglrx 8.632 uploaded to karmic
[11:03] <tseliot> bryce: heh, I guess you're the only one with X super powers there ;)
[11:12] <bryce> apparently
[11:12] <bryce> ok reboot time
[11:31] <Unggnu> hi all
[11:31] <bryce> heya Unggnu
[11:31] <Unggnu> Is the compiz ready radeon r600/r700 driver in the edgers repository?
[11:32] <Unggnu> hi bryce
[11:32] <Unggnu> The new intel driver works great besides of an error message and an additional option to get textured video working without tearing.
[11:32] <bryce> great
[11:33] <Unggnu> Do anyone else still have tearing problems with textured video?
[11:33] <bryce> Unggnu, do you have upstreamed bugs for those two issues?
[11:33] <Unggnu> yes
[11:33] <bryce> great
[11:33] <Unggnu> at least partly
[11:33] <Unggnu> http://bugs.freedesktop.org/show_bug.cgi?id=20664
[11:33] <ubottu> Freedesktop bug 20664 in Driver/intel "implement vblank sync'd GL buffer swap" [Enhancement,Resolved: fixed]
[11:33] <Unggnu> this is fixed but I still got the tearing
[11:33] <Unggnu> so someone mentioned an additional option which worked great
[11:33] <Unggnu> I am not sure if they make it standard though
[11:33] <bryce> yeah we've gotten more caught up with -intel than I think we've ever been.  Pretty much all remaining issues seem known upstream so hopefully they keep pounding them down.
[11:34] <Unggnu> More important is the KMS video overlay problem
[11:34] <Unggnu> http://bugs.freedesktop.org/show_bug.cgi?id=20901
[11:34] <ubottu> Freedesktop bug 20901 in DRM/Intel "please port video overlay to KMS" [Enhancement,New]
[11:35] <Unggnu> I guess it is a huge problem for pre i915 cards
[11:36] <Unggnu> KMS lets everything really look professional
[11:36] <Unggnu> The screen is up after one second after resume from suspend
[11:36] <jcristau> i8xx has other issues anyway...
[11:36] <Unggnu> jcristau: yes
[11:36] <Unggnu> They kicked already the support for i815 afaik
[11:37] <Unggnu> Is there somebody working on it?
[11:37] <jcristau> what do you mean?
[11:37] <Unggnu> The Intel developers doesn't support i815 anymore afaik
[11:37] <bryce> I've seen comments from a couple community people indicating interest in working on 810/815 code, but haven't seen patches
[11:37] <Unggnu> *don't
[11:38] <jcristau> Unggnu: ah, that.  well, otoh they're not breaking it either.
[11:38] <tjaalton> bryce: ok then, I'll merge it today
[11:38] <bryce> tjaalton, thanks
[11:38] <Unggnu> jcristau: If they don't do anything on it anymore they are basically breaking it because it has no exa, uxa and kms
[11:38] <jcristau> so it's probably better off on that front than 830-class :)
[11:38] <Unggnu> ok, maybe exa
[11:38] <tjaalton> jcristau: yeah I don't think it buys much, at least no-one has asked for it
[11:39] <Unggnu> I hope that they got some time for it as soon the whole switching process is done (if it will ever be done :D )
[11:39] <jcristau> Unggnu: no.  not even exa.  which makes it even harder to break.
[11:39] <Unggnu> jcristau: Xaa doesn't work anymore, at least with i915. You got many artifacts and stuff like this
[11:40] <Unggnu> I don't know if this is better with i815 with current X
[11:40] <jcristau> so you use shadowfb and everything's fine
[11:40] <Unggnu> ok
[11:40] <jcristau> it's not fast, but then you have an i810 so..
[11:41] <Unggnu> Is this automatically done?
[11:41] <jcristau> no idea
[11:41] <jcristau> it's not like there are many users of that around still
[11:42] <Unggnu> Maybe but Linux is often mentioned to support older hardware
[11:42] <Unggnu> especially with OSS
[11:44] <jcristau> that was probably true, once upon a time.  today, not so much.  or at least it requires some work.
[11:44] <Unggnu> I got huge problems with modesetting and i815 or i850. I don't know if they ever got fixed.
[11:44] <bryce> i850?
[11:44] <Unggnu> what's after i815? :)
[11:44] <jcristau> 830
[11:44] <Unggnu> then i830, don't know
[11:45] <Unggnu> The intel driver doesn't worked at all so we needed the old i810
[11:45] <Unggnu> and it worked only sometimes
[11:45] <jcristau> but then again once upon a time you had to buy year-old hardware to get drivers in linux
[11:45] <Unggnu> yes, this isn't the case anymore at least for intel
[11:47] <Unggnu> What is the status with KMS and radeon 600/700?
[11:48] <Unggnu> Is it very complicated to port the modesetting code from X to the Kernel?
[11:49] <tjaalton> it's not just the modesetting part, but the plumbing needed for that
[11:49] <Unggnu> I am still waiting for my first Linux bluescreen :D
[11:50] <Unggnu> One remaining problem if X crashes is still that it keeps the keyboard locked so I can't really do anything except of connecting through network or restarting with acpi keys.
[11:53] <Unggnu> It would be great if this issue could be also fixed. At least I now see the console again if X crashes thanks to KMS.
[12:09] <Unggnu> So is an current radeon SVN driver in the xorg-edgers package?
[12:09] <Unggnu> With 3D support for the r600/r700?
[12:09] <tjaalton> sarvatt would know
[12:10] <Unggnu> I hope that it also has support for powerplay. The fan noise of the bigger cards can turn you mad
[12:10] <tjaalton> passive cooling ftw
[12:10] <Unggnu> :)
[12:11] <Unggnu> I already underclocked and undervoltage it through the firmware to make it somehow manageable :)
[12:13] <Unggnu> The FGLRX has support for powerplay but it is too buggy
[12:19] <bryce> superm1, do you know if -fglrx 8.632 is supposed to build on hardy?  http://launchpadlibrarian.net/29926343/buildlog_ubuntu-hardy-i386.fglrx-installer_2%3A8.632-0ubuntu1~xup~1_FAILEDTOBUILD.txt.gz
[12:19] <Sarvatt> jcristau: appreciate it, and thanks for the info!
[12:20] <Sarvatt> Unggnu: you're on your own with that one, you need to build new radeon kernel modules and be using a 2.6.28 kernel to get it all working pretty much
[12:20] <Unggnu> Sarvatt: ok, thx
[12:20] <Sarvatt> way too intrusive to put into edgers right now, but the r600 mesa driver is built
[12:22] <Unggnu> Btw. what change exactly has made Gnome so fast?
[12:23] <Unggnu> I mean it switches directly from GDM to Gnome since Jaunty
[12:23] <Unggnu> Was this upstream or Ubuntu specific?
[12:23] <Sarvatt> i just have no interest in setting in up so early at least until it runs right under current kernels and noone else is stepping up to do it, you could do it with a drm-snapshot package though
[12:23] <Unggnu> Sarvatt: I understand this, I just wanted to know
[12:24] <Sarvatt> i'm guessing upgrading from the version of gdm that dated back to hardy in karmic did it :D
[12:24] <Sarvatt> or was it pre-hardy even
[12:24] <Unggnu> I don't know, the boost came with Jaunty afaik
[12:24] <Unggnu> if it is preloaded one time and you logout and login the desktop is there in one second
[12:25] <Unggnu> KDE isn't nearby since this changes
[12:25] <Unggnu> *these
[12:26] <Unggnu> And in Karmic it even looks much smoother thanks to KMS
[12:27] <Unggnu> With the .30 kernel in Karmic I got 10 seconds boot time but now I am back to 15
[12:27] <Unggnu> according to bootchart, the actual time is higher
[12:27] <Sarvatt> oh, thats odd, you're the first person I've talked to that saw a speed boost in gnome startup in jaunty, I had a good 30 second pause added to all of my machines after x started in jaunty personally :(
[12:28] <Unggnu> Really?
[12:28] <Unggnu> I just remember login out and login again takes quite some time to show the desktop
[12:28] <Unggnu> after cold boot the desktop is there in five to ten seconds after X start I guess
[12:29] <Sarvatt> yeah there was something really wrong there, it wasnt specific to any of my machines either. karmic looks slower on a bootchart but you can interact with it WAY earlier so it feels faster
[12:30] <Unggnu> Karmic is the first which makes Compiz 100% usable without penalties, at least with intel hardware
[12:30] <Unggnu> with working textured video and so on
[12:31] <Unggnu> and the animation are much more smoother
[12:31] <Sarvatt> i was getting around 22 second boots in jaunty, but couldnt do anything until over a minute, karmic is showing 31 seconds on bootchart but i have a cursor up after like 20
[12:31] <Unggnu> KWin looks really great with Karmic
[12:31] <Unggnu> Haha, like XP
[12:33] <Unggnu> Still, my mothers laptop has to stick with Hardy because of several penalties and it is really stable. I hope that Karmic hasn't this issues anymore.
[12:37] <Sarvatt> whoa, xserver master almost fully compiles now http://launchpadlibrarian.net/29926738/buildlog_ubuntu-karmic-i386.xorg-server_2%3A1.6.99.1%2Bgit20090805.95b678e6-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
[12:38] <Sarvatt> i've been having to disable kdrive xephyr xvfb dmx and xnest all this time
[12:47] <Unggnu> i am off, ciao
[12:51] <tjaalton> xserver 1.6.3-1u1 uploaded
[12:51] <bryce> yay
[12:51] <tjaalton> test-built too
[12:51] <bryce> reboot time
[13:46] <tseliot> \o/
[14:19] <Sarvatt> argh, such silly little mistakes, looks like its working right again at least http://bazaar.launchpad.net/~xorg-edgers/ppa-purge/ubuntu/revision/4?start_revid=4
=== maxb_ is now known as maxb
[15:12] <tjaalton> ok, my desktop booted to karmic just fine
[15:13] <tjaalton> and with 1.6.3 zapping works again :)
[15:13]  * bryce updates
[15:13] <bryce> reboot brb
[15:30] <tseliot> tjaalton: thanks a lot :-)
[15:35] <Sarvatt> nice, dmx is the only thing that doesnt work on xserver master now, they are really trying to push it out the door now that fedora people took over :)
[15:38] <Sarvatt> darnit, i versioned xorg-server as 1.6.3+git instead of ~git on edgers, didnt mean to do that
[15:39] <Sarvatt> just libdrm mesa and ati that need to be +git since its built with libdrm-radeon1
[15:40] <Sarvatt> btw I started pushing the debian/ packaging for stuff on launchpad incase the libdrm-radeon1 changes are useful or anything
[15:40] <Sarvatt> https://code.edge.launchpad.net/~xorg-edgers/
[15:48] <Sarvatt> easier to just keep debian/ around and apply it on top of fdo git than keep up with the crazy amount of hooks for auto-xorg-git i need to package xorg 7.5 components
[15:52] <bryce> Sarvatt, are the -ati and mesa in xorg-edgers built with libdrm-radeon1 ?
[15:52] <Sarvatt> yep
[15:53] <Sarvatt> the libdrm changes to build libdrm-radeon1 are here -- http://bazaar.launchpad.net/~xorg-edgers/xorg-server/libdrm/files/head%3A/debian/
[15:54] <bryce> excellent
[15:56] <Sarvatt> they could be incorrect but things work, was my first time really packing a new library so I might have missed something
[15:56] <bryce> Sarvatt, how much testing do you think it's gotten so far?
[15:57] <Sarvatt> tooons
[15:58] <jcristau> libdrm-radeon1.install should probably have the full soname in the glob instead of just .so.*, but apparently that's wrong for the other libs too, so not your fault :)
[15:58] <Sarvatt> more people bugging me about ati KMS in edgers than intel by far
[15:59] <bryce> Sarvatt, how do you feel about us moving it into Karmic proper now?
[15:59] <Sarvatt> i'm unsure about how this situation should be handled though, I couldnt find it in any of the debian library packaging guides
[15:59] <Sarvatt> http://bazaar.launchpad.net/~xorg-edgers/xorg-server/libdrm/annotate/head%3A/debian/libdrm-nouveau1.symbols
[15:59] <bryce> would be nice to have some KMS-ified -ati in by Alpha-4 to get increased testing on
[16:00] <Sarvatt> when symbols are removed should the missing lines be added, or just removed completely?
[16:00] <bryce> tjaalton, ^^ your opinion too?
[16:00] <jcristau> Sarvatt: when public symbols are removed, the soname (and package name) should be changed
[16:02] <Sarvatt> ah hah! thats what I thought but I thought I saw libdrm-nouveau1 have symbols dropped on the last api bust and the package didnt increase, must have been mistaken
[16:03] <jcristau> libdrm-nouveau is known unstable though, so i guess upstream isn't very careful with that
[16:04] <Sarvatt> bryce: there are some issues I'd be worried about but I think it would be a good thing to do :)
[16:04] <Sarvatt> like, xserver-xorg-video-ati hasn't compiled against xserver 1.6.2+ for a month now when libdrm-radeon1 exists
[16:05] <Sarvatt> i've been doing that nasty hack that makes it incompatable with older (or master branch) xservers on edgers
[16:05] <bryce> Sarvatt, -ati doesn't build against libdrm-radeon1?  that sounds fairly serious...?
[16:06] <Sarvatt> just with server 1.6 branch
[16:06] <bryce> hrm
[16:06] <jcristau> the dri2 api change?
[16:06] <bryce> well since we decided earlier today to stick with 1.6.x, that sounds like a blocker
[16:06] <Sarvatt> yeah
[16:06] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/radeon_dri2.c
[16:07] <jcristau> that should be a fairly trivial fix, i think
[16:07] <Sarvatt> in there, i've been just changing every instance of DRI2BufferPtr to DRI2Buffer2Ptr so it works with server 1.6 branch
[16:08] <bryce> Sarvatt, via a patch?
[16:08] <Sarvatt> but that looks like it would break non server 1.6 branch
[16:09] <bryce> Sarvatt, any problems with mesa in making it built against libdrm-radeon1?
[16:09] <Sarvatt> none, they've actually been breaking non libdrm-radeon1 mesa 7.6 way more than the KMS one :D
[16:09] <bryce> hah
[16:10] <bryce> so is this mesa a branch of mesa, or the mesa main branch?
[16:10] <Sarvatt> just mesa master
[16:11] <Sarvatt> probably will branch off in a few weeks?
[16:12] <bryce> Sarvatt, would merging that mesa master risk breaking -intel or other drivers?
[16:16] <Sarvatt> i havent had any issues with intel on 7.6 since may updating it almost daily at least, but there has been a bunch of times where i packaged it just to find a "revert last commit it broke things" an hour later
[16:16] <Sarvatt> mostly radeon though :D
[16:18] <bryce> Sarvatt, I'm trying to gage if we should pull the full mesa snapshot, or tease out just the -ati relevant bits (which could be hard)
[16:21] <Sarvatt> like a mesa-snapshot for radeon that diverts mesa 7.5?
[16:25] <superm1> bryce, i wasn't aware of any failures on hardy, is that the only one that failed?
[16:27] <Sarvatt> there is no x710 xarch for hardy in fglrx-installer?
[16:27] <Sarvatt> if i'm reading the rules right
[16:27] <superm1> oh right! did you do a --build-package Ubuntu/hardy for the hardy build?
[16:27] <bryce> superm1, karmic and jaunty seemed to go through fine
[16:27] <Sarvatt> ifeq ($(DISTRO),hardy)
[16:27] <Sarvatt>         XARCH   := x710
[16:28] <superm1> or did you just sent the karmic/ajunty build to hardy PPA
[16:28] <bryce> superm1, oh no, didn't think to try that.  Okay I'll give that a go
[16:28] <Sarvatt> robert@ubuntu-9{/opt/source/xorg-pkg-tools/fglrx-installer-8.632}:ls
[16:28] <Sarvatt> arch  debian  etc  lib  opt  usr  x740  x740_64a
[16:28] <Sarvatt> ah you guys got it :D
[16:28] <bryce> yeah just set it in the changelog
[16:29] <superm1> bryce, well a different build happens for hardy because they have an extra x710 directory for that X server
[16:29] <bryce> Sarvatt, ok so I think what I'm going to do is put these three packages into the kms ppa for xswat and solicit some additional testing, then hopefully if nothing majorly crazy happens, get them uploaded to Karmic in time for alpha-4
[16:33] <Sarvatt> sounds good :) to be honest I feel non KMS mesa 7.6 is the way to go if I used it alot. it doesnt seem like the KMS performance is going to be anywhere near non KMS in 2.6.31 and 7.6 is _alot_ better off than 7.5 and under on my 9200 mobility at least
[16:34] <jcristau> yeah radeon-rewrite was merged after 7.5 so i guess that's an improvement
[16:34] <jcristau> don't know how solid it is, but..
[16:40] <Ng> I'm sure I asked about this before, so I apologise for wasting everyone's time... disappearing animated mouse pointers in karmic. bug in xserver-xorg?
[16:41] <Ng> or -intel? (so I know where to search/file/subscribe)
=== james_w is now known as jdw
[16:52] <bryce> Ng, don't remember seeing it in -intel
[16:53] <Ng> it's just the animated ones, so loading folders in t'bird, or pages in f'fox makes it disappear. I found similar reports against -nvidia back in the gutsy era which seemed to relate to compiz desktop zooming, which I've disabled to see if it helps
[16:54] <Ng> I'll restart properly later with the new xserver to see if that makes any difference
[16:56] <Sarvatt> do they flicker constantly while animated?
[16:56] <Sarvatt> or disappear completely?
[16:56] <Sarvatt> and do you see a box shaped green block of corruption where the cursor should be when it happens sometimes? :)
=== jdw is now known as james_w
[16:58] <Ng> Sarvatt: disappear completely
[16:58] <Ng> Sarvatt: I've never seen them flicker or be a green block
[16:59] <Ng> as soon as it goes back to the normal mouse pointer it appears normally again
[17:00] <Sarvatt> both with and without compiz? this is in gnome? happens with every cursor theme? 
[17:04] <Ng> I've not tested without compiz, I use gnome, I've never changed cursor theme ;)
[17:05] <Ng> but I can do some other testing
[17:08] <Sarvatt> could be so many things, was just trying to narrow it down a little
[17:09] <Sarvatt> i'm pointing my finger at compiz first though since thats always where my problems come from :)
[17:29] <Ng> Sarvatt: yeah, I'll see if I can figure out exactly when it starts and try some combinations :)
[17:30] <Sarvatt> just finding something to animate my darn cursor to test things was a challenge in itself :D
[17:31] <Sarvatt> since most things that do load alot faster the second time
[17:40] <Ng> hehe
[17:41] <Ng> my laptop has a feeble CPU, and my IMAP folders are insane ;)
[17:42] <Sarvatt> guess i should have installed a mail client, i was just opening apps and could only use the first open to look at it since everything loads faster after that :D
[17:46]  * Ng files a bug that Sarvatt has an excessively fast PC
[17:48] <Sarvatt> .....it's an atom cpu
[17:48] <Sarvatt> :D
[18:00] <hyperair> fast hard disk then
[18:02] <Sarvatt> the corruption i was trying to see only happens like every 15 seconds of animation or so
[18:21] <bryce> ok, I've got the three packages put into the kms ppa - https://edge.launchpad.net/~ubuntu-x-swat/+archive/kms
[18:22] <bryce> redid the -ati merge to use the Ubuntu debian/ directory and tweaked the mesa one a bit
[18:22] <bryce> tomorrow will try to do some testing on it, then hopefully get it in maybe friday or next week early
[18:22] <bryce> cya
[18:27] <Sarvatt> ah yeah probably dont want to enable the r600 driver, i was just enabling it for the heck of it since it theoretically works if people go and use the external drm kernel modules for it
[18:28] <Sarvatt> see ya bryce, will point people to that ppa 
[18:28] <Sarvatt> woohoo @ubuntu email works now, time to mess with my keys
[19:23] <virtuald> is it some way possible to make kms choose my preferred resolutions?
[19:35] <Sarvatt> wish I knew the answer to that because it would solve alot of problems :)
[21:30] <Sarvatt> hyperair: are you around by any chance?
[22:30] <bryce> heya Sarvatt
[22:31] <Sarvatt> heyo, whats up bryce?
[22:32] <bryce> ah, just got back from exploring the city.
[22:34] <Sarvatt> out of town?
[22:35] <Sarvatt> ohh in dublin?
[22:37] <bryce> yup
[22:38] <Sarvatt> i loved it over there, lived in glasgow a few years ago and took a few trips over there. fun trying to interact with the locals huh? :)
[22:39] <hyperair> Sarvatt: what's up?
[22:39] <Sarvatt> didnt realize the sprint thing was a physical meeting
[22:40] <Sarvatt> i figured it out hyperair, was going to ask a question about gpg keys and adding new email addresses to it but it turned out to be easier than i thought
[22:40] <Sarvatt> thank ya though, sorry to bother
[22:40] <hyperair> hahah okay
[23:14] <bryce> Sarvatt, yeah we were having our after-lunch colloquium, but the presenters were having some projector problems
[23:15] <bryce> actually no it wasn't after lunch, it was in the morning 9am
[23:15] <bryce> and some random red-faced guy from elsewhere in the hotel wandered by, poked his head in, and started lecturing the room about random delusional things
[23:16] <bryce> we all sat in rapt attention, then someone asked if the guy was from the kernel team
[23:17] <Sarvatt> LOL