[00:14] <Sarvatt> sweet, flash has vdpau and crystalhd acceleration now
[00:16] <RAOF> crystalhd?
[00:23] <Sarvatt> that broadcom card a lot of netbooks ship with to do video acceleration
[00:24] <Sarvatt> they're pretty cheap, i've got a spare full sized mini pcie slot in my netbook and it's tempting :)
[00:40] <RAOF> Heh.
[01:19] <bjsnider> Sarvatt, not on 64 bit it doesn't
[01:22] <RAOF> Eh.
[01:23] <bjsnider> i'd like to see flash go the way of realplayer
[01:23] <bjsnider> remember realplayer?
[02:01] <ion> Does Flash still do scaling and color format conversion in software even though using VDPAU?
[02:04] <RAOF> I think VDPAU's powerful enough to actually make that work; whether Flash uses it or not I don't know
[02:10] <ion> Ah, sorry, i mixed up VDPAU and VA-API. I’ve tried xvba-va-driver (which provides VA-API for fglrx), and vlc seems to still use Xv or one of its equivalents with it, which lead to my question.
[02:11] <Sarvatt> hmm yeah our libvdpau is still all kinds of messed up regarding 32 bit on amd64, we just dropped the 32 bit build because ia32-libs is in universe, it needs to be built with --with-module-dir=/usr/lib32 to work there from what I can see
[02:15] <Sarvatt> you have to set the moduledir path at compile time to adjust where it looks for the drivers looking at this http://cgit.freedesktop.org/~aplattner/libvdpau/commit/?id=0537b13e292bc772e984872a3986e41fb51f9258
[02:25] <Sarvatt>     -> 0, "NVIDIA VDPAU Driver Shared Library  260.19.26  Sun Nov 28 22:58:32 PST 2010"
[02:25] <Sarvatt> vdp_presentation_queue_target_create_x11(1, 81788969, -)
[02:25] <Sarvatt> [19475:19475:38699139682:ERROR:app/x11_util.cc(59)] X Error detected: serial 271, error_code 9 (BadDrawable (invalid Pixmap or Window parameter)), request_code 139 minor_code 4 (Unknown)
[02:25] <Sarvatt> romium-browser/chromium-browser --type=plugin --plugin-path=/usr/lib/chromium-browser/plugins/libflashplayer.so --lang=en-US --plugin-data-dir=/home/sarvatt/.config/chromium/Default --channel=19385.0xb8973a20.1456222274: ../../src/xcb_io.c:183: process_responses: Assertion `!(req && current_request && !(((long) (req->sequence) - (long) (current_request)) <= 0))' failed.
[02:26] <Sarvatt> hey I finally found something that can reproduce that xcb assertion
[02:29] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/419501
[02:30] <ubot4`> Launchpad bug 419501 in python-qt4 (Ubuntu Lucid) (and 6 other projects) "apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed. (affects: 146) (dups: 70) (heat: 755)" [Undecided,Invalid]
[02:31] <Sarvatt> VDPAU_TRACE=1 chromium-browser http://www.youtube.com/watch?v=DD0A2plMSVA
[02:33] <Sarvatt> (with flash 10.2 beta on i386 of course)
[02:38] <bjsnider> who uses i386 anymore?
[02:43] <Sarvatt> i care about wine and using xorg-edgers without the mess that is ia32-libs :)
[02:46] <bjsnider> well, perfect ia32-libs
[02:46] <bjsnider> don't abandon 64 bit just for that
[02:47] <Sarvatt> yeah let me just upload a 700mb package every day when I update mesa
[02:47] <bjsnider> ia32-libs is now 700 mb?
[02:48] <Sarvatt> ia32-libs_20090808ubuntu10~wineppa1.tar.gz (795.0 MiB)
[02:49] <RAOF> We should be getting multiarch Real Soon Now™
[02:49] <bjsnider> might as well just use the i386 cd image
[02:49] <Sarvatt> 64 bit kernel 32 bit userspace would be ideal but they said no to that idea at UDS
[02:50] <hyperair> Sarvatt: why so?
[02:51] <hyperair> RAOF: it was Real Soon Now™ a year ago.
[02:51] <Sarvatt> "just use 64 bit" "we've got too many kernel flavors" "We should be getting multiarch Real Soon Now™" :)
[02:51]  * hyperair sighs
[02:52] <Sarvatt> really though I think its real soon now for real this time
[02:52] <hyperair> i guess
[02:52] <hyperair> Sarvatt: at the dpkg level?
[02:52] <hyperair> afaik it needed some FHS transitioning to be done.
[02:53] <RAOF> My understanding is that Linaro wants it, and has someone doing it.
[02:54] <hyperair> RAOF: multiarch, or the 64-bit kernel and 32-bit userspace
[02:54] <Sarvatt> I heard people bugging slangasek about it at a bunch of sessions :)
[02:54] <RAOF> Multiarch.
[02:54] <hyperair> cool
[02:54] <RAOF> I guess at least in part because there's a bunch of ARM architectures which reasonably exist in parallel.
[02:55] <hyperair> hm
[02:59] <Sarvatt> it was mostly NAKed because you can do 64 bit kernel 32 bit userspace now anyway if you do it manually and supporting it would be a nightmare with all the little problems it causes :)
[03:01] <Sarvatt> last I checked blobs wouldn't work so haven't tried it yet
[07:42] <Sarvatt> RAOF: the do nothing approach is probably the best, I dont think option 2 will even be possible with fbcon built into the kernel? plus nvidia is installable with persistant storage and booting off of usb to test isn't that tall an order.. that being said I'd love to see nouveau on there by default even if just to see the impact while it's early in the cycle and easily backed out if it truly is bad off which would be opposite to my experiences wit
[07:42] <Sarvatt> h it
[07:43] <Sarvatt> we need a ddx update
[07:43] <RAOF> Yeah.
[07:43] <RAOF> I was going to get to that after getting mesa master to not segfault when alt-tabbing in compiz.
[07:45] <Sarvatt> will get edgers updated to natty's mesa packaging this week
[07:53] <bryceh> RAOF, uh oh looks like the last minute code for 1.10 is knocking on the door
[07:54] <Sarvatt> hopefully xinput 2.1 that we wanted to do 1.10 for in the first place makes it :)
[07:54] <RAOF> Ah.  That's an impressive 190 unread X messages since yesterday!
[07:55] <RAOF> Many of which seem to be ‘ack, pulling these reviewed patches’, though.
[07:55] <bryceh> nope, keep reading
[07:55] <RAOF> Even if 1.10 doesn't make it in, the new input ABI has :)
[07:56] <Sarvatt> there may be an fpit release!
[07:56] <Sarvatt> it's been broken (but fixed in git) since xserver 1.7
[07:57] <bryceh> see keith's post about delaying the freeze so he can slip in per-crtc-pixmap ;-)
[07:57] <RAOF> Hah.
[07:58] <Sarvatt> was actually starting to package stuff for xorg-edgers until I saw that a few hours ago :)
[07:59] <bryceh> Sarvatt, feeling better I take it?
[08:00] <Sarvatt> yep! never eating from that chinese food restaurant again, thats for sure
[08:01] <bryceh> ugh I hate stomach flu
[08:04] <Sarvatt> it doesn't look like its all hooked up yet but the bailer plugin for compiz looks like it would help quite a bit if we did enable nouveau
[08:04] <Sarvatt> there's infrastructure there for different levels of reduced functionality if it detects problems
[08:04] <RAOF> That's also where the blacklist will live.
[08:04] <mvo> get well bryceh
[08:05] <RAOF> We're *going* to need one, and the DX guys know it.
[08:05] <bryceh> mvo, oh thanks!  However it was Sarvatt who had stomach flu, I'm actually fine
[08:05] <Sarvatt> RAOF: yeah blacklist is in there now, blacklisting a few 8xx intels
[08:05] <mvo> oh, missed that - in this case: Sarvatt: get well :)
[08:06] <RAOF> Sarvatt: Not that it needs to do that, what with us loading fbdev on them :)
[08:08] <Sarvatt> thanks mvo, i'm all better now :)
[08:08] <Sarvatt> http://sarvatt.com/downloads/patches/065_add_bailer_and_detection_plugins.patch
[08:08] <Sarvatt> thats the bailer patch, dont have the bzr branch link handy
[08:12] <tjaalton> RAOF: what about option (3): make it easy to install nouveau dri in the livecd. it should be pretty straightforward I think
[08:13] <tjaalton> just apt-get; logout -> respawn X
[08:14] <Sarvatt> oh even better idea!
[08:17] <Sarvatt> where to hook that in would be the question
[08:18] <tjaalton> yep
[08:19] <tjaalton> is jockey on the livecd?
[08:19] <Sarvatt> jockey maybe? where it offers restricted drivers it could offer unsupported ones too?
[08:19] <tjaalton> right
[08:26] <Sarvatt> might not even need the logout if it can be made to just start compiz with the unity plugin after installing it
[10:01] <ara> hello all
[10:01] <ara> in alpha 1 testing I am seeing a weird error with my mini9 
[10:01] <ara>  the live session works correctly (X session shows), but when I install
[10:01] <ara>  the X session starts (I can hear the gdm bang sound), but the screen is completely black
[10:01] <ara>  any ideas?
[10:01] <ara>  I tried to kill X or going to another ttx to check the logs, but I couldn't
[10:35] <mvo> does the live session has unity/compiz ? it smeels like unity and or compiz kill it via their opengl requirements
[10:37] <ara> mvo, yes, the live session does have unity/compiz
[16:30] <Sarvatt> go figure, waited about 24 hours of using nvidia 260.19.26 to see if it was stable before uploading it to the PPA and now it's completely busted after I upload it :)
[16:31] <bjsnider> works fine here
[16:32] <bjsnider> why did they release it with no changelog?
[16:33] <Sarvatt> ok I take back the completely busted thing, just glxgears having the problem so not really  a big deal. [89457.337477] NVRM: Xid (0001:00): 8, Channel 00000001 and a 30 second or so hang every time I run it
[16:35] <Sarvatt> they didn't really release it yet, someone just asked for a beta update and they  haven't announced it because they forgot the changelog
[16:36] <bjsnider> glxgears works here
[16:58] <apw> bryceh, who knows anything about intel register dumps ?
[18:28] <bryceh> apw, anholt, jbarnes sometimes
[18:29] <apw> bryceh, so i have a box in my hand which shows the goes black failure mode when grub hands off the video in graphics mode
[18:55] <bryceh> apw, pipe underrun just means that it noticed not enough graphics data came through
[18:55] <bryceh> apw, which is kind of a silly error - of course no data is coming through, the GPU locked up
[18:56] <apw> bryceh, i am not showing a gpu lockup
[18:56] <apw> bryceh, i suspect we are reprogramming the graphics while it is runnning, and don't do it right, leading to the underrun
[18:56] <bryceh> apw, ah
[18:57] <apw> bryceh, but i am unsure if the underrun is an end of the world event or just 'not very handy'
[18:57] <bryceh> apw, yeah dunno