[00:10] racarr_, can a cursor exist (render) with a mir surface that never swaps buffers? [00:11] attempting to manually swap said surface causes a crash :( [00:21] bschaefer: I dont exactly understand the second bit [00:21] but to the first bit...should be able to! [00:22] We don't expose the ability to use a surface as a cursor yet, do we? [00:23] racarr_, well, the issue im see is in SDL2 they do a cursor test just by simply rendering the cursor (a surface/window exists but is not renderered) [00:24] RAOF, so yeah, thats what would be needed i suppose (or at lease how this one SDL2 test assume cursors work) [00:24] Can we tell SDL that we don't support hardware cursors? [00:27] RAOF, hmm [00:27] RAOF, so thats a hardware cusor? I wonder if it assumes the system cursor is a hardware cursor? [00:28] RAOF, i think we can live with out that support, considering most the time a window will come along with the cursor (otherwise thats a pretty boring app) [00:29] Well, can we tell SDL that it'll have to draw its own cursors if it wants to draw something special? [00:29] for now i can just set the cursor for the surface, and if they don't render the window then they wont get anything [00:29] Oh, right! [00:29] RAOF, not that i know, ill have to dig into that, but i think it just sets the cursor [00:29] and wishes it luck [00:29] Because the cursor is only going to change when it's *over* the surface. [00:29] right [00:29] cool, i can live with that [00:29] just wanted to double check :). Thanks! [00:29] And the surface isn't going to appear until some rendering has been done to it. [00:30] Right, I think I see your problem now :) [00:31] hmm [00:31] shouldnt the surface be in the input targets though [00:31] even if its never posted a buffer [00:31] yeah, the test was interesting ill have to write my own where the window is being rendererd [00:32] racarr_, yeah, inputs and all is fine it just never gets to the swap buffers stage [00:32] so when i set the cursor [00:32] configure for the surface [00:32] you need to swap the buffers to get the new cursor right? [00:33] as, from i can tell doing a set cursor config on a surface yeilds nothing until a swap happens [00:34] I wouldn't thinky ou would no [00:34] as far as I can tell doing a swap doesn't change anything with respect to doing hte set cursor [00:35] and there is a test that [00:35] you can change the cursor without anything else happening [00:35] and the appropreiate things happen...so [00:35] something weird is happening [00:35] racarr_: If you haven't submitted a buffer we don't show the window at all, right? [00:36] racarr_: So the surface *won't* be in the input targets list? [00:36] Or, at least, if the surface is in the input targets list that'd be a pretty horrible bug, because it would look like you'd have input mysteriously going nowhere. [00:37] racarr_, i can take a look, where is the input target list kept? [00:37] i would think the mir_server somewhere? [00:39] racarr_, yeah in your example if i comment out that first swap buffers [00:39] nothing shows up, and soo i cant see any cursor changes (since it has to be over a surface) [00:40] sooo i guess the overall issue, there is no swap at the very beginning, so no mir_surface is rendered so i cant see the cursors getting changed [01:12] RAOF: I think it will be and it would be a horrible bug [01:12] bschaefer: Ok possible if nothing [01:13] is ever rendered [01:13] at all [01:13] then the cursor wont show up [01:13] hahaha [01:13] like from any surface. [01:16] racarr_, yeah haha === chihchun is now known as chihchun_afk [04:05] Ah, cmake [04:05] *Of course* set(VAR value PARENT_SCOPE) doesn't actually set VAR in the *current* scope. [04:05] Whyever would I expect that behaviour? === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [06:31] Oops. [06:31] Don't do testing in a dirty tree. === chihchun_afk is now known as chihchun [08:25] alf_: anpok want to give an opinion on this or shall I top-approve? https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336 [08:25] alan_g: just commented [08:26] Just saw that. ;) [08:28] BTW I'd be happier if it were *only* the unit tests that linked directly to the internal classes - maybe we should record that as a bug? [08:35] hm or the opposite .. acceptance tests not using the libraries [08:35] i mean we have integration tests that dont include/touch/need the complete system [08:39] Yes, the acceptance tests ideally use the libraries. [08:40] the $ ? [08:41] yes [08:42] nearly like libtool convenience library [09:03] alf_: It is great how the review process unearths hidden problems: https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336/comments/553784 [09:12] greyback: is the "PrivateProtobuf" stuff being used? [09:13] alan_g: @"It is great how the review process unearths hidden problems", +1 [09:14] alan_g: not that I can see, no [09:15] greyback: Yesterday my eye caught a comment about not showing the last frame. Do you have a bug for that, more information about how to reproduce etc? [09:16] greyback: cool. No immediate plans either? [09:16] alan_g: none that I'm aware of either [09:17] * alan_g stop worrying about breaking it [09:20] * alan_g finds ua_ui_set_clipboard_content()/ua_ui_get_clipboard_content() [10:05] hello all [10:05] racarr_, you here ? [10:15] I was trying to investigate my device being stuck at boot logo. Yesterday I tried removing hwcomposer.so from android system and reboot. [10:15] This time device booted up and a small ubuntu logo appeared followed by a hello screen to choose language. [10:16] But it got stuck there. So I'm thinking maybe mir has problems with hwcomposer module. How can I debug it ? [10:24] groot_: the guys that know about bringing up devices new best (kdub and AlbertA) are not up yet. [10:27] groot_: can you adb into the device and see what's running? Or is that broke too? [10:27] alan_g, I see. I'll wait for them. kdub helped me a lot to debug my issues :). Are they gonna be here soon ? [10:27] alan_g, I've ADB access [10:29] Probably an hour or so [10:29] alan_g, I can upload some logs if you want to take a look. [10:29] groot_: I'd be guessing as much as you are [10:30] But if you've adb you can try running mir_demo_server_basic and clients [10:34] alan_g, all right. I'll try and see what happens. [11:10] alf_: (non-urgent) please have another look at https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336 [11:10] alan_g: ok [11:13] alf_: is anything still happening with https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/228247? [11:17] alan_g: RAOF thinks that Breaks,Replaces is the right way to go, and wanted to try some script changes to use apt instead of dpkg [11:18] alf_: understood. === pete-woods is now known as pete-woods|lunch === tvoss is now known as tvoss|lunch [11:33] alan_g: @fix-libmirclient, 136- mirclient , do we remove the explicit link because it's linked through libmirserver? [11:35] alf_: no, because I accidentally reverted that before checking in. (And, as you observer, it "just works") [11:36] alf_: fixed === dandrader is now known as dandrader|lunch === chihchun is now known as chihchun_afk === pete-woods|lunch is now known as pete-woods === alan_g is now known as alan_g|lunch [12:20] kdub, hello. I've come again to solve my device hang issue. Are you here ? [12:20] yep, I thought you had a segfault issue though [12:21] kdub, something interesting happened. Yesterday I tried removing hwcomposer.so from android system and reboot. [12:21] This time device booted up and a small ubuntu logo appeared followed by a hello screen to choose language. [12:22] But it got stuck there. So I'm thinking maybe mir has problems with hwcomposer module. [12:22] oh, well if you do that you start using the backup mode (the fb module), which is deprecated in android, but seems it works on your device [12:23] groot_, so that assessment is right... I was thinking that your hwcomposer module was malformed or loaded incorrectly, because a lot of the function hooks we call in hwc were nullptrs [12:25] kdub, I'm sure that hwcomposer is fine since we use the same source on other custom roms. So probably it is loaded incorrectly. [12:26] also, where you trying to run with hwcomposer as root? [12:26] * kdub forgets if that was aske [12:28] kdub, I'm not sure. hwcomposer is loaded during system startup? how to know it's running as root ? [12:28] well, I meant running the test binaries [12:28] like mir_demo_server_basic [12:29] kdub, ohh I didn't use sudo. Just ran them normally when hwcomposer was present before. [12:30] groot_, it tries to access some files in /dev, its a common problem with new devices that the permissions arent set up to run as the normal user [12:30] so, might be worth a shot [12:31] kdub, just to let you know, I ran some mir_demo commands like flicker, eglflash, scroll etc after removing hwcomposer.so. They worked, device screen was updated with the commands [12:32] I'll test with hwcomposer beign present [12:32] right, it seems the backup module is working [12:39] kdub. just tried with sudo. Without sudo it segfaults and with sudo it falls back to command prompt. But those tests are failing, saying "couldn't connect to display server" [12:40] so that wasnt the root of the problem === alan_g|lunch is now known as alan_g [12:43] kdub, So hwcomposer is the main issue here? [12:44] yep! [12:48] kdub, so how to know it's from my end or it's loaded incorrectly? I'm ready for some tests :) [12:50] not quite sure, as we're hitting null function hooks that apparently aren't there in sf [12:50] some devices have a .so that's just a passthrough to load another blob .so... is this driver like that? [12:54] kdub, it's not. You can take a look if you want https://github.com/AndroidOpenSourceXperia/android_hardware_ste-sony/tree/master/display/libhwcomposer [12:54] oh great, its open [12:56] :) [12:57] are any of those ALOGE's in hwcomposer_device_open printed in logcat? [12:57] that seems to be the fn that fills the fn hooks [12:58] kdub, I'll check and let you know. [13:09] kdub, no errors like that. In fact, there's no log with that log tag. [13:10] hmm, well, from what I've been told it seems like its not getting to lines 1681-1686 [13:16] kdub, there's a error in logcat "E/MMHwBufferPool( 1875): allocate: HWMEM_EXPORT_IOC failed". Maybe it's related ? [13:16] well, sure doesn't sound good to me [13:16] but it could be from any component [13:25] kdub, is there a way to pinpoint the exact functions causing hwcomposer issue? (like backtrace) [13:26] groot_, i'd see if it gets to those lines I pointed out in hwcomposer... that can be done via gdb or sprinkled printf [13:28] kdub, can you tell me which commands to run ? I've the device attached. === dandrader|lunch is now known as dandrader [13:41] kdub, ^^ [13:41] groot_, short answer, its a bit too interactive to do over irc. [13:42] but basically, after you have things built with debug symbols, you just run gdb and set up the breakpoints on hwcomposer_device_open [13:43] and you can step over the lines of code to see if those function hooks get filled === tvoss|lunch is now known as tvoss [13:47] kdub, I'll try that. But hwcomposer is a .so file. I used "gdb programm_name" to get backtrace. How to do it with lib files? That part I don't understand :) [13:47] ah, so when the executable starts up, the linker will stitch that .so file into the program (because the executable will ask for hwcomposer) [13:50] kdub, all right. Lastly, what executable I should run? [13:50] mir_demo_server_shell ? [13:50] ./mir_demo_standalone_render_to_fb is the simplest thing that will drive the display, but that one will work also [13:53] kdub, All right. I'll be here when I'm done with the test. [13:59] groot_, good luck! [14:02] kdub, thanks. It seems hard to me, do I have to build mir again? Or just the hwcomposer with "-g" flag ? [14:08] hwcomposer [14:08] mir should have been built with it, since you built it yourself [14:19] Hey guys, I was poking around wayland stuff and considered buildining it but I came across the link to Mir on the ubuntu website. Any pointers I should know that arent listed on the site? === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [15:21] Morning [15:28] hey racarr_ [15:44] kdub: (non-urgent) please have another look at https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336 [15:44] sure === chihchun_afk is now known as chihchun === alan_g is now known as alan_g|EOD [17:09] any other takers? https://code.launchpad.net/~kdub/mir/fd-refcount/+merge/228306 === chihchun is now known as chihchun_afk [17:52] why am I putting the pixel 0x00 0xff 0xff 0xff in to an argb buffer and getting green lol... [18:07] racarr_: its really rgb ? ending up 00ffff ? [18:10] kgunn: Well...I dunno...I guess something really isn't [18:10] the buffer really does report being ARGB though, and my pixel really is 0, 255, 255, 255 [18:10] and I do get green... [18:11] lol I guess that buffer isnt really ARGB or I have [18:11] made some strange error [18:11] touchspots are all done besidfes being [18:11] green... [18:11] lol [18:12] yea! for green touch spots [18:12] well in particular they are blue circles on green rectangles [18:12] instead of orange circles on transparent [18:12] :p [18:13] racarr_: oh wait....rgba vs argb [18:13] racarr_: suppose swap the values around would prove the theory [18:36] kdub: You were...talking about something the other day with android buffer maps and pixel format mess...is there anything in particualr beyond having to get the pixel format right? [18:36] kdub: ...my buffer reports being mir_pixel_format_argb8888 [18:36] racarr_, that should be all, as far as I remember [18:36] and green would be 0xFF00FF00 [18:36] no tiling madness? [18:37] no tiling madness my [18:37] circle shows up as expected... [18:37] I guess I am getting yellow lol. [18:37] it was hard to see...... [18:38] but my buffer says it should be argb8888, and I put in [18:40] 0, 255, 255, 255 and get yellow which means my buffer is really...bgra [18:40] or something [18:40] starting in b [18:40] what....:/ [18:42] grrr [18:45] racarr_, [18:46] mir_pixel_format_argb_8888: gets translated to HAL_PIXEL_FORMAT_BGRA_8888 [18:46] so sounds like a byte ordering thing [18:47] I...feel like I must not understand what pixel formats [18:47] mean [18:48] why do we have something called pixel_format_argb if the pixels are bgra [18:52] " * The order of components in a format enum matches the [18:52] * order of the components as they would be written in an [18:52] * integer representing a pixel value of that format. [18:52] " [18:54] kdub: Oh...I see...lol. thanks :) [18:54] This is a strange choice for us [18:54] considering both systems we have ever run mir on [18:54] are little endian... [18:54] (well arm is little endian by default at least) [18:57] there's something I still dont understand... [18:57] the cursor (which I guess has never been used on ARM) [18:57] (i.e. black_arrow.c) [18:57] gets put in a GBM_FORMAT_ARGB8888 buffer [18:57] however the image file [18:57] is RGBA?!?! [18:58] so what on earth is GBM_FORMAT_ARGB8888 in memory.... [18:58] well [18:58] RGBA apparently [18:58] lol [19:00] we don't have a bgra format [19:03] probably because android doesn't have a corresponding pixel format [19:04] there's a HAL_PIXEL_FORMAT_BGRA_8888, but that would be mir_pixel_format_argb_8888 [19:04] fun, huh? [19:04] yes lol [19:05] IO understand now [19:05] what confused me [19:06] was just the comment from the gimp C file outputer lol...the cursor image thing is ARGB in our terms. [19:12] ...do we have any other [19:12] transparent surfaces anywhere [19:13] because now I am writing it in BGRA...(though I dont think its going to work on mesa now...not sure what I am going to do...) [19:13] but I get [19:13] white for the background [19:13] (writing ff ff ff 00 in to HAL_PIXEL_FORMAT_BGRA) [19:14] and my renderable says shaped [19:20] I've got go to outside lol...between my seeming inability to put a pixel of the correct color on the screen, the people outside with jack hammers [19:20] and the person yelling at the person with a jack hammer [19:20] I am about to lose it:p [19:20] back after lunch [19:24] ugh of course...my pixels arent premultiplied...I wonder how alan got gimp to produce such a nice black_arrow.c [19:26] oh, there's an output plugin [19:27] mm but it produces the pixels in the opposite order we need [19:28] and doesnt premultiply [19:28] unless I am missing like an extra [19:28] options page [19:28] or something [19:28] maybe it depends on the input format oO [19:51] fwiw, ti did the same damn misnaming.... [19:51] created the same headaches [19:56] yeah, the best is when like [19:57] marketing somehow gets involved ;) [20:08] lol... [20:09] premultiplied alpha sounds like something people might pay extra for [20:14] and even more for MostSignificantByte premultiplied alpha [20:15] with some tiling [20:16] lol [22:03] Whee...fresh install [22:04] feels nice :p [23:45] so how do I update this [23:45] server-ABI-sha1sums file [23:47] eh nvm pipe find + some stuff to xargs sha1sum [23:47] lol...this is ridiculous [23:47] my two branches which I am proposing [23:48] ok nvm maybe it will be fine [23:48] conflicts galore [23:48] ...sorry speaking outloud in half sentences [23:53] Heh.