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