[00:01] <RAOF> Dandel: A change to the piglit packaging?
[00:01] <Dandel> yes.
[00:03] <Dandel> to be exact, it's two main changes ( to fix the EGL, OpenGL+EGL, GLES1, and GLES2 tests): libegl1-mesa-dev libgles1-mesa-dev libgles2-mesa-dev
[00:04] <Dandel> the last message had the missing build dependencies and then for the build command, it is missing.... -DPIGLIT_BUILD_GLES1_TESTS=ON -DPIGLIT_BUILD_GLES2_TESTS=ON
[00:05] <Dandel> this would allow one to test the OpenGL ES 2 stuff using ( as long as libegl and libgles2 is not missing upon install): piglit-run.py /usr/share/piglit/tests/all_es2tests results/es2
[00:06] <Dandel> and most importantly, EGL With desktop OpenGL support can be tested with this change: env PIGLIT_PLATFORM=x11_egl piglit-run.py /usr/share/piglit/tests/quick.tests results/x11_egl_opengl
[00:07] <Dandel> EGL W/ OpenGL support is somewhat critical to have in the test... especially since things like Wayland and desktops w/o X11 desktops require it.
[00:09] <Dandel> RAOF: ya get my message?
[00:09] <RAOF> Yes, thanks.
[00:09] <Dandel> I was just doing a quick test to see what was there, and what was not.... I also noticed that OpenCL support is missing
[00:10] <Dandel> it requires the opencl library, and headers, and then to add... -DPIGLIT_BUILD_CL_TESTS=ON to the build flags
[00:14] <Dandel> I know that OpenCL is currently not implemented to a usable state in mesa yet, so it's not exactly a huge requirement. ( However, it is still worth the a note being added.)
[00:22] <RAOF> We could certainly include the OpenCL tests; there's not much reason not to.
[00:23] <Dandel> RAOF: only 1 problem... precise, and up do not have the OpenCL library yet.
[00:23] <RAOF> ocl-icd-libopencl1 is in Raring.
[00:24] <Dandel> but it's missing from precise ><;
[00:24] <RAOF> Then we don't do opencl tests on Precise :)
[00:24] <Dandel> what about the users of the blob who want to get the vendor to behave nicely?
[00:26] <RAOF> They use their vendor drivers as normal?
[00:26] <Dandel> yes, but the executables are missing in the precise package ( bad scenario )
[00:26] <RAOF> ?
[00:26] <Dandel> i checked... the opencl tests file is there.
[00:27] <Dandel> the executables are not
[00:27] <Dandel> there's no reason not to backport it to precise ( since limited packages depend on it, and it'll let devs start picking it up sooner )
[00:27] <RAOF> I'm not sure what the problem is - the OpenCL piglit tests won't run on Precise? That doesn't seem like a huge problem to me.
[00:28] <Dandel> it's complaining about the opencl exectuables not being there.
[00:28] <RAOF> In piglit, on Precise?
[00:29] <Dandel> yes
[00:29] <Dandel> piglit-run.py /usr/share/piglit/tests/all_cl.tests all-cl-test
[00:29] <Dandel> and all output is skip
[00:29] <Dandel> Error code: Test executable not found.
[00:31] <Dandel> it'd be one thing if it had an error due to the OpenCL ICD not being installed, but sadly, I know i have mine installed.
[00:32] <Dandel> I have an ldd for libOpenCL ( provided by amd driver, but it's still a valid OpenCL provider )
[02:53] <Dandel> RAOF: about how long do ya think it'll take to see the minor fix to appear in the repo?
[02:54] <RAOF> About as long as a piece of string; they'll get in shortly after someone takes the time to get them in.
[04:21] <superm1> so on a fairly fresh mythbuntu install I keep seeing reports of this crop up: " ValueError: invalid literal for int() with base 10: 'experimental-304'"
[04:21] <superm1> it's 12.04.1
[04:22] <superm1> with jockey 0.9.7-0ubuntu7.4
[04:24] <superm1> i see bug https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/1047681 was supposed to add support experimental flavors, but i'm on the latest version and still seeing that (http://paste.ubuntu.com/1371747/) http://paste.ubuntu.com/1371748/
[04:27] <superm1> oh but that's actually an old report that kept getting triggered but not uploaded for whatever reason i think, maybe before the new jockey was installed
[04:27] <superm1> i'll purge reports and keep an eye if it crops up again
[08:25] <mlankhorst> morning
[08:27] <tjaalton> same
[08:46] <tjaalton> updating -intel git
[08:47] <mlankhorst> sure
[08:47] <tjaalton> thinking about a ubuntu-next branch for mesa
[08:47] <tjaalton> or such
[08:47] <mlankhorst> bit too soon, it will only become easier with all the new autopackaging..
[08:48] <tjaalton> what is?
[08:48] <mlankhorst> well more autotools fixes :)
[08:48] <tjaalton> it would have git master. ah
[08:49] <tjaalton> hmm xserver has ubuntu+1
[08:50] <mlankhorst> just split off ubuntu-raring for stable?
[08:50] <tjaalton> nah
[08:50] <tjaalton> hmm
[08:51] <mlankhorst> but we need libdrm 2.4.40 for next branch
[08:51] <tjaalton> guess that's doable
[08:51] <mlankhorst> waiting for experimental acceptance..
[08:51] <mlankhorst> so I can syncpackage it
[08:52] <tjaalton> oh right
[08:52] <tjaalton> sure
[08:52] <mlankhorst> jcristau: do you have the .dsc and diff btw? patience is running out :D
[08:53] <jcristau> i posted the url on #d-x when i uploaded
[08:53] <tjaalton> http://ftp-master.debian.org/new/libdrm_2.4.40-1.html
[08:53] <tjaalton> hmm not that
[08:54] <tjaalton> mlankhorst: http://people.debian.org/~jcristau/libdrm/
[08:55] <mlankhorst> ah thanks
[08:56]  * mlankhorst syncpackage --force
[08:57] <tjaalton> you could've also just uploaded a -0u1
[08:57] <tjaalton> just like the current version is
[08:58] <tjaalton> manual syncs are not encouraged
[08:58] <mlankhorst> aye but I wanted to test how syncpackage worked :)
[08:58] <tjaalton> that's not how it's supposed to be used :)
[08:58] <mlankhorst> aw
[09:00] <mlankhorst> ok uploaded xorg-server renamed for some version of xorg-server
[09:00] <tjaalton> it's hard now that debian is frozen
[09:00] <tjaalton> to make use of syncpackage..
[09:02] <mlankhorst> guess I should start uploading lts-raring soon when I confirm quantal works
[09:43] <mlankhorst> yay, installing libcogl-dev or libclutter-1.0-dev wipes the lts stack..
[09:46] <mlankhorst> should I make the unrenamed mesa-dev packages installable with the renamed stack just in case?
[09:46] <tjaalton> why?
[09:47] <mlankhorst> they depend on libgl1-mesa-dev (>= 7.1~rc3-1~)
[09:47] <tjaalton> shouldn't be needed if the renamed one provides libgl1-mesa-dev
[09:47] <mlankhorst> and versioned provides is a pita..
[09:47] <tjaalton> oh right
[09:50] <mlankhorst> it would be ugly though, but I see no other choice..
[09:50] <tjaalton> maybe ask on #u-d first
[10:27] <mlankhorst> tjaalton: to be fair it shouldn't break anything if it ends up compiling :-)
[10:34] <tjaalton> mlankhorst: lost the context.. :)
[10:42] <mlankhorst> I mean if I use the unrenamed mesa-dev packages it should still work
[10:46] <mlankhorst> only way it could fail would be on static linking
[10:54] <mlankhorst> and that would break anyway :)
[13:09]  * hyperair pokes Sarvatt 
[13:10]  * hyperair wonders if anyone has had any luck with Steam, intel and BadMatch
[13:13] <mlankhorst> verrrrry specific
[13:14] <hyperair> yeah well, if it works, it works, if it doesn't, it doesn't.
[13:15] <hyperair> BadMatch, major opcode is 153
[13:15] <hyperair> appears to be GLX
[13:15] <hyperair> minor opcode is 26
[13:15] <hyperair> i don't know what that is
[13:15] <hyperair> where can i look this up?
[13:16] <jcristau> in the glx spec
[13:17] <hyperair> jcristau: www.opengl.org/registry/doc/glx1.4.pdf <-- this?
[13:17] <jcristau> 26 is GLXMakeContextCurrent
[13:18] <jcristau> that would probably work too.
[13:18] <hyperair> hmm i don't see op codes in this thing =\
[13:18] <hyperair> i do see GLX functions though
[13:18] <hyperair> thanks
[13:18] <jcristau> http://cgit.freedesktop.org/xorg/proto/glproto/tree/glxproto.h#n2152
[13:19] <hyperair> hmm, http://www.opengl.org/sdk/docs/man2/xhtml/glXMakeContextCurrent.xml..
[13:19] <hyperair> BadMatch is generated if draw and read cannot fit into frame buffer memory simultaneously
[13:19] <jcristau> the spec (or reading the mesa and xserver code) should tell you when that's allowed to return badmatch.
[13:19] <hyperair> this sounds potentially the issue.
[13:21] <hyperair> jcristau: sandy bridges use shared memory, right?
[13:21] <hyperair> is there some way to increase the amount of memory it can get, or something?
[13:22] <jcristau> no
[13:22] <jcristau> other than maybe putting more ram in the box
[13:23] <hyperair> there's 8G in this box =\
[13:23] <jcristau> then that's not the issue
[13:23] <hyperair> hm.
[13:50] <mlankhorst> ok I think I can push the raring stack now as well, I fixed the command up
[14:31] <mlankhorst> tjaalton: can you do the uploads for https://bugs.launchpad.net/ubuntu/+source/x11proto-randr/+bug/1081122 ?
[14:32] <mlankhorst> I would imagine you need to add a new changelog entry with a lower version than quantal for the sru, just in case they'd need to roll back.
[14:42] <tjaalton> sure, when i get back home
[14:52]  * penguin42 is seeing something he's never seen in >20 years of playing with X and could do with some hints; I've got a Thinkpad w520 - mixed Intel/NVidia machine, running Quantal; now I realise Optimus is odd; but I'm not seeing the external monitor in xrandr, but /proc/fb shows it (via fbset), and nouveau shows it in Xorg.0.log - so if it's shown in both of those how can xrandr not see it?
[14:54] <mlankhorst> penguin42: because it's driven by nouveau, and it's not a supported config until x1.14 (hopefully!)
[14:56] <penguin42> mlankhorst: so nouveau has explicitly decided not to tell xrandr about it? Just seems odd sincethe log shows it's probing the output, associated a screen with it etc
[14:57] <mlankhorst> penguin42: any output on xrandr --listproviders ?
[14:57] <penguin42> Provider 0: id: 165 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 1 name:Intel
[14:57] <penguin42> Provider 1: id: 102 cap: 0x5, Source Output, Source Offload crtcs: 2 outputs: 5 associated providers: 1 name:nouveau
[14:57] <penguin42> hmm
[14:58] <mlankhorst> DRI_PRIME=1 glxgears, congrats you got nouveau working, still no output support though :P
[14:59] <penguin42> mlankhorst Sorry, can you just explain that line
[14:59] <mlankhorst> multiple graphics card never worked before, so the fact it's even working at all is definitely some progress..
[15:01] <penguin42> true; what surprises me though is since the kernel was actually driving the nouveau display (it had the boot progress screen on previously), and since /proc/fb shows it, why wouldn't it just leave it enabled and let it render to it
[15:02] <mlankhorst> because x has no support for that yet, if you know C and want to help out however...
[15:03] <penguin42> mlankhorst: Maybe at the weekend, I could do (although my list of bugs to fix first...); OK, I'd just assumed X would be able to use anything it had a framebuffer for
[15:06] <penguin42> I guess I should try bumblebee or something 1st
[15:10] <penguin42> for ref; this is 12.10 with the bios set to optimus mode; in 'discrete' mode it hangs solid ( a cow-orker had 12.04 work successfully in discrete mode)
[15:12] <mlankhorst> lot of activity in nouveau recently
[15:13] <penguin42> yeh, good to see - is it worth my trying edgers?
[15:13] <mlankhorst> could try
[15:13] <mlankhorst> but no guarantees
[15:13] <penguin42> sure
[15:14] <penguin42> ok, thanks for your help; if I find something that works I'll come back and say
[17:44] <bryce> mlankhorst, 1080808 looks to me like just a kernel regression, what do you think?  Something we should care about or should I bump it over  to the kernel team's queue?
[17:46] <mlankhorst> bug 1080808
[17:46] <mlankhorst> ty
[17:47] <mlankhorst> fun fun
[17:47] <mlankhorst> keep against xxv-nouveau
[17:47] <bryce> ok
[17:48] <mlankhorst> I don't  think the kernel team does nouveau development
[17:55] <bryce> mlankhorst, no but they can walk folks through testing mainline kernels and/or doing git bisection
[17:55] <bryce> however if it's an issue we should care about, we should keep it against X, since things sometimes fall through the cracks if filed against the kernel
[17:56] <mlankhorst> bryce: yeah 3.7 has the massive rewrite
[17:57] <mlankhorst> so if they can do update to nouveau git tree first to check
[17:59] <bryce> mlankhorst, he says it's been happening since quantal beta2, which would predate the 3.7 change
[17:59] <bryce> maybe he's experiencing two separate bugs
[18:00] <mlankhorst> also forged alliance works fine with mesa 9.0 fixes
[18:00] <mlankhorst> but still dead slow :P
[18:09] <bryce> mlankhorst, ok tomorrow remember to do some triaging at http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-raring-workqueue.svg.  There's probably only going to be a couple bugs filed so far.
[18:11] <mlankhorst> bryce: yeah I saw like 3 bugs when I looked at it today
[18:11] <mlankhorst> so got some work done instead
[18:11] <mlankhorst> at least last i checked i was on tuesday
[18:12]  * bryce nods
[18:25] <bryce> yeah there won't be much this early on, but I've learned if we keep the queue tamped down here early on, it'll help keep the queue better under control down the road in a few months.
[18:26] <mlankhorst> I'm actually on precise still
[18:26] <mlankhorst> with wayland from raring renamed installed
[18:27] <mlankhorst> and mesa 9.0.1
[18:27] <mlankhorst> + fixes I want to push
[18:32] <mlankhorst> but ok, qa passed, so fixes pushed to 9.0 branch
[19:01] <tjaalton> mlankhorst: so what needs uploaded and from where?
[19:01] <tjaalton> don't see any git branches
[19:01] <mlankhorst> x11proto-gl, dri2, randr
[19:01] <mlankhorst> just take quantal version, add a lower version number, upload to precise
[19:16] <tjaalton> done
[23:02] <Dandel> RAOF: there's going to be a bit of an issue on the piglit builds... the eglext.h needs updating with the changes that happened in the last 24 hours.
[23:03] <RAOF> Heh.
[23:04] <Dandel> i figure it'd be good to know this before the daily autobuild shows the issue.
[23:04] <Dandel> also, i see a small branch with changes to the piglit builder set... although, I don't see where the code is kept for the waffle library.
[23:19]  * bryce waves to RAOF 
[23:19] <RAOF> Good morning!
[23:20] <RAOF> Slash afternoon :)
[23:20] <bryce> :-)
[23:21] <bryce> working on getting verification done for fglrx-experimental-9.  Darn AMD dropped hw support for my card, so had to build a new system.  almost done.
[23:21] <Dandel> fun.
[23:22] <Dandel> bryce: i know whay ya mean... i have two cards i can't use for testing with amd driver due to the fact they outright blacklist radeon.
[23:23] <RAOF> bryce: :(
[23:24] <RAOF> Intel took back my Haswell desktop SDP, so I now no longer have a box with enough power for my Radeon 7870.
[23:25] <Dandel> RAOF: i could possibly help with this... I have two different boxes with amd gpus that *are* still supported.
[23:26] <bryce> RAOF, yeah fortunately I had rebuilt my file server from scratch this year, and had spare parts with enough oomph to drive my 7850
[23:32] <Dandel> bryce: toy around with any of the a-series systems yet? ( like the a6 apu found in many laptops )
[23:33] <bryce> Dandel, nope
[23:34] <Dandel> ah... just was wondering... I'm probably one of the few devs to use one... although i'm disappointed in how the hybrid graphics work ><;
[23:34] <RAOF> Dandel: I'd quite like to; problem is that I'd need to buy one, which means I'd want a high-end one, and Intel stomp the AMD processors on the high-end.
[23:36] <Dandel> RAOF: That may be the case, but AMD is more of a budget system, and frankly... I see reasonably good performance even on the a6-3400m i use on my laptop 
[23:37] <Dandel> anyways, in the lower end, amd is stomping intel across the board ( namely sub-$300 range for cpu/motherboard/ram/video card)
[23:44] <Dandel> RAOF: do ya run the piglit tests often on the amd gpus by any chance? ( using both mesa and binary driver ) ( I'm wondering since the piglit test suite also appears to be a good measure for stability )
[23:46] <RAOF> Not often, no. I have in the past, when I was fiddling with mesa and adding piglit tests.
[23:51] <Dandel> I see... I know someone who's been running piglit on amd cards for a while now.
[23:51] <mlankhorst> RAOF: want to approve x11proto-* in precise queue? :P
[23:58] <mlankhorst> after that it should be possible to upload the entire x stack
[23:58] <RAOF> Urgh. Our previous x11proto-randr had the per-crtc pixmap proto stuff that got dropped in it.
[23:59] <mlankhorst> ..?