[02:15] <duflu> RAOF: Do you recall why outputs have pixel formats?
[02:15] <duflu> Is that for nesting?
[02:16] <RAOF> Because CRTCs have pixel formats?
[02:16] <RAOF> How else would you scan out of rgb565, or rgbx1010102?
[02:16] <duflu> RAOF: Hmm, OK. Just noticed we've hardcoded xrgb in a couple of places for KMS (which might aggravate the vmware bug)
[02:17] <RAOF> Really? Odd.
[02:17] <RAOF> If you want to update the kms platform to use the available output formats that'd be fine :)
[02:19] <duflu> In other news, I found a second use for blank DVDs
[02:19] <duflu> To burn ThinkPad BIOS updates (which otherwise require Windows)
[02:19] <duflu> The first use is as a coaster
[02:20] <RAOF> Huh. I always used USB sticks for that.
[02:20] <duflu> RAOF: Not an option with ThinkPad ISOs
[02:20] <duflu> I have tried many times
[02:22] <duflu> The first 32K of the ISO is zero... so there's no boot sector there
[02:22] <RAOF> HUh.
[07:21] <duflu> Is CI down? I've been waiting 5 hours on my current branch...
[07:23] <duflu> Oh I see others have been waiting 7 hours
[07:45] <anpok> hm device-runtests-mir seem to wait for krllin executors
[07:46] <anpok> hm but it is still running
[07:47] <anpok> at least one job..
[08:20] <duflu> anpok: Finished after 6 hours
[08:20] <duflu> Just one revision on one branch
[12:09] <alan_g> kdub: have I understood your review comment? https://code.launchpad.net/~alan-griffiths/mir/rework-throwback-and-staging/+merge/314351
[12:15] <kdub> alan_g, didn't see the other file, will remove needs fixing
[12:15] <alan_g> thanks
[12:17]  * alan_g only needs the prerequisite to pass review now
[15:34] <kdub> camako, been thinking... if we're deprecating mir_buffer_stream_get_egl_native_window in favor of Mir(Render)Surface, there's really no reason to have a 'hardware' buffer stream
[15:35] <kdub> so maybe we just drop the MirBufferUsage parameter from mir_render_surface_get_buffer_stream(), and that makes software buffers
[15:35] <kdub> android drivers don't need streams, mesa doesnt need streams, and the users will port to using MirRenderSurface as the native window (instead of the hop through mir_bs_get_egl_native_window())
[15:36] <camako> kdub, umm yeah sounds reasonable... Future (non-egl) middleware can use PCs, I guess
[15:37] <kdub> right, and if we encounter any usage of it (which I think most the usage is the egl case)
[15:37] <kdub> we should add extensions for android and mesa to do the right thing
[15:37] <kdub> that is, 'add extensions for android/mesa to alloc a hardware bufferstream'
[15:38] <kdub> I'll pull that param out of there, and RAOF is probably interested in reviewing as well
[15:42] <kdub> 0.26 is going to be a big silo
[15:43] <bschaefer> kdub, it is
[15:44] <bschaefer> going to be
[17:01] <alan_g> kdub: your commit comment seems to be a C&P error - https://code.launchpad.net/~kdub/mir/usage-deprecation-nested/+merge/314518
[17:04] <kdub> alan_g, thanks, correcetd
[17:11] <kdub> camako, darn, we have name collisions when trying to change MirRenderSurface to MirSurface :/
[17:12] <camako> kdub, yeah we are not ready... We need to make a release
[17:12] <camako> then delete MirSurface
[17:12] <camako> then rename
[17:13] <kdub> yeah, so it looks like releasing the new platform won't make it into 0.26
[17:14] <alan_g> kdub: unless you call it Mir5urface for the time being and then deprecate
[17:14] <alan_g> ;)
[17:14] <kdub> yeah :D
[17:15] <kdub> mir_5urface_release
[17:15] <kdub> not too late to change all the functions to l33t5p34k before the 1.0!
[17:15] <alan_g> LOL
[17:16] <camako> kdub, @new platform... correct
[17:18] <alan_g> If we don't have enough to release now, we /could/ release MirRenderSurface in 0.26, then deprecate it for MirSurface in 1.0.
[17:19] <alan_g> ...and delete it in 2.0
[17:20] <bschaefer> kdub, i like that naming scheme, it expresses a lot about the functions
[17:20] <bschaefer> %s/*/l33t5p34k/g
[17:21] <alan_g> keywords too?
[17:21] <bschaefer> %s/./l33t5p34k/g
[17:21] <bschaefer> every char
[17:22]  * bschaefer assumes this would no longer compile though
[17:22] <kdub> well, thats where macros come in
[17:22] <bschaefer> haha
[17:23] <bschaefer> good luck figuring out how many k's you need to disambiguate that grammar
[17:23] <kdub> alan_g, yeah, I think the plan was to not release the MirRenderSurface, because if its named 'MirSurface', then it falls into the vulkan standard
[17:24] <alan_g> kdub: ack, I thought that too
[17:25] <kdub> yay, we're in a cheatsheet for khronos https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf
[17:25] <alan_g> But at that time I also thought 1.0 would make it into 17.04
[17:31]  * bschaefer has hope but it fades by the hour
[18:02] <kdub> r:74
[22:39] <tjaalton> bregma: ping