[06:02] <mlankhorst> morning
[06:03] <RAOF> Yo yo!
[06:03] <mlankhorst> no luck yet, did manage to scan for all storage modes yesterday and rediscovered some missing in the enumeration :P
[06:04] <mlankhorst> need something else to do for today, any suggestions?
[06:04] <tjaalton> nouveau bugs? :)
[06:05] <mlankhorst> I mean, something not nouveau so I can focus my mind on something else then try with fresh view in a few days
[06:05] <tjaalton> server bugs then
[06:06] <RAOF> Yeah, server bugs are often good.
[06:06] <mlankhorst> hm, do we have that evdev and synaptics memory corruption sru'd yet?
[06:07] <tjaalton> it's not in quantal even
[06:07] <tjaalton> i think
[06:07] <mlankhorst> yikes
[06:07] <tjaalton> no wait
[06:07] <tjaalton> different thing maybe
[06:14] <RAOF> What was the synaptics memory corruption?
[06:14] <RAOF> Dear mesa: kindly build, love, Chris.\
[06:15] <tjaalton> RAOF: 8.0.3? builds here
[06:15] <tjaalton> or built
[06:15] <RAOF> 8.1
[06:15] <tjaalton> ahh
[06:15] <tjaalton> no comments
[06:15] <mlankhorst> RAOF: the one where X dies a slow death, or sudden death on unplug :)
[06:16] <RAOF> I think the -evdev one which was that got accepted, didn't it?
[06:16] <tjaalton> was it the silent abi change?
[06:16] <mlankhorst> yeah might, but basically all patches from xf86-input-synaptics 1.6.2
[06:16] <tjaalton> or where it looked like one
[06:17] <RAOF> I *think* it ended up being miscompiled code on i386 under certain circumstances?
[06:17] <tjaalton> yeah that
[06:18] <RAOF> tjaalton: Incidentally, do you have any idea what 101_mesa_hidden_glname.patch is *for* ?
[06:20] <mlankhorst> RAOF: do we have plans to sru synaptics 1.6.3 yet? haven't seen any reports of regressions in quantal with it
[06:21] <RAOF> It's not on my TODO list; this is something that you could usefully do today, if you wanted :)
[06:24] <mlankhorst> i want to move synaptics to 1.6.2 first, since it basically is. Only thing lacking is the 2 version changing commits.
[06:25] <tjaalton> RAOF: looks like we've lost all the history before 8.0-rc2..
[06:26] <tjaalton> oh it goes way back
[06:26] <RAOF> tjaalton: The earliest reference I can find to it is in your changelog from 7.1~rc1
[06:27] <RAOF> Although you don't seem to have known what it did then :)
[06:27] <tjaalton> neither did kyle mcmartin five years ago
[06:27] <tjaalton> in 6.5.3-1u1
[06:29] <tjaalton> so, DEP-3 has a true purpose :P
[06:29] <mlankhorst> drop it for quantal ? :>
[06:30] <RAOF> As far as I can tell that would break ABI by hiding a symbol that was previously unhidden.
[06:31] <RAOF> On the other hand, I have absolutely no idea what anyone would *do* with that symbol.
[06:36] <tjaalton> http://old-releases.ubuntu.com/ubuntu/pool/main/m/mesa/mesa_6.5.1~20060817-0ubuntu3.diff.gz
[06:36] <tjaalton> back in the golden days there was no patch-system..
[06:36] <tjaalton> being used
[06:37] <tjaalton> ah, not true. but that change was done directly to the source it seems..
[06:37] <mlankhorst> later than in dapper?
[06:40] <tjaalton> looks like I put that in a patch Feb 21st '07
[06:41] <tjaalton> and no comment about why it was there
[06:42] <tjaalton> mlankhorst: right, it was introduced in edgy
[06:42] <tjaalton> but reading between the changelog lines..
[06:42] <tjaalton> might just as well been a temporary hack that remained in the package
[06:47] <RAOF> It doesn't do anything to x86-64. I think we can probably drop it in quantal and see if anything explodes. I don't think it will.
[06:48] <tjaalton> yeah
[07:02] <mlankhorst> well, i ran dapper fine without it ;)
[07:19] <RAOF> You know what would be *totally awesome*? If make wasn't saying “no target to make depend”.
[07:28] <mlankhorst> didn't it use 'makedepend' ? :P
[07:34] <RAOF> Ah, no.
[07:35] <RAOF> It turns out that if makedepend doesn't work, it says “No rule to make target depend”
[07:35] <RAOF> Because it's GODDAMNED RIDICULOUS, that's why.
[07:39] <mlankhorst> RAOF: btw I'm still RE'ing even if to the casual observer it may look like I'm preparing synaptics 1.6.2 (just a version bump, we already have all the patches)
[07:39] <RAOF> If we've already got all the patches why are we getting the version bump?
[07:41] <mlankhorst> RAOF: shrug, there will probably be a new release at one point, i need to get my mind off reverse engineering for a bit so I can subconsciously process information and think of things you cant when staring too long :)
[07:41] <RAOF> Fair enough :)
[07:43] <mlankhorst> plus it was just merging debian and dropping the patches-that-were-commits series
[07:49] <RAOF> Fair enough.
[07:52] <RAOF> Mmm. Hardlinks.
[07:52] <RAOF> JUST TO MAKE IT MORE DIFFICULT.
[07:54] <mlankhorst> 'thou shalt not built from tmpfs with package on a real fs'?
[07:55] <RAOF> No, in this case “be careful when editing files in ./build/dri, because they're hardlinks to files in ., and different editors will break those hardlinks.
[08:00] <RAOF> GrrrrAAAAARCGH!
[08:01] <mlankhorst> I build intree with git anyhow :)
[08:02] <mlankhorst> mesa make clean is broken enough to justify using git clean instead
[08:02] <RAOF> Well, you're *required* to build mesa in-tree; out of tree builds are broken.
[08:09] <RAOF> ...that's retarded.
[08:09] <mlankhorst> there's another build system you can use too
[08:09] <mlankhorst> scons iirc
[08:10] <RAOF> Yeah, but we don't use that. And I'd be surprised if it isn't a bit broken.
[08:11] <RAOF> So, make can't seem to determine that a rule for main/api_exec_es1.c can be used to make ../../src/mesa/main/api_exec_es1.c
[08:12] <mlankhorst> I'm pretty sure out of tree shouldn't even be attempted atm unless you want to fix things
[08:13] <RAOF> That's what I'm doing now; attempting to fix things.
[08:13] <RAOF> Because we'll probably want 8.1, and that means we'll want out-of-tree to work.
[08:16] <mlankhorst> hm, where can I see the stable queue for 3.2.21?
[08:17] <mlankhorst> stable-queue.git doesn't list it
[08:19] <jcristau> probably not started yet
[08:34] <RAOF> Oh, man. Out-of-tree builds are so utterly broken.
[08:55] <tjaalton> mlankhorst: git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git
[08:55] <tjaalton> but nothing there yet
[08:55] <tjaalton> I'll add some commits though
[09:10] <mlankhorst> multi arch is funny, took a bit to figure out how to install libdrm2 amd64
[09:18] <Sarvatt> RAOF: that problem is because of galliumcore
[09:19] <Sarvatt> RAOF: dget -u -x http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/pool/main/m/mesa/mesa_8.1~git20120529.f92b2e5e-0ubuntu0sarvatt.dsc , that was the last time mesa built
[09:21] <Sarvatt> llvmcore was broken because of https://bugs.freedesktop.org/show_bug.cgi?id=49504 , now it fails with https://bugs.freedesktop.org/show_bug.cgi?id=50604
[10:07] <aissen> Sarvatt: is there a reason your cedarview ppa is private ?
[10:08] <Sarvatt> aissen: i got asked to delete it, the packages are going straight into precise in the next few days though
[10:09] <aissen> Sarvatt: alright !
[11:56] <aissen> Sarvatt: I tried it on two different hardware (D2500 and N2600), and I only have a black screen on X startup.
[11:56] <aissen> Sarvatt: will there be an updated version from the latest code drops ?
[12:05] <Sarvatt> aissen: if you're using ubuntu you need to remove vt.handoff=7 from the kernel command line to get around that, can do GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub and update-grub to do it
[12:07] <Sarvatt> sysrq-v works too, or vt switch and stop/start the dm
[12:24] <aissen> Sarvatt: thanks
[12:26] <aissen> Sarvatt: the screen is filled with garbage. Even the "kms" side doesn't work, it doesn't seem to find the right refresh rate.
[12:26] <aissen> Sarvatt: yes, I'm on ubuntu, running precise
[12:39] <Sarvatt> aissen: unity 2d or gnome fallback session instead of unity or gnome-shell
[12:40] <Sarvatt> aissen: arent these drivers fun? :P
[12:40] <aissen> Sarvatt: yeah I love that :-)
[12:41] <Sarvatt> 2d deceleration, broken GL support, but video acceleration works ok
[12:42] <aissen> Sarvatt: how can I enable unity 2d ? Isn't the problem at the modesetting level, since the display is already scrambled before X starts ?
[12:42] <Sarvatt> its scrambled on the lightdm login screen?
[12:43] <aissen> yes
[12:43] <Sarvatt> err, thats a new one
[12:43] <aissen> I could "find" unity 2d choice in lightdm, but I'm guessing this won't help much
[12:44] <aissen> let me try on the other hardware (D2500) the grub options, I'll tell you if it helps.
[12:45] <Sarvatt> aissen: are you using your own kernel? you dont have psb_gfx loaded right?
[12:46] <aissen> Sarvatt: nope, clean precise install.
[12:46] <aissen> Sarvatt: let me check.
[12:46] <Sarvatt> did you dkms the kernel patch or something?
[12:47] <aissen> hum, I installed the dkms package from your ppa - wrong move ?
[12:47] <aissen> cedarview-drm
[12:47] <Sarvatt> oh yeah
[12:47] <Sarvatt> that wont work
[12:47] <aissen> oh, ok.
[14:03] <rohan> hello.. anyone here from the x-swat x-updates ppa team?
[14:05] <mlankhorst> yes?
[14:07] <rohan> mlankhorst: I was wondering about the 295.59 nvidia driver -- has it been deliberately kept to the 259.3x version due to some issue? 
[14:08] <mlankhorst> 259?
[14:08] <rohan> sorry, 295.3x
[14:08] <mlankhorst> think there were some regressions indeed :)
[14:09] <rohan> ah.. looks that way, because even the page here http://www.nvidia.com/object/unix.html lists 295.53 as the latest
[14:10] <rohan> i hope it's resolved soon because the .53 version doesn't support my card
[14:10] <tjaalton> which is.. ?
[14:11] <rohan> PCI ID 0fd3 
[14:11] <rohan> GT 640M LE
[14:11] <tjaalton> it's up to nvidia to provide that
[14:12] <rohan> yes, I realise :) I know it's not something x-swat / x-updates can fix :) 
[14:15] <rohan> It looks like 295.59 was supposed to be a "long-lived branch release".. i can't imagine how they could release it with regressions!
[14:16] <tjaalton> there was a security fix that broke stuff
[14:17] <rohan> I see, thank you, tjaalton , mlankhorst 
[14:17] <rohan> I will wait for the next iteration 
[14:17] <tjaalton> nvidia-current is at 295.40, nvidia-current-updates at 295.49
[14:18] <mlankhorst> plus it didn't fix the gaping hole :(
[14:18] <tjaalton> ah that
[14:19] <rohan> mlankhorst: which gaping hole? [just curious]
[14:19] <tjaalton> oh now there should be 295.59
[14:19] <mlankhorst> rohan: from what i read from the patch, it seems whole io space is open to user
[14:19] <tjaalton> with support for 640m le
[14:19] <mlankhorst> now whole io space minus 100kb is
[14:20] <tjaalton> http://www.nvidia.com/object/linux-display-amd64-295.59-driver.html?ClickID=d2mtm2tsoxksbkobmcnznsx20bn22ytbcymy
[14:20] <rohan> [10:17] <tjaalton> nvidia-current is at 295.40, nvidia-current-updates at 295.49 ==> are we looking at different repos? I am looking at the x-updates PPA and the version of nvidia-graphics-drivers is 295.53
[14:21] <tjaalton> ah
[14:21] <mlankhorst> ftp://download.nvidia.com/XFree86/patches/security/CVE-2012-0946/nvidia-blacklist-register-mapping-290-295.diff
[14:21] <rohan> yes, but isn't 295.59 the one with the security hole?
[14:21] <tjaalton> it's the latest of the series..
[14:21] <mlankhorst> look at that patch.. there is no reason for userspace to map ANY register from the device in that range..
[14:22] <mlankhorst>      if (IS_REG_OFFSET(nv, NV_VMA_OFFSET(vma), NV_VMA_SIZE(vma)))
[14:22] <tjaalton> so if they all are affected then yes
[14:22] <mlankhorst> that whole branch needs to be removed if nvidia cared about security
[14:22] <tjaalton> is it fixed in 302?-)
[14:22] <mlankhorst> nope
[14:22] <tjaalton> heh
[14:23] <rohan> [10:19] <mlankhorst> now whole io space minus 100kb is ... ?
[14:23] <rohan> oh you were referring to the patch you linked? 
[14:23] <mlankhorst> yeah that was their 'fix' turns out userspace needed it so it broke on a few
[14:25] <rohan> oh this 'fix' is what's holding 295.59 up? 
[14:25] <rohan> I guess that's also why they removed it from the main download page
[14:25] <tjaalton> no
[14:25] <tjaalton> the hole is old
[14:25] <rohan> yes, but the fix is breaking userspace, like mlankhorst said, right? or am I just not following? 
[14:25] <mlankhorst> it's in all nvidia drivers ever released up to 295.40, and even there still open. :S
[14:40] <rohan> so does 295.59 fix it, and by fixing it, cause issues? or were the regressions you mentioned separate?
[14:54] <mlankhorst> i cant say since i dont look into nvidia drivers
[14:54] <tjaalton> they tried to fix it in .40, which caused issues, and at least some got fixed later
[14:54] <tjaalton> aiui
[14:55] <rohan> ah i see
[14:55] <rohan> guess my best option atm is just wait, then :) 
[14:55] <mlankhorst> there's no point in just updating for the sake of updating
[14:57] <tjaalton> right, but .59 adds support for 640mle..
[14:57] <tjaalton> and a bunch of other cards
[14:59] <mlankhorst> that's a valid point :)
[15:18] <rohan> so should i file a request or just wait?
[15:19] <tjaalton> tseliot probably has it on his todo-list already
[15:20] <tseliot> yep
[15:20] <tjaalton> :)
[15:35] <rohan> great, thank you :)