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