=== BUGabundo_NCISLA is now known as BUGabundo_TBBT
[01:14] <RAOF> tjaalton: In the mesa merge, why did you keep the “unexport LDFLAGS”?  I've test-built on amd64 without it, and it builds fine.  Was there some other subtlety that this change was fixing?
[01:53] <Sarvatt> RAOF: I believe you can nuke that, it was over a year ago and Tormod fixed it upstream afaik
[01:54] <RAOF> Yeah, I've been checking.
[01:54] <RAOF> AMD64 builds just fine.
[01:54] <RAOF> And now that we actually build the intel DRI on i386 again, it's time to find a sponsor!
[01:54] <Sarvatt> back in the mesa 7.4 days
[01:55] <Sarvatt> think it was this - http://cgit.freedesktop.org/mesa/mesa/commit/?id=9cb3cdec76b679f15c591955084bd48e91a32142
[02:08]  * Sarvatt can't wait for xrandr 1.4 to stop all these virtual screen resolution > max texture size and compiz broken bug reports
[02:09] <RAOF> Oh? 1.4 is the magical version that will fix that?
[02:10] <Sarvatt> yeah adds per-crtc pixmaps
[02:10] <Sarvatt> +   • Per-crtc pixmaps. This provides for multiple scan-out buffers
[02:10] <Sarvatt> +     which applications can create and assign to arbitrary collections
[02:10] <Sarvatt> +     of crtcs. These pixmaps can be associated with a window for use
[02:10] <Sarvatt> +     with OpenGL or drawn to directly.
[02:14] <Sarvatt> oh i totally missed the later discussion - http://www.mail-archive.com/xorg-devel@lists.x.org/msg07846.html
[02:17] <Sarvatt> ack they're uploading backported kernels to lucid? do you know if they know about how nouveau is going to be totally broken by that RAOF?
[02:18] <RAOF> Sarvatt: Yes; we discussed that at UDS.
[02:19] <RAOF> I was vaguely aware of that blueprint before, but hadn't quite twigged as to the consequences.
[02:19] <RAOF> The answer is: there shall be madness.
[02:20] <RAOF> Or, rather, that we'll do some ungodly symlink-the-appropriate-libdrm-on-boot hack.
[02:41] <Sarvatt> i guess we can drop libgl1-mesa-swx11-i686 here soon huh? :D
[02:41] <Sarvatt> noticed gcc-4.5 uses i686 as the default arch
[02:42] <Sarvatt> oh gcc 4.4 now too, nice
[02:53] <RAOF> Sarvatt: That's a good point.
[04:00] <Sarvatt> RAOF: oh wow good catch on that mesa problem, I didn't notice since I use an external debian/ with all of the gallium changes
[04:01] <Sarvatt> the i686 arch changes.. 
[04:01] <Sarvatt> actually it does affect me too, hah!
[04:02] <RAOF> Are you not testing your built packages? :)
[04:02] <Sarvatt> only popped up in the past few days since maverick is using gcc-4.4 still as default and that was just switched, looks like i915 and friends are still the old versions
[04:02] <Sarvatt> i dont think i've even built mesa since the gcc change
[04:03] <Sarvatt> looking now though
[04:03] <Sarvatt> nope it was today - Date: Wed, 19 May 2010 11:28:26 +0200
[04:03] <Sarvatt> built mesa yesterday
[04:12] <Sarvatt> ugh going to cause hell for lucid, i'll have to add more conditionals instead of just changing things
[04:12] <RAOF> We don't support lpia; why not switch on i386 arch rather than DEBIAN_HOST_GNU_CPU?
[04:59] <tjaalton> RAOF: yeah that was overlooked for some time, nice that it got dropped
[04:59] <tjaalton> I can upload mesa if it's ready
[05:00] <RAOF> Luke's got it in #ubuntu-desktop, unless you'd prefer to take it yourself.
[05:00] <tjaalton> nah that's fine
[05:32] <Bernardo> hi
[06:00] <Sarvatt> not sure what the proper method to bring in llvm is in for libgl1-mesa-dri-gallium, llvmpipe needs it to be used but its not picked up. recommends?
[06:00] <Sarvatt> doing it as a recommends brings in llvm-dev and oprofile also
[06:09] <RAOF> What requires llvmpipe?
[07:22] <tjaalton> RAOF: the swrast driver aiui
[07:24] <RAOF> Do the other drivers fall back to swrast for anything?  If so, we need it.  If not, meh.
[07:27] <tjaalton> we have the non-gallium version of it
[07:27] <tjaalton> so yes
[07:27] <tjaalton> umm, no we don't need the gallium one, but it's a lot faster :)
[07:29] <RAOF> Yeah, I've heard.
[07:29] <RAOF> But the gallium drivers don't care which swrast gets used?
[07:29] <tjaalton> actually llvmpipe is the gallium version of swrast
[07:30] <tjaalton> don't think so
[07:30] <tjaalton> and then there's softpipe, which is probably closer to swrast performance wise
[07:30] <RAOF> With the interesting converse: do users of non-gallium drivers get faster software fallbacks with llvmpipe?
[07:30] <tjaalton> it it'd replace swrast then yes
[07:31] <tjaalton> well, at least that's how I'd see it but I've no evidence of how it works
[07:31] <RAOF> Heh.
[07:32] <tjaalton> so, don't count on my words ;)
[07:32] <tjaalton> Sarvatt: probably need logs about the "didn't pick it up" part
[09:34] <jcristau> mesa should likely have used DEB_HOST_ARCH_CPU rather than the GNU version
[09:36] <jcristau> looks like this was my fault, sigh
[09:37] <tjaalton> :)
[09:45] <jcristau> hmm raof left :(
[09:47] <coz_> hey guys...anything change on lucid where we can now install the official nvidia driver??
[09:52] <tjaalton> nope
[09:54] <coz_> tjaalton,  ooo darn... do you have any information that that will change? i really dont want to go back to karmic
[09:54] <tjaalton> coz_: it won't change, lucid is released
[09:55] <tjaalton> installing the driver from nvidia.com breaks your system
[09:55] <coz_> tjaalton,  you mean in general^^?
[09:55] <tjaalton> and fills launchpad with obscure bugs
[09:56] <tjaalton> it replaces system libs and then upgrades won't work etc
[09:56] <coz_> tjaalton,  thats not the true at all.. depending on card  and who manufactured it along with system configuration...the nvidia driver offered via hardware drivers doesn always work across the board... chaning drivers  can reduce the amount cpu useage  by X  considerably... 
[09:57] <coz_> tjaalton,  thats why nouveau is not going to be any different for that matter
[09:57] <coz_> a single driver on all systems with all configurations is a pipe dream
[09:57] <tjaalton> eh, there are three blobs to choose from, depending on your card
[09:57] <tjaalton> or four, I've lost count
[09:57] <coz_> tjaalton,  thats not workable though   only one driver is current
[09:58] <tjaalton> and not current enough I take?
[09:58] <coz_> tjaalton,  well again depending on system config and video card  no  not current enough...considering that nvidia puts out beta drivers with many bug fixes  but none of those fixes make it into ubuntu for 6 months at best5
[09:58] <coz_> best
[09:59] <tjaalton> go blame them
[09:59] <tjaalton> I don't know if there are plans to update the driver
[09:59] <coz_> tjaalton,  well no   its not their fault I cant install on lucid
[09:59] <tjaalton> in lucid
[09:59] <tjaalton> it's their fault to have their release schedule
[09:59] <tjaalton> and bugs in the driver
[10:00] <coz_> tjaalton,  you mean like lucid relesing with bugs?
[10:00] <tjaalton> some bugs can be fixed
[10:00] <coz_> right
[10:00] <tjaalton> nvidia's blobs always bring new ones
[10:01] <jcristau> Sarvatt: fix in debian-unstable git for mesa's debian/rules, fwiw.
[10:57] <tseliot> coz_: I've uploaded the latest nvidia driver to lucid-proposed but it hasn't been approved yet
[10:57] <coz_> tjaalton,  ok thats cool :)
[10:57] <coz_> tseliot,  sorry 
[10:57] <coz_> tseliot,  thats cool
[10:57] <coz_> tjaalton,   sorry
[15:17] <asac> in mesa source there seem to be GLES headers et al ... are those packaged somewhere?
[15:19] <jcristau> probably not
[15:26] <asac_> jcristau: sorry had reconnect. did you say anything besides "probably not" ?
[15:26] <jcristau> no
[15:27] <asac_> why is that: "probably not"?
[15:27] <Sarvatt> because we dont ship libGLES in mesa
[15:27] <jcristau> because there hasn't been a reason to package them
[15:28] <asac_> Sarvatt: but we could produce that from that source or do we need some other source packaged for that?
[15:28] <asac_> ok so how can we get that packaged? would like to provide clutter gles packages, but i think i need this first ;)
[15:29] <jcristau> i have no idea if the ES stuff in mesa is production quality, what it's useful for, how it's built, or whatever
[15:31] <jcristau> also i don't know if there are any free gles drivers
[15:31] <Sarvatt> asac_: i'm pretty sure you are going to need the sdk libgles/egl headers for each target to build against instead of the mesa ones, that really needs looking into
[15:33] <asac_> Sarvatt: hmm. so you say the mesa ones are useless? if we move to real drivers?
[15:33] <asac_> otherwise i wonder what kind of packages to produce for "egl"
[15:34] <asac_> just libgles0-mesa* i guess
[15:34] <Sarvatt> i'm not sure, but thats the impression i'm under. mesa is going to ship libegl here soon for this wayland stuff
[15:36] <Sarvatt> egl is seperate from libgles though
[15:38] <Sarvatt> http://sarvatt.com/downloads/patches/egl.patch
[15:38] <Sarvatt> started it but haven't done much yet if you want to use any of that
[15:40] <Sarvatt> i really was under the impression you'
[15:40] <Sarvatt> re going to need to build things against the vendor sdk's headers though
[15:41] <jcristau> Sarvatt: so there's no unified ABI like there is for libGL.so.1?
[15:41] <Sarvatt> comparing the headers to the powervr now
[15:42] <Sarvatt> for egl at least it looks like there is, theres just some egl_dri2 specific stuff added to the mesa ones it looks like but gles is the one i'm not sure of
[15:46] <asac_> Sarvatt: ok so we get egl ... hmmm
[15:48] <Sarvatt> libGLES_CL.so libGLES_CM.so -- those are in the powervr sdk and not in mesa, doesn't look promising :)
[15:49] <asac_> Sarvatt: does mesa have libGLES.so at all?
[15:49] <Sarvatt> oh i could be wrong there, haven't actually built mesa libgles, thought it was libGLES.so and libGLESv2.so
[15:52] <Sarvatt> Name: glesv1_cm
[15:52] <Sarvatt> Description: Mesa OpenGL ES 1.1 CM library
[15:53] <jcristau> #elif defined(_EGL_PLATFORM_X)
[15:53] <jcristau>    const char *es1_libname = "libGLESv1_CM.so";
[15:53] <jcristau>    const char *es2_libname = "libGLESv2.so";
[15:54] <Sarvatt> src/mapi/es1api/Makefile
[15:57] <Sarvatt> configs/linux-opengl-es
[16:01] <jcristau> hmm.  docs/opengles.html.  seems it can use the dri drivers if built with --enable-gles1 --enable-gles2
[16:03] <Sarvatt> oh i'm doing everything on master, looks like theres a bunch of stuff missing in 7.8 thats in a seperate branch - http://cgit.freedesktop.org/mesa/mesa/log/?h=7.8-gles
[16:26] <Sarvatt> jcristau: thanks for fixing the mesa cpu mess, much cleaner than what I was going to do :D
[16:31] <asac_> jcristau: does that mean we could package something up?
[16:31] <asac_> with egl and gles?
[16:31] <asac_> you think you could give that a stab? i would then see what clutter says when i build it against it ;)
[16:35] <jcristau> ENOTIME
[16:35] <jcristau> i can take patches though
[16:35] <jcristau> :)
[16:36] <jcristau> but raof sounded like he wanted to work on that.  from the mail he sent to {debian,ubuntu}-x
[16:36] <asac_> thx. will talk to him
[16:47] <Sarvatt> sheesh i'm starting to like bzr more and more, bzr branch git://whatever.git works :D i pushed the mesa packaging changes to https://code.edge.launchpad.net/~xorg-edgers/mesa/packaging so other people can commit unlike http://sarvatt.com/git/cgit.cgi/mesa/
[16:54] <ripps> Hi, I'm having an issue with 2.6.34 radeon drm. I'm not sure if this is the right place to ask, but I figure you guys might have an idea what's going on. Whenever I resume from suspend Xorg fails to resume properly, instead just giving me a black screen and a mouse cursor that has glitched graphics. When I switch to a VT, I have "drm:radeon_cs_ioctl failed to schedele IB" repeating constantly. Stopping X makes them stop, but it resumes 
[16:55] <jcristau> #radeon would probably be better.
[20:36] <Bernardo> hi
=== Bernardo is now known as Bernardo|away
=== apachelogger_ is now known as darthvader
=== darthvader is now known as apachelogger
=== BUGabundo is now known as BUGabundo_Cougar
[22:25] <Sarvatt> it sure would be nice if abi breaks in xserver were required to put something in the subject about it :)
[22:31] <jcristau> i think most mention it
[22:32]  * Sarvatt bookmarks http://cgit.freedesktop.org/xorg/xserver/log/hw/xfree86/common/xf86Module.h
[22:34] <Sarvatt> looks like theres a bunch of abi bumps queued up, just want to get ready for it
[22:35] <Sarvatt> eh wait it's the abi bumps without actually bumping the version numbers that screw me up
[22:37] <Sarvatt> wow the libxfont rebuild has been queued for almost a week
[23:04] <ripps> is there an easier method to move dri-galluium/r300_dri.so to dri/r300_dri.so. Having to move and replace the file every time xorg-edgers updates is kind of a hassle
[23:05] <ilmari> dpkg-divert?
[23:08] <Sarvatt> ripps: still not sure what I want to do there
[23:08] <Sarvatt> the gallium stuff really is just for testing and it works fine with the dri-searchpath thingy outside of aiglx :(
[23:10] <Sarvatt> tormod has a seperate ppa where he builds it with gallium by default (and only r300) 
[23:11] <Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/radeon
[23:13] <Sarvatt> really would hate to start adding diverts there and risk screwing things up
[23:13] <Sarvatt> hmm maybe have libgl1-mesa-dri-gallium replace libgl1-mesa-dri and install to /usr/lib/dri?
[23:15] <Sarvatt> but then if someone removed libgl1-mesa-dri-gallium the libgl1-mesa-dri libs wouldn't be there, and ppa-purge wouldn't downgrade it
[23:18] <ripps> Sarvatt: I like that last idea
[23:19] <ripps> If dri-gallium is a marked as a replace for mesa-dri, wouldn't it then just install mesa-dri during a downgrade?
[23:19] <Sarvatt> do you know a way to make libgl1-mesa-dri be reinstalled if someone removed libgl1-mesa-dri-gallium? thats too nasty of a problem to do
[23:20] <Sarvatt> i hit this *alot* when we had libdrm-dev replacing linux-libc-dev, it would be real bad with the dri drivers hitting it
[23:20] <ripps> I honestly don't know the particulars of the downgrade system in apt as well as I should. Most devs, when asked about it, tell me not to try it :/
[23:21] <Sarvatt> it doesn't reinstall the replaced package on removal, no :(
[23:21] <Sarvatt> it would just remove the libs in /usr/lib/dri 
[23:22] <ripps> Sarvatt: is tormod's ppa in sync with xorg-edgers? or will it always take precedence over xorg-edgers?
[23:22] <Sarvatt> and it thinks libgl1-mesa-dri is still installed in that state
[23:23] <Sarvatt> no you'd have to only get mesa from the radeon ppa, xorg-edgers is usually newer
[23:23] <Sarvatt> i dont update the radeon one when i do xorg-edgers, tormod uses a different set of hooks to build those and i have too much to update as it is :D
[23:23] <ripps> Y'see, that's a problem, I want to test out all the newer xorg components, not just mesa...
[23:24] <Sarvatt> cant you just pin the mesa packages to only download from that ppa?
[23:25] <ripps> Technically, it would be easy to setup a secondary gallium ppa that depends on xorg-edgers, and than just increase the epoch on the gallium mesa package
[23:25] <Sarvatt> ask tormod to do that, thats what it is now outside of the epoch :)
[23:25] <ripps> Sarvatt: I'm not very familiar with pinning, last time I tried it I kinda screwed up my apt, is there a guide with a decent description?
[23:27] <Sarvatt> https://edge.launchpad.net/~tormodvolden -- shoot him an email and ask him to bump the epoch, it makes sense to do that
[23:28] <Sarvatt> just a matter of adding -e 1 to his auto-xorg-git invocation
[23:28] <Sarvatt> oh wait, he doesn't build that PPA against xorg-edgers, sorry about that
[23:28] <Sarvatt> thought he did..
[23:37] <Sarvatt> guess i could always just drop classic swrast and r300 and throw the gallium ones in -dri for a bit and see how many complaints we get :D
[23:37] <Sarvatt> no, bad bad idea, what am I thinking
[23:37] <Sarvatt> KMS only