[02:33] <Sarvatt> http://sarvatt.com/git/cgit.cgi/mesa/ is a start for now :D
[03:19] <Sarvatt> ok think libgl1-mesa-dri-gallium is all set to go - http://sarvatt.com/git/cgit.cgi/mesa/
[03:21] <Sarvatt> package description wording needs some work but oh well :)
[03:29] <Sarvatt> now to spend a year test building
[04:09] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/539772 is starting to be the new intel lid close hang bug with tons of duplicates :)
[04:09] <ubottu> Ubuntu bug 539772 in xserver-xorg-driver-ati "Lucid 2.6.32-16 crashed to login screen - miCopyRegion" [Unknown,Confirmed]
[04:09] <Sarvatt> finding lots of dupes all over the place
[04:10] <__mikem> hey Sarvatt what sort of "infrastructure" were you refering to with that PPA package?
[04:11] <Sarvatt> i need to decide how to package gallium stuff properly first before i dig into vmwgfx
[04:12] <__mikem> oh
[04:12] <Sarvatt> is there no howto on google for building vmwgfx?
[04:12] <__mikem> I loath building stuff from source with a passion
[04:22] <Sarvatt> i think i found the most useful backtrace ever - http://launchpadlibrarian.net/43423955/ThreadStacktrace.txt
[04:22] <__mikem> Sarvatt: what will that tell you?
[04:27] <rafiyr1> So cute, I'm tempted to print it and hang it on the wall.
=== ubott2 is now known as ubottu
[10:52] <tormod> so are clutter apps broken on all non-KMS drivers now?
[10:56] <tormod> clutter seems to be built on sand
[10:56]  * tormod wonders why we use clutter in 10.04
[11:04] <RAOF> tormod: Wait, what!
[11:06] <tormod> Failed to initialise clutter: Unable to find suitable fbconfig for the GLX context
[11:06]  * RAOF thinks we use clutter in 10.04 because no-one's written a good 2D-accelerated animation framework yet.
[11:07] <tormod> we shouldn't use animation then until the graphic stack is ready :)
[11:07] <RAOF> Sadly, history suggests that the graphics stack won't be ready until we've been breaking it with animation for a release or so :)
[11:07] <tormod> or just declare that we only support ati/intel/blobs :->
[11:08] <RAOF> tormod: What driver are you using?  I thought Sarvatt had tested a non-DRI2 driver.
[11:08] <tormod> savage, worked until yesterday's xserver fix
[11:09] <RAOF> tormod: Want to try my fixier fix?
[11:09] <tormod> sure
[11:10] <RAOF> https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa
[11:10] <jcristau> tormod: arguably, non-kms drivers aren't part of the graphic stack anymore
[11:10] <RAOF> It'll need a version bump or manual install; it's now been superceded by the new xserver.
[11:11] <RAOF> jcristau: That's a pretty aggressive deprecation schedule :)
[11:12] <jcristau> RAOF: you're saying there's stuff outside of intel/ati/nvidia that's still relevant?
[11:13] <RAOF> jcristau: None that's current, certainly.
[11:14] <RAOF> We probably need to make it explicit what old hardware we really care about, though.
[11:16] <RAOF> We need to be somewhere between “eh, it's old hardware, it doesn't matter if we break it” and “no hardware that was once supported will ever lose support”, and I think we need to make that decision conciously.
[11:18] <vish> folks, the new_poll=0 quirk for rv515 and rv535 is not a complete fix , it just seems to delay the occurrence of problems by about 5-6hrs
[11:19] <vish> alteast in rv515 that is , the problems happen in 5-6 hrs ^
[11:21] <tormod> RAOF, same error with u7~xtesting~dri2fixes
[11:22] <tormod> granted savage is a special case and recently got some extra patches so it just worked (until now)
[11:22] <tormod> but does clutter work on other DRI1 drivers now?
[11:23] <RAOF> It *should* work with dri2fixes.  Or, at worst, should crash when you close the window.
[11:24] <RAOF> Because dri2fixes was u5, with the patch that caused the leak dropped + a patch to prevent the crash, which only changed the DRI2 code.
[11:26] <jcristau> the crash on closing the window was in dri2 stuff.
[11:26] <tormod> I can go back to -u5 just to confirm it
[11:27] <RAOF> tormod: That might be nice, maybe?
[11:28] <RAOF> Oh, poot.  That stupid kernel bug has flipped my hdd read only.
[11:33] <tormod> bollox I get same error on -u5, so I guess it is just savage then, thought I had it working once though...
[11:33] <tormod> have to say that lucid is not very useful anyway on this laptop, because of the gbloat
[11:34]  * tormod looks for LXDE
[11:35] <jcristau> you could try to figure out why it doesn't like savage's fbconfigs i guess
[11:35] <jcristau> s/it/clutter/
[11:35] <tormod> I think knarf did that, and we added his patch
[11:37] <tormod> http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/103_savage-expose_fbmodes_with_nonzero_alpha.patch;hb=ubuntu
[11:41] <tormod> hmm he notes in the bug report savage users have to use 24bit
[11:41] <tormod> and apparently 16bit is default
[11:50] <tormod> woohoo quadrapassel works on 24bit
[11:51] <tormod> maybe we need to release note this
[11:51] <tormod> I am not so sure defaulting to 24bit on savage is a good idea, it was set to 16bit for a reason
[11:57] <tormod> RAOF, when forcing 24bit, -u5 works fine, ~dri2fixes crashes after some time
[11:58] <tormod> (only the app crashes)
[11:59] <RAOF> Thanks.  Was that what changed?  Does -u5 work with 16bit?
[12:00] <tormod> no with 16bit (default) neither -u5, drifixes, u7 work
[12:01] <RAOF> Ok.
[12:02] <RAOF> There's probably some more evil lurking in the DRI1 + GLX 1.4 codepath.
[12:02] <tormod> and likely bugs in savage mesa
[12:02] <tormod> (quadrapassel:4076): Clutter-WARNING **: The required ID of 1060953 does not refer to an existing actor; this usually implies that the pick() of an actor is not correctly implemented or that there is an error in the glReadPixels() implementation of the GL driver.
[12:02] <RAOF> It's a non-stop cavalcade of lightly-tested code!
[12:03] <RAOF> That's the dri2fixes error?
[12:03] <tormod> yes
[12:03] <RAOF> I suspect I know how to fix that.
[12:03] <tormod> it starts out with a couple of:
[12:03] <tormod> (quadrapassel:4076): ClutterGLX-CRITICAL **: Unable to make the stage window 0x3c00040 the current GLX drawable
[12:04] <RAOF> Yeah, but *everyone's* clutter gives that CRITICAL warning :)
[12:04] <tormod> looks good ;)
[12:15] <tormod> with -u7 it spews a lot of messages, but does not crash
[12:40] <jcristau> there's no dri1 + glx 1.4...
[12:41] <jcristau> dunno what raof was talking about there
[12:41] <tormod> I think he meant using DRI1 when the rest of the stack is reworked for GLX1.4
[13:01] <ricotz> tormod, hello, is the new gallium packaging change the solution for 10.10?
[13:10] <ricotz> tormod, "/usr/lib32/dri-gallium" should be added to "confflags-dri" for i386 compatibility, so it will be possible to patch the ia32-libs
[13:44] <bjsnider> Sarvatt, nvidia has released a driver that supports x-server 1.8
[13:59] <tormod> ricotz, I don't know if any gallium drivers will be ready for 10.10 but maybe r300g
[13:59] <tormod> but xorg-edgers will make sure people can test it
[13:59] <tormod> yes, we can add the lib32 path
[14:01] <tormod> some people have been testing r300g in our radeon gallium ppa since a few weeks and it looks pretty goof
[14:01] <tormod> *good :)
[14:03] <ricotz> tormod, ok, or perhaps another solution would be to add a ia32-libs-mesa-dri-gallium package to edgers mesa instead of patching ia32-libs with the same split package
[14:07] <tormod> ok, I am clueless about 64-bit compatibility, I never had such hw
[14:07] <ricotz> this is only for compatibilitly issues with precompile gl apps like googleeath, ...
[14:08] <ricotz> tormod, what is the reason of splitting out gallium to a new deb?
[14:09] <tormod> so that we can easily ship gallium and classic drivers from the same build and repo
[14:10] <ricotz> ok, so i think it is better to provide 2 independent debs, which wouldnt required the path juggling
[14:10] <tormod> in the radeon gallium PPA I have been shipping both in one package, for people to play with LIBGL_DRIVERS_PATH, but that's not n00b-friendly enough
[14:10] <tormod> and have them conflict against each other?
[14:11] <ricotz> yes, and the gallium package would provide the real mesa package name
[14:11] <tormod> I find the path juggling rather elegant :) but again I have experience with 64bit stuff
[14:11] <tormod> *no experience
[14:12] <ricotz> ok
[14:13] <tormod> hmm I wonder if the conflicts would confuse people
[14:13] <ricotz> this make it a bit harder patching ia32-libs, but its possible
[14:14] <tormod> anyway with the current way, we should also add some depends and stuff so that reverting from xorg-edgers etc does the right thing
[14:15] <ricotz> the mesa package is full of conflicts ;-)
[14:15] <ricotz> ok, i will do some changes to ia32-libs
[14:17] <tormod> good. I will your suggestion in mind though, I am not against it
[14:19] <ricotz> tormod, i will adapt ia32-lib to the current packaging in edgers, but the path addition is needed get it to work
[14:39] <tormod> ricotz, uploaded with path addition now
[14:43] <ricotz> tormod, taking a bit longer here ;-)
[14:54] <hyperair> so i hear we can now use intel gallium3d drivers..
[14:55] <hyperair> is it faster or slower than conventional intel?
[14:56] <Dr_Jakob> hyperair: slower, and i965g wont work at all.
[14:56] <hyperair> heh okay, i'll take that as fair warning and keep my distance for now =p
[14:56] <hyperair> thanks for the info =)
[14:56] <Dr_Jakob> if you have a i915g and want to play around with drivers please feel free
[16:13] <Sarvatt> wow, libgl1-mesa-dri-gallium actually works :D
[16:13] <Sarvatt> thanks tormod!
[16:18] <Sarvatt> now to document it
[16:20] <Sarvatt> maybe we should upload an apport that refuses to accept bug reports if libgl1-mesa-dri-gallium is installed just incase :)
[16:32] <Dr_Jakob> Sarvatt: whats in libgl1-mesa-dri-gallium? Only r300g?
[16:35] <Sarvatt> i915_dri.so  i965_dri.so  nouveau_dri.so  r300_dri.so  swrastg_dri.so
[16:35] <Dr_Jakob> heh, you can do without i965_dri.so, not even trivial/tri works.
[16:36] <Sarvatt> probably a good idea, someone might actually try it :)
[16:37] <Dr_Jakob> swrastg_dri.so could probably be renamed to swrast_dri.so
[16:39] <Sarvatt> was fixing that right as you said it :)
[17:04] <Sarvatt> ah hah, having libmyth-0.22-0 installed in karmic brings in the blob drivers on upgrade to lucid, thats where people were getting the blob installed on non nvidia from still
[17:04]  * Sarvatt just read the discussion in #ubuntu-devel
[17:07] <bjsnider> because of vdpau?
[17:08] <Sarvatt> ricotz: added you as a member, thought you were going to request it through launchpad but you never did :D
[17:08] <Sarvatt> yeah
[17:09] <Sarvatt> nvidia-185-libvdpau
[17:10] <bjsnider> libvdpau1 needs to be altered so it upgrades and replaces those packages
[17:10] <Sarvatt> yeah for sure
[17:11] <bjsnider> hahaha
[17:11] <bjsnider> i just looked at the control file for it, and it does replace the debian versions o those packages, but not the ubuntu versions
[17:11] <Sarvatt> doh!
[17:11] <bjsnider> Replaces: nvidia-libvdpau, nvidia-libvdpau1, nvidia-libvdpau-ia32
[17:11] <bjsnider> and conflicts too
[17:12] <bjsnider> this is because of the big disconnect between debian and ubuntu over the nvidia blob packaging
[17:12] <bjsnider> they've gotten too far apart
[17:12] <bjsnider> !info libvdpau1 lucid
[17:12] <ubottu> libvdpau1 (source: libvdpau): Video Decode and Presentation API for Unix (libraries). In component main, is optional. Version 0.3-2 (lucid), package size 23 kB, installed size 124 kB
[17:13] <bjsnider> yeah so if you look at the version, there are no ubuntu changes, it's synced from debian
[17:13] <ricotz> Sarvatt, oh, thanks, i have asked you awhile ago on irc here ;-)
[20:04] <Sarvatt> hehe apparently intel responded to someone asking about the lack of GMA500 drivers for linux saying it was up to the distro they are using to fix the problem
[20:26] <bryceh> !!
[20:26] <bryceh> Sarvatt, who exactly said that?
[20:27] <bryceh> got a link?  I should forward that to rick
[20:28] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-psb/+bug/330906/comments/70
[20:28] <ubottu> Ubuntu bug 330906 in xserver-xorg-video-psb "MASTER: GMA-500 lacks driver for 8.10 and 9.10 (poulsbo works only on 8.04 and 9.04)" [Wishlist,Won't fix]
[20:29] <Sarvatt> btw meego has psb support with current userspace :)
[20:30] <Sarvatt> was digging through all the meego source a week or two ago and saw the mass of patches
[20:30] <bryceh> hmm, second hand, no names associated with it
[20:30] <bryceh> oh?
[20:30] <bryceh> *sigh* meego
[20:31] <Sarvatt> yup didn't mean to imply it was an official response, sorry
[20:31] <bryceh> np
[20:32] <bryceh> would be nice to have those patches in a ppa or something
[20:32] <Sarvatt> tempted to get a psb machine to work out adding support for it
[20:33] <bryceh> no
[20:33] <bryceh> I value your sanity too much.
[20:35] <bryceh> ;-)
[20:35] <bryceh> actually would be great to get some -psb owners involved in helping with Ubuntu-X
[20:35] <bryceh> it's a tough, tough platform to support
[20:35] <bryceh> er, s/platform/driver/
[20:36] <Sarvatt> http://meego.gitorious.org/meego-os-base/kernel-source
[20:39] <Sarvatt> http://sarvatt.com/downloads/patches/linux-2.6.34-img-graphics-driver.patch -- too big to view on gitorious
[20:43] <bryceh> Sarvatt, did you run across any patches to stuff other than the kernel?
[20:43] <Sarvatt> nope I need to dig through the rpms for it still
[20:45] <bryceh> apw, ^^ maybe this patch should go on the meerkat kernel todo list.  maybe worth thinking about for 10.04.1
[20:46] <Sarvatt> nothing special in libdrm
[20:46] <Sarvatt> maybe they make everyone download the blob driver that needs an agreement externally that does it all
[20:47] <Sarvatt> need to pick apart the moorestown meego image
[20:51] <Sarvatt> what the heck is up with these packages
[20:51] <Sarvatt> KERNEL=="event*", SUBSYSTEM=="input", ATTRS{name}=="TSC2007 Touchscreen", ENV{x11_options.MinX}="150"
[20:52] <Sarvatt> they're using xserver 1.8, evtouch has a bunch of udev rules passing x11_options?
[20:52] <hyperair> hmm x11_options in udev rules eh
[20:52] <hyperair> i will have to port my hal fdi rules over
[20:54] <Sarvatt> hyperair: they aren't supported afaik, you use xorg.conf (or xorg.conf.d snippets) now
[20:54] <hyperair> Sarvatt: oh i see.
[20:54] <hyperair> Sarvatt: so how does one specify that only touchpads get 3button emulation?
[20:55] <Sarvatt> hyperair: http://fedoraproject.org/wiki/Input_device_configuration
[20:55] <hyperair> ohoho cool
[20:56] <hyperair> Sarvatt: is there any official documentation?
[20:56] <hyperair> Sarvatt: like a list of options, and matchwhatever things?
[20:57] <hyperair> nevermind matchwhatever things are there
[20:57] <Sarvatt> man synaptics or man xorg.conf tells ya
[20:59] <Sarvatt> http://edc.intel.com/Software/Downloads/IEGD/ thats what i was thinking of for psb
[21:07] <BUGabundo> even|ng
[21:46] <Sarvatt> there is no support for gma500 in meego currently.
[21:46] <Sarvatt> guess that answers that
[21:50] <Sarvatt> can't register with intel to grab that IEGD driver to look through either - You attempted to reach edc.intel.com, but the certificate that the server presented has been revoked by its issuer. This means that the security credentials the server presented absolutely should not be trusted. You may be communicating with an attacker. You should not proceed.
[21:52] <Sarvatt> the meego netbook repo is private too, thats why i couldn't find any juicy patches :D
[21:57] <bryceh> ahh
[21:57] <bryceh> now this is starting to sound like the psb we know and love
[22:00] <Sarvatt> they have a new platform coming out too thats just as crappy as psb but incompatible and bound to be used in netbooks, yay :)
[22:11] <bryceh> lovely