[00:23] ScottK: But that could be carried as a patch in natty, though, right? [00:24] pretty sure he means rewriting the detection mechanism to not use the gl renderer string is whats too invasive, just changing GEM to Intel wouldn't be invasive at all [00:25] Why use GEM in the first place, though? :/ [00:26] same reason its using driver date in the blacklist files.. craziness [00:26] Well, that's *also* going to break now that the driver date is removed :) [00:27] I've some sympathy with the “GL strings are part of the ABI, you shouldn't change them in a stable release” point of view, though. [00:30] it was removed from mesa 7.9.2 :( [00:30] (also) [00:32] wine does a lot of things based on the gl renderer string too, I hope its not broken in special ways also [00:33] How much wine works on Intel, anyway? [00:35] works great unless you're on amd64 at the moment :) [00:36] good old https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/755720 [00:36] Launchpad bug 755720 in mesa (Ubuntu) (and 1 other project) "32 bit dri drivers cannot find libdricore and libglsl (affects: 2) (heat: 14)" [High,Fix released] [00:38] ok good wine doesn't care about GEM or driver date [00:38] ./dlls/wined3d/directx.c: if (strstr(gl_vendor_string, "Intel(R)") [00:38] ./dlls/wined3d/directx.c: /* Intel switched from Intel(R) to Intel® recently, so just match Intel. */ [00:38] ./dlls/wined3d/directx.c: || strstr(gl_renderer, "Intel") [00:38] ./dlls/wined3d/directx.c: || strstr(gl_vendor_string, "Intel Inc.")) [00:39] comments off, only GM45 uses Intel® instead of Intel(R) [01:34] Anybody have any idea why proprietary nvidia has such bad tearing in Natty, it's alot worse than it was in Maverick [01:35] there isn't any tearing in natty [01:37] the only time tearing would have been an issue in maverick is if metacity was being used instead of compiz, since metacity has always had tearing and compiz syncs to vblank [01:44] bjsnider: I'm using Natty, I know that my vdpau videos have serious tearing, even when I have compiz to redirct fullscreen, vsync, and force refresh to 120. [01:44] forget about vdpau for a minute. is there tearing on the desktop? [01:44] do regular windows tear? [02:09] ripps: Refresh to 120Hz? Is that actually your refresh rate? [02:45] RAOF: no, but I read from a couple of sources that improves things, and things do seem alot smoother than when it's just 60. But the compiz refresh rate doesn't seem to affect vdpau whatsoever [02:46] Do you have two monitors? I hear that nvidia won't actually vsync on *either* monitor until you set the primary monitor with a crazy env variable. [02:47] RAOF: yeah, I don't think desktop tearing is too bad, not that I'd care if it was. I only use one monitor. And I already tried specifiying in my nvidia-settings.rc that I want DFP-0 to have vsync priority [02:48] it sounds like you've already tried every possible fix, even some that haven't been invented yet [02:49] VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-0 ? [02:51] RAOF: yep, I have that in both my .xsessionrc and .gnomerc [02:52] I've discovered that by enabling/disabling "copy to texture" plugin in compiz will temporarily fix/improve vdpau tearing [03:04] RAOF: Sarvatt is correct. Changing kwin would be too invasive and such a patch doesn't yet exist anyway. I think our only hope for Natty is to add the dropped string back. [03:05] It's tested to work and seems low risk to me. [03:05] Do you see any harm in it? [03:07] It could potentially confuse code that's expecting the new string on mesa 7.10.? [03:07] It would be easy to change the string that kwin's looking at; drop GEM and replace it with Intel. [03:08] (I mean, in kwin) [03:08] That's a change with more restricted possible side-effects. [03:09] Can we just add the old string back without dropping the new? [03:09] But! It's entirely possible that *other* code is checking for ‘GEM’, which might make reverting the mesa string better. [03:10] I guess we could concatenate the strings. That looks like it should work for kwin. [03:10] I don't know which is best, but if I read the bug correctly, Intel broke the ABI, so that's the logical place to fix it. [03:10] If that would work, then I'd say that's likely best. [03:20] Heh. “Not only did this contain lies, it contained lies that wouldn't be useful even if true.” [03:27] - if (strstr((const char *)renderer, "GEM")) [03:27] + if (strstr((const char *)renderer, "Intel")) -- that was a change for kwin I was suggesting that wouldn't be invasive [03:30] but either way works, i'll just put a patched kdebase-workspace in xorg-edgers for the people using KDE I guess [03:35] http://sarvatt.com/downloads/patches/kdebase-workspace.patch [03:41] sarvatt: Which place do you think it's best to fix in for 11.04? Mesa or kdebase? [03:43] yofel_: ^^^ [03:43] I think the biggest question is what else might have depended on that. [03:44] IIRC kees has an unpacked copy of the archive he can grep through all the source code with. [03:44] RAOF: You might ask him to check. [03:46] So, we've only been testing with the new string since early March. [06:54] urg http://web.archiveorange.com/archive/v/NG4bEpKZYXhax5O0z7gm [06:57] There's a testcase for that? [06:58] Neat! [06:59] Yup, there it is. === yofel_ is now known as yofel [16:55] bryceh, ping [17:04] bryceh, unping [17:35] * yofel fetches his eeePC and tries that kdebase patch [17:53] yofel: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/753370/comments/9 [17:53] Launchpad bug 753370 in mesa (Ubuntu) (and 1 other project) "No Desktop Effects in Kubuntu 11.04 Beta1 (affects: 9) (dups: 2) (heat: 54)" [Medium,Confirmed] === schmidtm_ is now known as schmidtm [18:52] Sarvatt: sorry, was busy, that patch seems to work for me too [20:51] Sarvatt: about bug #753370: wouldn't it be safer to just revert the commit that changes the renderer string? [20:51] Launchpad bug 753370 in mesa (Ubuntu) (and 1 other project) "No Desktop Effects in Kubuntu 11.04 Beta1 (affects: 9) (dups: 2) (heat: 56)" [Medium,Confirmed] https://launchpad.net/bugs/753370 [20:52] I've tested this patch which works fine: http://bugsfiles.kde.org/attachment.cgi?id=58999 [20:53] debfx: I wasn't really proposing the kdebase-workspace for the distro, someone else must have flagged it with patch. just uploaded it for the PPA because reverting the string changes from mesa 7.11 is not going to happen [20:53] for kubuntu there is no situation where Intel being in the renderer string doesn't have DRI2 in use though [20:54] but I can see them not wanting it that way in upstream kwin because they have to support older mesa releases and such [20:54] Sarvatt: kde will change the driver feature detection in 4.7 so this will only be an issue in natty [20:55] 4.7 is coming out in june? [20:55] thats about when 7.11 will hit oneiric [20:56] ah cool the timelines do line up good [20:59] yep [23:05] debfx: yeah s/GEM/Intel/ isn't the way to go for sure and it'll just have to be a hack added to xorg-edgers until KDE 4.7 comes around since it ships mesa 7.11, indirect is OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile x86/MMX/SSE2 and would still pass the direct check [23:10] Sarvatt: adding the GEM string wouldn't be an option? [23:40] sarvatt: Oh? What breaks then? [23:43] RAOF: could you sponsor my debdiff on bug #753370 [23:43] Launchpad bug 753370 in mesa (Ubuntu) (and 1 other project) "No Desktop Effects in Kubuntu 11.04 Beta1 (affects: 9) (dups: 2) (heat: 58)" [Medium,Confirmed] https://launchpad.net/bugs/753370 [23:44] debfx: No, sorry - no main upload priviledges :/ [23:45] oh, okay [23:46] I've made that change locally but haven't tested it properly. [23:49] at least on my system the blur effects works again after that change