=== ara_ is now known as ara
[07:55] <tjaalton> mlankhorst: bad news, best to keep -msm for now :)
[07:55] <tjaalton> so if you could port it as well that would be great
[07:55] <mlankhorst> sigh I'll look into it :p
[07:55] <tjaalton> :)
[07:56] <tjaalton> i started it tho, want the preliminary patch?
[07:57] <RAOF> Hey all!
[07:57] <tjaalton> howdy!
[07:57] <tjaalton> and congrats :)
[07:57] <RAOF> Ta!
[07:58] <mlankhorst> tjaalton: sure
[07:58] <mlankhorst> my job of today is mostly poking an intel guy till he reviews stuff anyway :)
[07:59] <tjaalton> mlankhorst: http://paste.ubuntu.com/1148310/ the compat-api.h was just dumped from some other driver, edit as needed :)
[07:59] <tjaalton> not tested in any way, other than that the driver does not build on amd64 :P
[08:13]  * mlankhorst tries on his panda
[08:15] <Sarvatt> debian/patches/111_armel-drv-fallbacks.patch might need fixing after all these drivers being dropped
[08:16] <tjaalton> RAOF: back to work or just popping in?-)
[08:16] <tjaalton> Sarvatt: yep
[08:16] <mlankhorst> tjaalton: well was on canonicaladmin, tuesday was his last day off :p
[08:16] <Sarvatt> RAOF: what the heck are you doing on? contrats man!
[08:16] <tjaalton> mlankhorst: hah, ok :)
[08:17] <tjaalton> Sarvatt: actually, rsalveti is trying to get rid of the patch
[08:18] <Sarvatt> RAOF: all your mesa commits got commited, out of tree builds work again and unity works so the system compositor ppa could be updated where robert_ancell can use it
[08:18] <Sarvatt> today was the first day where unity works, good timing :)
[08:18] <mlankhorst> and we're about to break nvidia by moving x1.13 from proposed
[08:18] <mlankhorst> :p
[08:19] <Sarvatt> oh noes!
[08:19] <Sarvatt> but it compiles
[08:19] <Sarvatt> driver bug we cant fix, darn
[08:20] <mlankhorst> oh and slashdot ran an article linking to phoronix about the shame of wayland not being in quantal, I think suppuku is the honorable way ;)
[08:21] <tjaalton> seppuku you mean? getting prepared..
[08:21] <mlankhorst> :D
[08:21] <mlankhorst> darn I need the quantal stack on my panda now..
[08:24] <Sarvatt> mlankhorst: but you'll need to test the backport stack tomorrow and wont be able to
[08:25] <mlankhorst> oh no, you were supposed to test it :p
[08:26] <Sarvatt> mlankhorst: are blobs in there by any chance?
[08:26] <mlankhorst> not yet, suppose I could copy nvidia-current over
[08:26] <Sarvatt> i'm running edgers on my main machine where ppa-purge doesnt work so thats the main demotivation atm
[08:27] <Sarvatt> i have another precise machine with the blob i could remove edgers and test
[08:28] <Sarvatt> libdrm is up in the air
[08:32] <mlankhorst> tjaalton: great that driver is messed up
[08:32] <tjaalton> mlankhorst: you don't say..
[08:41] <mlankhorst> oh hey it has a strcasecmp..
[08:46] <mlankhorst> I can only confirm it doesn't break existing compiles at the moment..
[08:48] <mlankhorst> that's all I can do, sorry :(
[08:48] <tjaalton> it compiles?
[08:49] <mlankhorst> on old x abi, but I think it would on new one too now
[08:50] <mlankhorst> oh wait I can compile armel in my ppa
[08:50] <tjaalton> nice
[08:50] <tjaalton> uploaded evdev 2.7.3
[08:52] <mlankhorst> I'll see if it builds there or not
[08:52] <seb128> you guys noticed that our libxrandr is outdated compared to Debian (1.3.2 vs 1.4)? is that wanted?
[08:54] <tjaalton> seb128: the new one is in quantal-proposed
[08:55] <seb128> tjaalton, no it's not
[08:55] <tjaalton> no?
[08:55] <seb128> no
[08:55] <seb128> that's why I'm pointing it
[08:55] <seb128> our version pages uses proposed :p
[08:55] <seb128> http://people.canonical.com/~platform/desktop/versions.html
[08:55] <mlankhorst> woops forgot to check if that ppa had proposed enabled or not
[08:56] <tjaalton> seb128: ok, let's sync it then
[08:57] <tjaalton> done
[08:59] <seb128> tjaalton, thanks
[09:00] <tjaalton> thanks for the reminder :)
[09:04] <mlankhorst> tjaalton: https://launchpad.net/~mlankhorst/+archive/x-1.13/+build/3725585
[09:04] <tjaalton> :)
[09:04] <seb128> tjaalton, you also have those in red
[09:04] <seb128> libxvmc 	2:1.0.6-1ubuntu2 	2:1.0.7-1
[09:04] <seb128> xinput 	1.5.99.1-0ubuntu2 	1.6.0-1
[09:04] <seb128> xserver-xorg-input-evdev 	1:2.7.0-2~ubuntu1 	1:2.7.1-1
[09:04] <seb128>  xserver-xorg-input-mouse 	1:1.7.2-2build1 	1:1.7.2-3
[09:04] <seb128>  
[09:04] <tjaalton> I just uploaded evdev
[09:04] <seb128> in case you didn't notice them either ;-)
[09:04]  * seb128 pets versions
[09:05] <mlankhorst> but seems I used a too old version number since i used the precise one
[09:05] <tjaalton> yeah we have another list I'm following: http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/package_status.html
[09:12] <mlankhorst> oh great xorg 1.13 does a bunch of incompatible crap :(
[09:23] <debfx> tjaalton: what do I need to handle?
[09:24] <tjaalton> debfx: there's a patch added to virtualbox in quantal-proposed, builds against the new abi
[09:24] <tjaalton> debfx: so if you have channels to shove that upstream it would be nice :)
[09:26] <debfx> tjaalton: is it compatible with all the prehistoric x server versions? ;)
[09:27] <mlankhorst> still builds against the old abi, too!
[09:27] <tjaalton> should be
[09:27] <mlankhorst> or at least against the one in precise
[09:27] <tjaalton> mlankhorst tested against the current one
[09:27] <tjaalton> oh that
[09:27] <Sarvatt> does the new virtualbox release from today already compile against 1.13? :P
[09:27] <mlankhorst> not that I know of?
[09:27] <mlankhorst> or at least not last time I checked svn
[09:27] <Sarvatt> by today i mean my today, yesterday
[09:28] <tjaalton> beta1 was released aug 3rd, it doesn't
[09:28] <Sarvatt> 4.2 beta 1 august 14th?
[09:29] <tjaalton> oh rc1 tagged on 13th
[09:29] <mlankhorst> Sarvatt: svn trunk didn't seem capable of building it..
[09:29] <Sarvatt> i dont see anything in the notes :(
[09:29] <Sarvatt> just 1.12 support for solaris
[09:29] <mlankhorst> so what made you think it would?
[09:29] <mlankhorst> anyhow that patch makes it build at least
[09:34] <mlankhorst> next build attempt for msm..
[09:36] <tjaalton> seb128: merged libxvmc :)
[09:36] <seb128> tjaalton, great ;-)
[09:36] <tjaalton> and put the changes to git
[09:38] <mlankhorst> https://launchpad.net/~mlankhorst/+archive/x-1.13/+build/3725654 next msm attempt
[09:38] <mlankhorst> hopefully last one :)
[09:41] <Sarvatt> seb128: thanks for the heads up
[09:41] <seb128> yw ;-)
[09:42] <tjaalton> xinput can be synced
[09:42] <tjaalton> updated the branch though
[09:43] <Sarvatt> i tend to merge crap and don't find out its actually uploaded to debian till way later, like libxvmc just then
[09:44] <Sarvatt> should have been on the ball, april!
[09:45] <tjaalton> who uses that anyway, doesn't matter one bit :)
[09:45] <mlankhorst> xvmc is mostly dead
[09:45] <Sarvatt> yeah that update had like no actual fixes lol
[09:45] <mlankhorst> when you have fast enough hardware to call xvmc, you don't need xvmc
[09:46] <mlankhorst> yessss it's compiling msm :D
[09:46] <tjaalton> for how long? :)
[09:46] <mlankhorst> vdpau on the other hand is pretty nice
[09:46] <mlankhorst> https://launchpad.net/~mlankhorst/+archive/x-1.13/+build/3725654
[09:46] <mlankhorst> done compiling afaict
[09:47] <mlankhorst> ship it?
[09:47] <tjaalton> obviously
[09:48] <mlankhorst> ok just grab it from ppa and bump version number
[09:51] <Sarvatt> mlankhorst: you actually fixed msm??
[09:51] <mlankhorst> wasn't that broken
[09:52] <mlankhorst> tjaalton: ok so just omapfb being replaced by omap then?
[09:53] <tjaalton> mlankhorst: yeah, basically just needs the omap driver enabled in the kernel, then -omapfb removed from the archive
[09:53] <Sarvatt> the msm driver traditionally has just been driver drops from the vendor, who stopped caring forever ago, i spent a few days fixing it up for one xserver abi update to get ignored because it got updated in a new drop from the vendor so stopped caring
[09:53] <mlankhorst> would be a great thing to have
[09:54] <tjaalton> -msm uploaded
[09:54] <mlankhorst> Sarvatt: oh the thing is I don't care either about msm or virtualbox one hoot, it was just getting in the way of getting new xorg-server ready :)
[09:54] <Sarvatt> debian/patches/111_armel-drv-fallbacks.patch in xserver is probably totally hosed, wonder if anyone cares
[09:56] <Sarvatt> yeah i agree but those are universe packages that are community maintained, why we need to care.. who knows
[09:56] <mlankhorst> because x is special
[09:56] <mlankhorst> :p
[09:57] <Sarvatt> meanwhile, something like fglrx is broken and wont be fixed until a few months after we break it, thats a million times more important than any of that crap
[09:57] <RAOF> Sarvatt, mlankhorst: Last time I spoke with orga about that (which was during 11.10, IIRC), he intimated that he just wanted a heads-up on xserver transitions and we could palm off arm-specific drivers to his team to fix.
[09:57] <Sarvatt> and if we dont break it it wont ever be fixed
[09:57] <RAOF> That said, things have changed vis-a-vis the importance of arm-specific drivers, so we probably need to care :)
[09:58] <mlankhorst> RAOF: oh sure, but in this case I know the procedure so it would have been more work to make him do it then to do it myself
[09:58] <Sarvatt> RAOF: back when ubuntu-arm existed?
[09:58] <RAOF> Sarvatt: Yeah, pretty much :)
[09:58] <mlankhorst> RAOF: do you still want to do the radeon fencing thing?
[10:00] <RAOF> I won't have the time, much as I'd like to.
[10:01] <mlankhorst> ok I gathered as much, was already investigating at doing it myself..
[10:01] <tjaalton> huh, power cut off
[10:01] <tjaalton> need to shutdown
[10:13] <tjaalton> was writing that rsalveti is trying to fix the arm driver loading in the server
[10:14] <Sarvatt> do default drivers in the xorg metapackage need to be changed?
[10:14] <tjaalton> Sarvatt: the big difference is that we can fix this shit..
[10:14] <tjaalton> no
[10:15] <tjaalton> arm* depends on silly drivers..
[10:15] <Sarvatt> yeah bryce tried to reach out to the arm people years ago and noone responded
[10:15] <tjaalton> not any of this arm-specific stuff
[10:15] <Sarvatt> they dont use xserver-xorg-video-all
[10:16] <Sarvatt> cirrus sisusb fbdev vesa? that doesnt make any sense hmm
[10:18] <Sarvatt> modesetting omap fbdev maybe would be better
[10:18] <mlankhorst> yeah :s
[10:18]  * mlankhorst wonders if failsafe-x works on arm
[10:32] <ogra_> mlankhorst, at times :)
[10:33] <ogra_> though it usually gets me into a stuck situation (like no pointer working so that i have to switch to tty and stop lightdm)
[10:34] <ogra_> we definitely default to fbdev on all arm devices ... and we use xserver-xorg-video-all on all arm images 
[10:35] <ogra_> (ubuntu-arm images only differ in bootloader and kernel from x86 images in quantal, seeds are identical across the archies)
[10:38] <ogra_> as for the three binary arm video drivers we have in the archive .... we dont have armhf binaires for the omap3 one, feel free to ignore it ... for omap4 pvr we are supposed to get a new binary blob very soon (current one doesnt work with the current kernel), for nvidia tegra we are waiting for a fixed binary blob that supports xorg abi 13
[10:39] <ogra_> if you have any other questions, #ubuntu-arm still exists ... even though there isnt a team called like that anymore ;)
[10:45] <Sarvatt> vesa and cirrus definitely don't make sense and thats being brought in via xserver-xorg-video-all on arm, omap is the only real open source driver available, xf86-video-modesetting is for exynos  and any other kms driver, fbdev for the other stuff like tegra and fallback with out the blobs installed, debian/patches/111_armel-drv-fallbacks.patch in xorg-server could be updated to load the blob drivers automatically without an xorg.conf like it was do
[10:45] <Sarvatt> ing except not touching it will make omap blobs still work
[10:47] <Sarvatt> its just loading the pvr driver if /sys/devices/platform/omap exists right now, none of the other matches will do anything since the drivers are being dropped
[10:50] <Sarvatt> tegra should be added there at least, now sure how to tell if its a tegra, if those fail fbdev would be used, loadin pvr for omap might not make sense because xf86-video-omap exists
[10:51] <Sarvatt> 7 am? not asleep yet? goodnight :)
[10:52] <mlankhorst> ;)
[10:53] <mlankhorst> ogra_: yeah I'm just using the ti omap ppa, seems to work for me on omap4 a lot better than stock precise
[10:53] <Sarvatt> mlankhorst: play a divx video in totem
[10:54] <ogra_> apart from installing a ton of unsupported packages :)
[10:54] <mlankhorst> and yet it still works better than precise.. what does that mean? :)
[10:54] <ogra_> mlankhorst, that TI didnt invest much time into making the driver work with the official kernel
[10:54] <Sarvatt> they're forcing a specific gstreamer output sink via a gconf setting, which doesnt support normal videos only stuff that can be accelerated :P
[10:55] <ogra_> we dont have any control over it 
[10:55] <mlankhorst> Sarvatt: heh... have you tried playing video unaccelerated then? :D
[10:55] <mlankhorst> count the frames..
[10:55] <ogra_> Sarvatt, well, only if you installed the packages from the PPA
[10:56] <ogra_> (there is a reason we couldnt ship their codecs ;) )
[11:01] <Sarvatt> i just looked over the ppa when i was doing some nightmare with cedarview (aka poulsbo aka pvr sgx545 used there) video acceleration, not playing back anything but low profile h264 isn't really an option on the desktop :)
[11:02] <mlankhorst> shrug :p
[11:02] <mlankhorst> it's not the profile that matters, it's the resolution :D
[11:02] <Sarvatt> it can play back 1080p h264 3.1 high profile fine
[11:02] <Sarvatt> play a divx video.. haha
[11:02] <Sarvatt> something not gpu accelerated
[11:03] <Sarvatt> it just wont even play if you force the output sink to pvrwhateversink in gconf like the ppa is doing
[11:03] <Sarvatt> and thats the only way to use gstreamer-vaapi in gnome
[11:06] <mlankhorst> >implying you can call the unaccelerated slideshow 'playing' :D
[11:12] <mlankhorst> tjaalton: anything else I can do for x1.13?
[11:16] <tjaalton> mlankhorst: can't think of anything atm
[11:19] <mlankhorst> ok great :)
[11:34]  * mlankhorst reading into radeon
[11:52] <mlankhorst> I feel like being evil and convert radeon_fence to dma_fence :p
=== debfx_ is now known as debfx