[00:00] <RAOF> No; I've got it building here on 7.8
[00:00] <RAOF> It also runs, as long as you don't ask i965g to have anything to do with it :)
[00:00] <Sarvatt> well theres a ton of new commits for them here - http://cgit.freedesktop.org/mesa/mesa/log/?h=7.8-gles
[00:00] <Sarvatt> what the heck are you using i965g for? :D
[00:01] <RAOF> there are no classic gles drivers.
[00:01] <Sarvatt> are you building gallium egl or something?
[00:05] <RAOF> Yeah.
[00:05] <Sarvatt> hmm that might be why, how are you enabling opengles?
[00:06] <RAOF> Because the egl_dri2 and egl_glx drivers only do opengl, not gles.
[00:06] <Sarvatt> --enable-gles1 --enable-gles2 --enable-gles-overlay?
[00:06] <Sarvatt> i think this is whats fixed in that 7.8-gles branch
[00:06] <Sarvatt> i see classic support here - http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.8-gles&id=136a938559452e2e4966fe4d990ad9183948868d
[00:08] <RAOF> Ah, right.
[00:09] <jg> RAOF: have you been watching freedesktop bug [Bug 28070] [Arrandale] No output (black) on eDP ?
[00:09] <ubot4> Launchpad bug 28070 in ubuntu "DSDT for laptops with smart batteries (dup-of: 30038)" [Wishlist,New] https://launchpad.net/bugs/28070
[00:09] <ubot4> Launchpad bug 30038 in gnome-applets (Ubuntu) (and 2 other projects) "SmartBattery load level not shown (dups: 5)" [Undecided,Invalid] https://launchpad.net/bugs/30038
[00:11] <RAOF> jg: I've seen it; at the moment there doesn't seem to be a resolution to the bug, other than “damnit, why must monitors always lie?”
[00:13] <jg> RAOF: they seem to be coming down to just one or two short patches, as of the last day or so.  One of them is clearly suboptimal (always tries to run at highest speed).  Either seems to work, so it looks like just the one is what is necessary, at least from my read of the conversation of the last day or so.
[00:13] <RAOF> Is this linked to a launchpad bug?  I didn't see.
[00:13] <jg> RAOF: dunno; I'm happy to enter a launchpad bug for you if that will help.
[00:14] <Sarvatt> if you do file it against linux because it's not an X related problem at all unfortunately :(
[00:15] <jg> It wasn't clear when I first ran into the problem that it was Ubuntu; I replicated on Fedora, and got Ajax and the Intel folks on the case (along with the other reports on FDO that I have been watching).
[00:15] <Sarvatt> jg: do you have an installed system yet? I can ask to have a kernel made with the patches but it wont work on a livecd
[00:15] <jg> Sarvatt: yeah, its a display driver.
[00:16] <jg> Sarvatt: I ordered another disk; it's backordered; I can dig up a USB stick, I believe, if that will do.
[00:16] <Sarvatt> the problem is in the kernel though :(
[00:16] <jg> Sarvatt: yup.  DRM bug.
[00:17] <Sarvatt> I wish it was in an X component because I could have had packages for you to test forever ago
[00:18] <jg> Sarvatt: heh; there are (a few) downsides toward fixing the insanity of the XFree86 driver nonesense.  
[00:19] <jg> among other things, only a kernel driver can ever have a chance of sanity on an oops, for example.
[00:20] <jg> Sarvatt, RAOF: should I enter a launchpad bug?
[00:20] <RAOF> jg: It's not a bad idea, particularly if it's linked to the fdo bug.  That'll make it obvious when it's fixed upstream that there's something we should pick up.
[00:21] <jg> Sarvatt: particularly annoying is that this laptop has a spashtop running fine on it; so I've seen Linux/X running on the beast...
[00:21] <jg> RAOF: ok, will do.
[00:22] <Sarvatt> checking if any of those fixes have been commited to drm-intel-next yet, we have daily kernel builds from that git tree
[00:22] <Sarvatt> nope intel git hasn't been touched in 2 weeks
[00:24] <Sarvatt> ahh I may  have found a bug about it
[00:24] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/554569
[00:24] <ubot4> Launchpad bug 554569 in linux (Fedora) (and 3 other projects) "[lucid] Blank screen with KMS on Thinkpad X201 with Arrandale (i915) (affects: 22) (heat: 150)" [Undecided,Invalid]
[00:25] <Sarvatt> they bisected it down to   drm/i915: fix pixel color depth setting on eDP
[00:26] <jg> that sounds very similar.
[00:27] <jg> but it isn't color depth, in the fdo bug.
[00:31] <jg> Sarvatt, RAOF: seems like that bug should get linked to the FDO bug, which may be related.
[00:33] <jg> Sarvatt, RAOF: the x201 and the HP 2540p are very similar machines.
[00:35] <Sarvatt> yeah, it's hard to say if its the same problem without seeing the dmesg on yours. did you enable persistant storage on the live usb you used? could mount that and check out the logs from when it failed if so
[00:36] <Sarvatt> guessing not if you used windows to make the livecd a liveusb 
[00:38] <Sarvatt> btw on your latitude XT you can just install a kernel from here until it's finally fixed in stable to use KMS - http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/
[00:45] <jg> cool; I'll probably wait until the weekend on the latitude XT, as my daughter uses it at school during the week (and has lots of homework right now).
[00:46] <jg> Sarvatt: I got Ajax the dmesg file, IIRC, somehow.
[00:46] <Sarvatt> oh nice, i'll dig through my logs to find it
[00:46] <jg> I'll attach the dmesg stuff I sent Ajax and the ROM dump to the bug I'm filing.
[00:46] <Sarvatt> jg: thanks for that
[00:48] <Sarvatt> i can build you a livecd image containing the patched kernel if we can get ahold of a patched kernel somehow :D
[00:55] <jg> Sarvatt: Bug #585651 
[00:55] <ubot4> Launchpad bug 585651 in xserver-xorg-video-intel (Ubuntu) "Cannot install on HP 2540p laptop (affects: 1)" [Undecided,New] https://launchpad.net/bugs/585651
[00:59] <jg> boy, I managed to get the number into the channel before the bot did.  Then again, launchpad seems terribly slow in my interactions with it.
[00:59] <jg> Sarvatt: I'm not so hot to trot that we shouldn't wait until we get a response back upstream; though it does look like just one of the patches is all that should be applied (and is quite tiny).
[01:00] <bjsnider> Sarvatt, are the vaapi intel bits in the lucid kernel?
[01:01] <jg> Sarvatt: I screwed up; I filed the bug against the X driver, rather than the kernel.  me bad....
[01:01] <jg> sorry.
[01:01] <RAOF> bjsnider: No
[01:01] <jg> brain not engaged...
[01:02] <RAOF> bjsnider: They're still getting discussed on intel-gfx; they're not in the *Maverick* kernel (or drm-intel-next)
[01:02] <bjsnider> what's to discuss?
[01:03] <RAOF> bjsnider: Um, it's a patch, and a very big one.  There's always something to discuss :)
[01:03] <Sarvatt> jg: no worries, already moved it and linked the fdo bug to it
[01:04] <Sarvatt> bjsnider: wont ever be in lucid's kernel
[01:04] <bjsnider> well ain't that a kick in the pants
[01:04] <Sarvatt> *might* be in maverick's though
[01:04] <jg> RAOF, Sarvatt: if the bugs are indeed the same (between the x201 and the HP), the bug is bugging quite a lot of people.  I'm surprised, though, that the x201 problem hadn't been noticed upstream, as I know keithp et. al have x201's they use for testing in Intel.
[01:05] <Sarvatt> they need to merge it here soon to be in maverick's kernel
[01:05] <RAOF> The 2.6.35 merge window is closing pretty soon, yeah.
[01:07] <jg> and ajax said he hadn't seen an eDP laptop in captivity; the x201 has been out much longer, so I suspect there may be two bugs here, with the obviously similar symptom of the panel not working....
[01:08] <jg> I reproduced this bug in Fedora beta as well.
[01:08] <jg> (in fact, that dmesg output is from Fedora).
[04:57] <RAOF> Woot!  pbuilder passes DEB_BUILD_OPTIONS through.
[07:11] <alf__> RAOF: Hi!
[07:11] <RAOF> alf__: Howdie.
[07:12] <RAOF> You'd like a libegl / libgles? :)
[07:12] <alf__> alf__: Just wondering how that is going :)
[07:13] <RAOF> I can run all the mesa GLESv1, GLESv2, and OpenVG demos locally; the packaging is pretty much done.
[07:15] <alf__> RAOF: That's great news! Thanks!
[07:15] <RAOF> While I'm here I'm going to add the raw kms drivers, too, which needs a new libdrm package.
[07:16] <RAOF> Your hardware-acceleration mileage will vary depending on what hardware you've got, though, with intel being worst.
[07:17] <alf__> :D
[07:18] <tjaalton> is it really useful to add a package for libkms? why not just ship it with libdrm?
[07:18] <tjaalton> since they depend on each other anyway, right?
[07:19] <RAOF> libkms depends on libdrm, but not visa-versa
[07:19] <tjaalton> right
[07:19] <RAOF> It's a different lib with a different SONAME, and as it's new I'd guess it's signifcantly more likely to bump SONAME than libdrm.
[07:20] <tjaalton> hmm ok
[07:20] <RAOF> Although, given libdrm-nouveau, it's possible that libdrm doesn't believe in SONAME.
[07:21] <tjaalton> well, the packaging seems done, so maybe just use it
[07:22] <RAOF> Yeah.
[07:22] <RAOF> Now just to patch the buildsystem to make it build!
[07:23] <tjaalton> heh
[07:23] <RAOF> And prod upstream to do something about the patch that I've had sitting there for a couple of months.
[07:29] <alf__> RAOF: So, when do you expect your packaging changes to be available?
[07:30] <RAOF> I hope to have them done by the end of the day, but they should be done by the end of tomorrow certainly.
[07:31] <RAOF> What PPA would you like the lucid packages to end up in?
[07:32] <alf__> RAOF: Hmm, I should ask asac about this (when I find him, as he is traveling).
[09:27] <RAOF> Let's warm this room up by building mesa 5 times again!
[09:27] <hyperair> lol
[14:12] <blue_anna> hey, I'm on lucid -- Xorg runs between 60% and 80% cpu resources on my machine -- with no video or anything going on
[14:12] <blue_anna> can you help me diagnose it
[14:13] <blue_anna> is there any way to completely disable compiz? I have video effects on none already but I think it still uses compiz
[14:15] <blue_anna> oo nvm, it is metacity
[14:15] <blue_anna> no compiz
[14:16] <blue_anna> it was firefox
[14:49] <blue_anna> ok, I have a set of apges open, that with firefox I get load averages close to 3.0 and Xorg at 60-80% and firefox just behind it .. those same pages loaded into opera gives me opera at 20-30% and xorg just under that, and a load average below 2.0 -- that's too big of a difference for it to be just buggy javascript 
[14:59] <asac> RAOF: hey ... cool. just push them to one of your ppas .... we will copy them somewhere from there
[18:00] <Sarvatt> jcristau: have you heard anything more about the pkg-config problem? would reverting http://cgit.freedesktop.org/pkg-config/commit/?id=69a7eaa6763bb0920e2b539fffbad51348d94deb be a wrong way to work around it for now?
[18:03] <Sarvatt> oh yuck it's got another nasty problem too - https://bugs.freedesktop.org/show_bug.cgi?id=28240
[18:03] <ubot4> Freedesktop bug 28240 in src "pkg-config 0.24 fails to find 'foo' if foo.pc has an empty Cflags field" [Normal,New]
[18:04] <jcristau> fdo#28240 is only with external popt aiui
[18:05] <jcristau> so, yeah, reverting 69a7eaa6763 would fix it.  or just excluding : and = (at least) from the escaped chars.
[19:35] <Sarvatt> ugh dependencies are all kinds of screwed up in xorg-edgers, added the ppa and did a dist-upgrade from a fresh install and it wanted to remove all video/input xserver-xorg-core xserver-xorg and ubuntu-desktop
[19:36] <Sarvatt> i must have metapackages removed on all my machines making that not happen
[19:47] <Sarvatt> RAOF: http://meego.gitorious.org/qemu-maemo/gles-libs
[19:48] <Sarvatt> checking out the meego release stuff and saw that
[19:48] <Sarvatt> libgles2-qemu is a library which provides the GLES2 and EGL apis for applications to build against. 
[19:48] <Sarvatt> It is a open source replacement for closed source libraries such as the SGX libraries and has been
[19:48] <Sarvatt> tested with Qt and DUI. Due to package structure, it is possible to replace with per-device type
[19:48] <Sarvatt> GLES libraries such as the SGX libraries in deployment.
[19:49] <Sarvatt> http://repo.meego.com/MeeGo/releases/1.0/core/repos/source/libgles2-qemu-1.3.0-1.1.src.rpm
[19:58] <Sarvatt> the moorestown/psb meego release isn't out yet, darn
[20:04] <micahg> is there any trick if xrandr is showing the wrong resolution for an external monitor aside from restarting x/reboot?
[20:06] <bjsnider> the broken hdmi audio issue that has been around since the nvidia 190 driver is fixed in the 256 driver
[22:01] <Sarvatt> ricotz: did you see mutter/gnome shell got a version bump in the latest packages you uploaded?
[22:03] <ricotz> Sarvatt, yes
[22:04] <ricotz> Sarvatt, i hope you dont mind when i upload your last mesa package to lucid
[22:05] <Sarvatt> i didnt because it doesnt build
[22:05] <Sarvatt> on maverick, was waiting for pkg-config to build to upload todays
[22:05] <ricotz> Sarvatt, it should build on lucid
[22:06] <Sarvatt> still on the fence on what to do with it, thinking about just reverting the commit that dropped all demos in a patch
[22:06] <ricotz> yes i saw this problem
[22:06] <Sarvatt> and leaving mesa-utils in it
[22:07] <ricotz> do you not want to go with upstream?
[22:07] <ricotz> i didnt follow this removal
[22:09] <ricotz> Sarvatt, why do you asked about g-s? i thought you "hate" it ;-)
[22:09] <Sarvatt> i use mutter from your PPA
[22:09] <ricotz> ok
[22:10] <Sarvatt> doesn't mean i dont follow what goes on in git :)
[22:12] <bjsnider> how can someone hate something as revolutionary as gnome-shell?
[22:13] <Sarvatt> run it at 1024x600 and you'll hate it too :D
[22:14] <bjsnider> why would i do that?
[22:14] <Sarvatt> thats the resolution i'm at 99% of the time and gnome-shell stinks that small
[22:15] <bjsnider> well, that's not an appropriate resolution
[22:26] <Sarvatt> ATI Catalyst™ 10.3 Proprietary Linux x86 Display Driver Revision Number: 10.5
[22:26] <Sarvatt> kaay
[22:27] <Sarvatt> packaging up fglrx-installer 8.732, anyone want to test it?
[22:28] <Sarvatt> dont want to put it straight into x-updates because i've never packaged this before, not sure i did it right
[22:30] <Sarvatt> well i uploaded it for maverick and lucid here - https://launchpad.net/~sarvatt/+archive/ppa
[22:40] <bjsnider> what do the numbers 10.3, 10.5 and 8.732 signify?
[22:40] <bjsnider> i mean how is there any difference between what it is they signify?
[22:44] <Sarvatt> they do monthly releases (10.5 is 5th month in 2010) and the 8.732 is the actual version number for it
[23:03] <bjsnider> what's the 10.3 for?
[23:14] <bryceh> march 2010?
[23:56] <Sarvatt> oh wow, can actually see the client side decorations in maverick if you switch to the dark room theme
[23:56] <Sarvatt> strange having all windows be transparent
[23:58] <Sarvatt> not too sure i like that, looks like a mess when you  have lots of windows open :D http://sarvatt.com/downloads/csd.png
[23:59] <Sarvatt> the browser being transparent is the weirdest part, hope we can control transparency level at least at some point