[00:28] <Sarvatt> chrisccoulson: is 05_locking_for_compiz.patch supposed to still be in our gnome-screensaver patch series?
[00:29] <Sarvatt> chrisccoulson: it was fixed years ago? https://bugzilla.gnome.org/show_bug.cgi?id=488264
[00:34] <chrisccoulson> Sarvatt - yeah, we could probably drop that no
[00:34] <chrisccoulson> s/no/now
[01:03] <Sarvatt> i'm not sure 02_keep_unlock_raised.patch is relevant still either
[01:58] <RAOF> Anyone here have a recentish macbook pro with the dual nvidia-gpus?
[02:00] <bryce_> RAOF, ask on ubuntu-x@ or ubuntu-devel@
[02:03] <RAOF> Yeah, I guess so.  Not quite so interactive, though :)
[02:18] <bryce_> whew almost caught up with -ati triaging... 3 more to go
[02:56] <Sarvatt> RAOF: pretty sure the generation of the gpu in that is just plain busted with accel in general on nouveau
[02:58] <RAOF> Sarvatt: Upstream thinks that it's likely an EFI problem, and that loading efifb first would make everything work.
[02:59] <Sarvatt> theres a dell model without EFI with the same hybrid sli setup that i've seen reports on that they had to use noaccel=1
[03:00] <Sarvatt> trying to dig up the other bug
[03:00] <RAOF> Ok.  So we might need to be detecting that and quirking off accel.
[03:01] <Sarvatt> GT240 needs noaccel quirked too
[03:02] <bryce_> yay, -ati is caught up
[03:02] <bryce_> (for now)
[03:03] <bryce_> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
[03:03] <RAOF> Damn you plymouth!  Stop killing boot on nouveau+dual head.
[03:04] <Sarvatt> oh crap we're closing in on 400 bugs now
[03:05] <Sarvatt> RAOF: geforce 9500M, thats it
[03:05] <Sarvatt> hybrid 9400M G + 9200M GS
[03:06] <RAOF> I suspect that hybrid setups generally might just be failing.
[03:06] <RAOF> Although sadly not because of vga16fb.  One bug I can't blame on that framebuffer!
[03:07] <RAOF> Sarvatt: Why do you think GT240 needs to be quirked?  Bug #554818 seems to be cruising along nicely with accel.
[03:08] <RAOF> Oh, wait.  That's the mobile variant.
[03:09] <RAOF> (I'm not entirely sure where that bug should go, but I'm pretty sure it's not a nouveau bug)
[03:16] <Sarvatt> thats a GT216 (aka NVA5) I think, alberto has an actual GT215 (GT240 desktop) NVA3 that doesn't work
[03:16] <RAOF> We can't quirk NVA3 acceleration off - it doesn't have any.
[03:17] <RAOF> There isn't a voodoo generator for it (in the Lucid packages - one has *just* been checked in to nouveau git)
[03:21] <RAOF> Um, why are people surprised that atom processors can't decode high resolution h264 video in realtime?
[03:33] <bryce_> Sarvatt, RAOF, have either of you applied for MOTU/Core-Dev?
[03:34] <RAOF> I haven't applied for core-dev (yet).
[03:35] <bryce_> here's a link to the process for core-dev https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[03:36] <bryce_> good idea for both of you to add it to your todo list, you'll probably appreciate having the rights when meerkat hits
[03:36] <RAOF> *Yes*
[03:36] <bryce_> and you've both definitely done enough to justify getting in :-)
[03:37] <Sarvatt> huh, never noticed this - http://cvs.fedoraproject.org/viewvc/F-12/kernel/linux-2.6-x86-64-fbdev-primary.patch?revision=1.1&view=markup
[03:37] <bryce_> I don't know if in the new scheme of things it's still expected for you to join MOTU first before applying for core-dev, but might want to think about it
[03:38] <bryce_> Sarvatt, might mention that patch to apw or send it to the kernel list
[03:38] <ScottK> It's never been required, just normal, but I think only one or two made it to core-dev direct.
[03:39] <bryce_> ScottK, ok
[03:40] <bryce_> Sarvatt, RAOF, I assume you're not MOTU yet, so would be good to shoot for that first
[03:41] <RAOF> bryce_: I've been MOTU for a number of years.  That's why you didn't have me pestering you for -nouveau uploads until it hit main :)
[03:43] <bryce_> RAOF, aha right
[03:44] <bryce_> Sarvatt, so you'll want to start by applying for MOTU - basically fill out your wiki page according to the application process, then put yourself on the next DeveloperMembershipBoard meeting, which is every two weeks.  Guessing the next one will be around Tues 13th
[03:45] <Sarvatt> bryce_: yeah I've been thinking about it a lot but I'm quite a ways away from core-dev and MOTU seems to be up in the air (it's not even listed on the DMB application page you linked anymore). thats why I was asking if there were any plans for a Ubuntu-X package set a few months ago. contributing developer seems no different than member which I already am, I was trying to decide on which packages to apply for PPU for in the future as the next st
[03:45] <Sarvatt> ep
[03:45] <bryce_> let me know when you have your wiki pages ready and I'll add my endorsement.  Would be good to get an endorsement from Timo and maybe one or two other developers you've worked with
[03:46] <bryce_> Sarvatt, yeah I'd recommend going for MOTU next, then work your way up to core-dev
[03:47] <bryce_> I don't know that we'll ever do anything elaborate with making Ubuntu-X a package set with special permissions
[03:47] <bryce_> pretty much anyone brave enough to work on X.org is probably not going to have much trouble with the general MOTU process
[03:51] <ScottK> Sarvatt: MOTU is not up in the air anymore.  It was decided at the last UDS to keep it.
[03:58] <Sarvatt> ah ok, I will take that step next, thanks for the clarification.
[03:59] <Sarvatt> the fact that it was dropped off of the developer membership board application wiki page made me think a delegated team or PPU was the next step for me now
[04:00] <bryce_> guess the wiki docs could be more clear
[04:00] <bryce_> although looks like someone has been updating them
[04:03] <RAOF> Sarvatt: Where was that agp-intel bug where drm loaded before agp had loaded agp-intel?
[04:04] <Sarvatt> RAOF: one sec, i emailed it to the kernel-team list, just gotta dig it up
[04:05] <RAOF> 'Cause it looks like a regression of bug #430694, probably another casualty of 2.6.33 drm backport.
[04:05] <Sarvatt> https://bugs.launchpad.net/bugs/542251
[04:06] <Sarvatt> it happens on radeon too in alot of bugs, search ati bugs for software rendering :(
[04:06] <RAOF> But they can't rely on agp-intel being the right agp module, so...
[04:08] <tjaalton> airlied said he'd make the agp modules mandatory (non-modules) because of bugs like these
[04:08] <Sarvatt> yeah agp modules should be built into the kernel so it doesn't happen but i dont think any of the kernel people like that idea
[04:10] <tjaalton> soon they have no choice
[04:10] <tjaalton> :)
[04:10] <tjaalton> and debian does that already afaik
[04:12] <Sarvatt> yeah thats what jcristau said
[04:14] <Sarvatt> it's going to add .006 seconds to the boot time though! :D
[04:14] <tjaalton> oh noes :)
[04:16] <Sarvatt> oh nice ati 6.13
[04:19] <Sarvatt> apw: any chance of having agp built into the kernel instead of as modules? we've got a lot of nasty bugs about it because we dont
[04:20] <Sarvatt> can get you a list if it would help, the two major ones we just linked but there are quite a few radeon ones as well
[04:36] <ScottK> Not for Lucid there isn't.
[04:39] <Sarvatt> https://bugs.freedesktop.org/attachment.cgi?id=34687 -- darn it's close, no longer crashing the server ever but quadrapassel is black until i move it so part of the window is off of the screen
[04:50] <Sarvatt> with compiz enabled it's always black :)
[05:29] <Sarvatt> hmm, what happened to http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=c5155725948be57010c4a558a1b9c5ddefb864c3
[05:30] <Sarvatt> looks like that got dropped somewhere along the line as well
[05:51] <Sarvatt> bryce_: wow that washed out DVI-VGA radeon problem got fixed fast - http://marc.info/?l=dri-devel&m=127052658905865&w=2
[07:21] <RAOF> What's responsible for ensuring the VTs have login prompts on them?  Is that getty?
[08:02] <Sarvatt> yeah
[08:03] <RAOF> Yeah?
[08:03] <Sarvatt> in response to your question :)
[08:03] <Sarvatt> we're running out of time to fix this clutter problem, ugh :(
[08:04] <RAOF> Oh, that it's getty that's responsible for login prompts?  Sweet.
[08:06] <Sarvatt> i'm having so many problems with clutter 1.2 even outside of the server crashes, i think they really expect people using it to be on xserver 1.8/mesa 7.8
[08:13] <Sarvatt> our glx 1.4 backport stuff is throwing it off, it works fine without them since it falls back to glx 1.2. it's falling back to glXGetVideoSyncSGI too (which SUCKS on intel) since GLX_SGI_swap_control stopped being advertised for some reason recently
[08:26] <Sarvatt> ok thats a relief, its just quadrapassel that sucks
[08:35] <Sarvatt> \o/ https://bugs.freedesktop.org/show_bug.cgi?id=26394#c21 fixes everything I can throw at it except it breaks quadrapassel :D
[13:09] <Sarvatt> RAOF: yeah that mbp_backlight intel ddx patch looks good, surprised it's not in there already since its been in the kernel for a few years
[13:11] <Sarvatt> i thought it was someone's hacky backlight driver thats not upstream yet so not relevant to upstream but its mbp_nvidia_bl
[13:17] <Sarvatt> yuck, publication is taking upwards of 5 hours on PPAs now
[13:25] <ricotz> Sarvatt, do you know the problem at launchpad about this delay?
[13:34] <bjsnider> ricotz, ask in the #launchpad channel
[13:36] <Sarvatt> ok clutter apps really are fixed, the black screen in quadrapassel I was seeing was just with xorg-edgers packages
[13:37] <bjsnider> ricotz, there was a merge last night that supposedly fixed a huge gnome-shell memory leak
[13:38] <Sarvatt> wish I could figure out why GLX_SGI_swap_control isn't advertised in glx extensions though, GLX_SGI_video_sync is *horribly* slow on intel and makes mutter/gnome-shell and such unusable
[13:41] <chrisccoulson> Sarvatt, i got one confirmation so far that the gnome-screensaver fix resolves the display not being restored correctly on user switching
[13:41] <Sarvatt> \o/
[13:41] <chrisccoulson> so, i will upload that today, but it will sit in the queue until after b-2 now
[13:41] <ricotz> bjsnider, yes, i saw it
[13:42] <Sarvatt> this xserver fix is pretty darn urgent
[13:42] <bjsnider> ricotz, cool
[13:42] <Sarvatt> any clutter app closing under dri2 is segfaulting the server..
[13:44] <ricotz> Sarvatt, is this clutter crash happening with edgers-ppa and lucid packages?
[13:44] <Sarvatt> both
[13:45] <Sarvatt> well i've got the fix in edgers
[13:45] <ricotz> ok, this would effect me on nouveau with 2.6.34
[13:46] <ricotz> Sarvatt, ok, but the release is pending, like in all ppa ;-)
[13:47] <bjsnider> the error that appears in this log is happening when installing nvidia-current right now: http://pastebin.com/zGe5YtEh
[14:00] <Sarvatt> bjsnider: no error in that log, i told tseliot about it the other day though.. the GUI is saying it failed but it really didn't and it works fine
[14:01] <bjsnider> yes i know, but it shouldn't say that it failed when it didn't
[14:01] <tseliot> bjsnider: can I see the output of "update-alternatives --display gl_conf" and of "ldconfig -p | grep GL" please?
[14:02] <bjsnider> tseliot, hold on, i'm acting as a middle man here
[14:02] <tseliot> no hurry
[14:03] <bjsnider> this happened to me too though, so i can contribute
[14:04] <bjsnider> in pastebin?
[14:04] <tseliot> yep
[14:06] <bjsnider> http://pastebin.com/fZhfm8VW
[14:06] <bjsnider> that's both commands on my system
[14:15] <tseliot> bjsnider: that looks good. I'll look into this issue
[14:16] <bjsnider> tseliot, this is the other guy that had the same issue a couple minutes ago: http://pastebin.com/GQJrDeJz
[14:17] <tseliot> thanks
[14:17] <Sarvatt> yeah everything looked fine and it really installed right, just that debug message made it throw up an error or something
[14:33] <BUGabundo> is there any wiki that lets us follow on the current state of which drivers work for which GPU?
[14:38] <Sarvatt> like what BUGabundo?
[14:39] <BUGabundo> Sarvatt: I have no idea which ATI drivers are there, and which cards each support
[14:39] <BUGabundo> everytime an user asks me, I just say I don't know
[14:39] <BUGabundo> which I really don't like to do :\
[14:40] <BUGabundo> also, with so many versions of nvidia blog, nouveua, nouveua 3D, bla bla
[14:40] <BUGabundo> and with the changes intel has been doing in the last two cycles, releasing cards with poor (none?) support for linux
[14:43] <Sarvatt> only things with poor support for intel are old 8xx GPU's and GMA500 that isn't really intel
[14:43] <Sarvatt> fglrx is for R600 and up (aka HD 2xxx series or newer)
[14:45] <BUGabundo> ok
[14:45] <BUGabundo> need to put that in some wiki
[14:45] <BUGabundo> I won't remember it in 15 min time
[15:16] <tjaalton> heh, so there is a driver for the waltop tablets, called linuxwaltop. seems like a fork of linuxwacom-0.8.4
[15:18] <tjaalton> so.. I'll diff it and see if it can be pushed to xf86-input-wacom
[15:21] <Sarvatt> tjaalton: only diff is the removal of the wacom vendor check line in one file afaik and they wont accept it upstream
[15:21] <tjaalton> Sarvatt: really? reference?
[15:22] <tjaalton> things might have changed now that ping doesn't own the driver anymore
[15:22] <Sarvatt> i've read it brought up on the wacom-devel lists tons of times in the past year, dont have any references offhand
[15:23] <tjaalton> ok, I'll search
[15:24] <tseliot> tjaalton: is the new mesa in place now? Do you have any further changes to make?
[15:24] <tjaalton> tseliot: haven't uploaded yet, but it wouldn't make it in beta2 anyway
[15:25] <tjaalton> that's what I was told last week
[15:25] <tjaalton> so, post-b2
[15:26] <tseliot> ok, thanks
[15:26] <Sarvatt> i think you'd need to patch it in the kernel now though
[15:26] <tjaalton> Sarvatt: that too, but it used to work with linuxwacom in jaunty
[15:26] <tjaalton> not fully though
[15:27] <Sarvatt> didn't it build an external kernel module back then?
[15:27] <tjaalton> no, stock jaunty
[15:30] <Sarvatt> http://wiki.archlinux.org/index.php/Wacom#WALTOP_tablet_support_by_the_Wacom_drivers
[15:30] <tjaalton> in karmic that made the server crash
[15:30] <tjaalton> or didn't work otherwise, can't remember
[15:42] <tjaalton> judging by the diff the vendor id seems to be the only change.. sigh
[15:43] <jcristau> and ping is naking that change?
[15:43] <Sarvatt> look at the n-trig patches to wacom, i'm sure you can hook it in the same way
[15:43] <tjaalton> jcristau: yep
[15:43] <jcristau> sounds stupid
[15:43] <tjaalton> Sarvatt: yeah it's the same spot
[15:44] <tjaalton> but the kernel driver needs changes too to make it fully functional
[15:44] <tjaalton> looks like it's a rebranded graphire
[15:47] <tjaalton> ah the kernel driver is completely new
[15:54] <Sarvatt> tjaalton: so what happens when you plug in a waltop tablet now? the stylus should at least work?
[15:54] <tjaalton> Sarvatt: nothing happens, since wacom.conf includes it :)
[15:54] <tjaalton> but the driver ignores the id
[15:54] <tjaalton> evdev would "work"
[15:55] <tjaalton> I haven't tried patching the current driver yet
[15:55] <Sarvatt> hmm fedora is matching WALTOP to wacom with no xf86-input-wacom patch
[15:56] <tjaalton> that's a leftover
[15:56] <tjaalton> pretty sure about that
[15:56] <tjaalton> they got it from us in the first place..
[15:56] <tjaalton> once someone had said that it worked ~a year ago
[15:57] <Sarvatt> the xf86-input-wacom fdi has waltop too
[15:57] <Sarvatt> ahh
[15:57] <tjaalton> oh the upstream one? that's hilarious
[15:57] <Sarvatt> i figured he removed the check
[15:59] <Sarvatt> tjaalton: did you make the udev rule make a symlink for your waltop tablet?
[16:00] <tjaalton> Sarvatt: no
[16:00] <tjaalton> those symlinks are useless now I think
[16:00] <tjaalton> aiui they were just for convenience when setting up the device via xorg.conf
[16:01] <tjaalton> in pre-hal world
[16:03] <Sarvatt> oh, i couldn't use wacom without a symlink though and thats what tripped me up first trying to convert xf86-input-wacom over, i think the driver expects it
[16:04] <tjaalton> no-one else uses them anyway
[16:04] <tjaalton> fedora doesn't ship rules at all
[16:05] <Sarvatt> weird, wonder what problem I had then, it wouldn't load the kernel module unless I had the /dev/input/wacom symlink
[16:06] <tjaalton> ah
[16:06] <tjaalton> well, loading the module made no difference
[16:07] <Sarvatt> err I meant the X driver sorry, kernel module loaded fine when it was plugged in
[16:08] <tjaalton> when was this?
[16:15] <Sarvatt> *right* after the udev support went in, back in january
[16:16] <Sarvatt> looks like its not needed now though and it does the extra device detection in the driver instead
[16:16] <tjaalton> you mean udev support in wacom?
[16:16] <tjaalton> that was late january
[16:17] <tjaalton> hmm, lots of duplicate stuff in the waltop kernel driver.. this should be forward-ported to the current hid infrastructure
[16:18] <tjaalton> the wacom driver is less than 300 lines..
[16:19] <tjaalton> waltop is ~500
[16:19] <tjaalton> well, closer to 1000 since it's split in three files
[16:20] <tjaalton> perhaps it could use the wacom driver as well, but it's hard to compare these since wacom is newer.. need to grab an older one
[16:33] <tjaalton> damnit, was looking at the wrong driver :)
[16:33] <tjaalton> the 300 lines were for the bluetooth wacom
[16:34] <tjaalton> ok this makes more sense
[16:35] <tjaalton> still, lots of renaming
[16:39] <tjaalton> sounds like a fun project to merge this stuff in the wacom kernel driver.. I'll give it a shot
[16:59] <tjaalton> meh, maybe the kernel drivers aren't mergable after all
[16:59] <seb128_> hey
[16:59] <seb128_> could somebody look at bug #554023?
[16:59] <seb128_> the guy says it's started on wednesday
[16:59] <seb128_> seems rather an xorg than gdm issue
[17:03] <tjaalton> commented
[17:04] <seb128_> tjaalton, thanks
[17:11] <ScottK> bryce_: I upgraded my 865 box and once I manually reinstalled the driver, then it works nicely.  Bug #556629 is the bug for the driver getting removed.
[17:13] <tjaalton> you had x-x-i-2.4 installed?
[17:13] <ScottK> Yes, I think so.
[17:14] <ScottK> It's the only way to make Karmic work with 865
[17:14] <tjaalton> still weird that it removed -video-all instead of pulling -intel
[17:15] <ScottK> Yes.  I think mvo should look at that case and special case it.
[17:16] <tjaalton> or should -intel Replace -intel-2.4?
[17:16] <ScottK> Pretty much anyone with 865 that's on Karmic will hit it (unless they like 800 X 600)
[17:16] <ScottK> Does it conflict now?
[17:16] <ScottK> If it does, that would probably solve it.
[17:17] <ScottK> I need to run out for $WORK meetings, but wanted to bring it to your attention.
[17:17] <tjaalton> not intel, but the xserver conflicts with every package providing the old abi
[17:17] <ScottK> Ah.
[17:35] <mvo> ScottK: thanks! I have a look now
[17:52] <ScottK> mvo: Great.
[20:27] <seb128> re
[20:27] <seb128> tjaalton, bug #554023 the submitter replied
[20:56] <Sarvatt> tjaalton: that xserver-xorg-video-intel-2.4 that guy had in a PPA had a bumped epoch. i really wish ppa-purge was automatically run during upgrades somehow instead of just disabling the sources because i get emails all the time from people upgrading from edgers to a new release with older versions than are in edgers
[20:57] <bryceh> Sarvatt, makes me wonder if people are using xorg-edgers who shouldn't be
[21:27] <BUGabundo> \o
[21:33] <Sarvatt> oh crap
[21:33] <Sarvatt> bryceh: new MAJOR symptom
[21:34] <Sarvatt> 965+ intel, gpu hang during boot, x64 arch
[21:34] <Sarvatt> i saw seb128's bug link there and put two and two together, theres huge IOMMU problems and I didn't realize we had IOMMU enabled because I was looking at the i386 config
[21:35] <Sarvatt> http://cvs.fedoraproject.org/viewvc/F-12/kernel/linux-2.6-cantiga-iommu-gfx.patch?view=markup -- need badly
[21:36] <Sarvatt> if we see someone with those symptoms, ask them to boot with intel_iommu=igfx_off
[21:37] <bryceh> Sarvatt, ok; do we have LP#'s on this?
[21:37] <Sarvatt> the workaround for broken graphics drivers kernel config option was dropped in 2.6.32, dang I wish I realized we had IOMMU enabled sooner
[21:38] <Sarvatt> here's a redhat bug - https://bugzilla.redhat.com/show_bug.cgi?id=538163
[21:38] <bryceh> why'd we enable it?
[21:38] <Sarvatt> probably did it back in karmic and it was fine back then because it picked a kernel option that made it work right with graphics but that kernel config option was dropped
[21:39] <Sarvatt> thinkpad x200's are especially hit hard with that
[21:39] <Sarvatt> RAOF must have a 32 bit ubuntu installed
[22:11] <tjaalton> Sarvatt: so the bug should be reassigned to kernel?
[22:14] <Sarvatt> well I looked into it a bit more and we are carrying all of the patches, the people still having it all are using swiotlb (meaning they have intel x64 without virtualization support or disabled) so I'm trying to dig into that more
[22:14] <Sarvatt> like https://bugzilla.kernel.org/show_bug.cgi?id=14627 except we have that fix
[22:18] <tjaalton> well maybe it was a different bug too, since this one just doesn't get the edid from vga1
[23:07] <RAOF> Sarvatt: My x200s is fine, and running x86-64.  Would disabling VT in the bios and trying to boot be an interesting datapoint for you?
[23:22] <Sarvatt> RAOF: yeah if you dont mind :D
[23:23] <kklimonda> chrisccoulson: no luck here with your gnome-screensaver
[23:23] <RAOF> Looking at that RH bug, it looks like people were having problems when VT-x was *enabled* - I have it enabled.
[23:24] <chrisccoulson> kklimonda, yeah, one person originally said that it worked and then changed their mind
[23:24] <chrisccoulson> bugger!
[23:24] <chrisccoulson> kklimonda, xtrace log would be good then, as it looks like there are 2 issues
[23:26] <kklimonda> chrisccoulson: http://pastebin.com/UNULvm57 - does it look like a proper xtrace?
[23:26] <kklimonda> if so I'll attache it to 555870
[23:27] <chrisccoulson> kklimonda, yeah, that looks ok. that is from gnome-screensaver and not test-fade isn't it?
[23:29] <kklimonda> chrisccoulson: it's from test-fade. do you want one from gnome-screensaver itself?
[23:29] <chrisccoulson> kklimonda, probably not. it shows the same issue that i thought i'd fixed yesterday
[23:29] <chrisccoulson> this is definately with the patch applied isn't it?
[23:30] <kklimonda> chrisccoulson: yes - I have your package installed and have restarted system (because I've managed to lock it while testing :/)
[23:31] <kklimonda> chrisccoulson: how can you read anything from xtrace log? it looks like nonsense to me ;)
[23:32] <chrisccoulson> kklimonda, it just shows all the raw X protocol calls. line 424 shows the issue though (the last CrtcSetGamma call)
[23:32] <chrisccoulson> there should be another call to reset it back to what it was
[23:32] <chrisccoulson> ** SetCrtcGamma even
[23:34] <chrisccoulson> ok, i'm slightly confused now
[23:34] <chrisccoulson> i can't recreate that issue with my patch :(
[23:36] <kklimonda> oh, both cores at 100% :/
[23:37] <kklimonda> and I'm wondering why do I smell something funny
[23:37] <kklimonda> htop