| bschaefer | racarr_, can a cursor exist (render) with a mir surface that never swaps buffers? | 00:10 |
|---|---|---|
| bschaefer | attempting to manually swap said surface causes a crash :( | 00:11 |
| racarr_ | bschaefer: I dont exactly understand the second bit | 00:21 |
| racarr_ | but to the first bit...should be able to! | 00:21 |
| RAOF | We don't expose the ability to use a surface as a cursor yet, do we? | 00:22 |
| 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:23 |
| 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:24 |
| 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:27 |
| 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:28 |
| 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:29 |
| RAOF | Right, I think I see your problem now :) | 00:30 |
| 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:31 |
| 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:32 |
| bschaefer | as, from i can tell doing a set cursor config on a surface yeilds nothing until a swap happens | 00:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:39 |
| 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 | 00:40 |
| racarr_ | RAOF: I think it will be and it would be a horrible bug | 01:12 |
| racarr_ | bschaefer: Ok possible if nothing | 01:12 |
| 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:13 |
| bschaefer | racarr_, yeah haha | 01:16 |
| === chihchun is now known as chihchun_afk | ||
| 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? | 04:05 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| RAOF | Oops. | 06:31 |
| RAOF | Don't do testing in a dirty tree. | 06:31 |
| === chihchun_afk is now known as chihchun | ||
| 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:25 |
| alan_g | Just saw that. ;) | 08:26 |
| 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:28 |
| 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:35 |
| alan_g | Yes, the acceptance tests ideally use the libraries. | 08:39 |
| anpok | the $<TARGET_OBJECTS.. will pull in the object files built for the target | 08:40 |
| anpok | ? | 08:40 |
| alan_g | yes | 08:41 |
| anpok | nearly like libtool convenience library | 08:42 |
| 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:03 |
| alan_g | greyback: is the "PrivateProtobuf" stuff being used? | 09:12 |
| alf_ | alan_g: @"It is great how the review process unearths hidden problems", +1 | 09:13 |
| greyback | alan_g: not that I can see, no | 09:14 |
| 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:15 |
| alan_g | greyback: cool. No immediate plans either? | 09:16 |
| greyback | alan_g: none that I'm aware of either | 09:16 |
| * alan_g stop worrying about breaking it | 09:17 | |
| * alan_g finds ua_ui_set_clipboard_content()/ua_ui_get_clipboard_content() | 09:20 | |
| groot_ | hello all | 10:05 |
| groot_ | racarr_, you here ? | 10:05 |
| 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:15 |
| groot_ | But it got stuck there. So I'm thinking maybe mir has problems with hwcomposer module. How can I debug it ? | 10:16 |
| alan_g | groot_: the guys that know about bringing up devices new best (kdub and AlbertA) are not up yet. | 10:24 |
| 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:27 |
| 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:29 |
| alan_g | But if you've adb you can try running mir_demo_server_basic and clients | 10:30 |
| groot_ | alan_g, all right. I'll try and see what happens. | 10:34 |
| 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:10 |
| alan_g | alf_: is anything still happening with https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/228247? | 11:13 |
| 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:17 |
| alan_g | alf_: understood. | 11:18 |
| === pete-woods is now known as pete-woods|lunch | ||
| === tvoss is now known as tvoss|lunch | ||
| alf_ | alan_g: @fix-libmirclient, 136- mirclient , do we remove the explicit link because it's linked through libmirserver? | 11:33 |
| alan_g | alf_: no, because I accidentally reverted that before checking in. (And, as you observer, it "just works") | 11:35 |
| alan_g | alf_: fixed | 11:36 |
| === 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 | ||
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:25 |
| kdub | also, where you trying to run with hwcomposer as root? | 12:26 |
| * kdub forgets if that was aske | 12:26 | |
| 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:28 |
| groot_ | kdub, ohh I didn't use sudo. Just ran them normally when hwcomposer was present before. | 12:29 |
| 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:30 |
| 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:31 |
| groot_ | I'll test with hwcomposer beign present | 12:32 |
| kdub | right, it seems the backup module is working | 12:32 |
| 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:39 |
| kdub | so that wasnt the root of the problem | 12:40 |
| === alan_g|lunch is now known as alan_g | ||
| groot_ | kdub, So hwcomposer is the main issue here? | 12:43 |
| kdub | yep! | 12:44 |
| groot_ | kdub, so how to know it's from my end or it's loaded incorrectly? I'm ready for some tests :) | 12:48 |
| 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:50 |
| 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:54 |
| groot_ | :) | 12:56 |
| 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:57 |
| groot_ | kdub, I'll check and let you know. | 12:58 |
| groot_ | kdub, no errors like that. In fact, there's no log with that log tag. | 13:09 |
| kdub | hmm, well, from what I've been told it seems like its not getting to lines 1681-1686 | 13:10 |
| 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:16 |
| groot_ | kdub, is there a way to pinpoint the exact functions causing hwcomposer issue? (like backtrace) | 13:25 |
| 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:26 |
| groot_ | kdub, can you tell me which commands to run ? I've the device attached. | 13:28 |
| === dandrader|lunch is now known as dandrader | ||
| groot_ | kdub, ^^ | 13:41 |
| kdub | groot_, short answer, its a bit too interactive to do over irc. | 13:41 |
| 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:42 |
| kdub | and you can step over the lines of code to see if those function hooks get filled | 13:43 |
| === tvoss|lunch is now known as tvoss | ||
| 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:47 |
| 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:50 |
| groot_ | kdub, All right. I'll be here when I'm done with the test. | 13:53 |
| kdub | groot_, good luck! | 13:59 |
| groot_ | kdub, thanks. It seems hard to me, do I have to build mir again? Or just the hwcomposer with "-g" flag ? | 14:02 |
| kdub | hwcomposer | 14:08 |
| kdub | mir should have been built with it, since you built it yourself | 14:08 |
| 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? | 14:19 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| racarr_ | Morning | 15:21 |
| willcooke | hey racarr_ | 15:28 |
| 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 | 15:44 |
| === chihchun_afk is now known as chihchun | ||
| === alan_g is now known as alan_g|EOD | ||
| kdub | any other takers? https://code.launchpad.net/~kdub/mir/fd-refcount/+merge/228306 | 17:09 |
| === chihchun is now known as chihchun_afk | ||
| racarr_ | why am I putting the pixel 0x00 0xff 0xff 0xff in to an argb buffer and getting green lol... | 17:52 |
| kgunn | racarr_: its really rgb ? ending up 00ffff ? | 18:07 |
| 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:10 |
| 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:11 |
| 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:12 |
| kgunn | racarr_: oh wait....rgba vs argb | 18:13 |
| kgunn | racarr_: suppose swap the values around would prove the theory | 18:13 |
| 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:36 |
| 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:37 |
| racarr_ | but my buffer says it should be argb8888, and I put in | 18:38 |
| 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:40 |
| racarr_ | grrr | 18:42 |
| kdub | racarr_, | 18:45 |
| 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:46 |
| racarr_ | I...feel like I must not understand what pixel formats | 18:47 |
| racarr_ | mean | 18:47 |
| racarr_ | why do we have something called pixel_format_argb if the pixels are bgra | 18:48 |
| 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:52 |
| 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:54 |
| 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:57 |
| racarr_ | so what on earth is GBM_FORMAT_ARGB8888 in memory.... | 18:58 |
| racarr_ | well | 18:58 |
| racarr_ | RGBA apparently | 18:58 |
| racarr_ | lol | 18:58 |
| kdub | we don't have a bgra format | 19:00 |
| kdub | probably because android doesn't have a corresponding pixel format | 19:03 |
| 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:04 |
| racarr_ | IO understand now | 19:05 |
| racarr_ | what confused me | 19:05 |
| racarr_ | was just the comment from the gimp C file outputer lol...the cursor image thing is ARGB in our terms. | 19:06 |
| racarr_ | ...do we have any other | 19:12 |
| racarr_ | transparent surfaces anywhere | 19:12 |
| 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:13 |
| racarr_ | and my renderable says shaped | 19:14 |
| 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:20 |
| racarr_ | ugh of course...my pixels arent premultiplied...I wonder how alan got gimp to produce such a nice black_arrow.c | 19:24 |
| kdub | oh, there's an output plugin | 19:26 |
| racarr_ | mm but it produces the pixels in the opposite order we need | 19:27 |
| 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:28 |
| kgunn | fwiw, ti did the same damn misnaming.... | 19:51 |
| kgunn | created the same headaches | 19:51 |
| kdub | yeah, the best is when like | 19:56 |
| kdub | marketing somehow gets involved ;) | 19:57 |
| racarr_ | lol... | 20:08 |
| racarr_ | premultiplied alpha sounds like something people might pay extra for | 20:09 |
| kdub | and even more for MostSignificantByte premultiplied alpha | 20:14 |
| kdub | with some tiling | 20:15 |
| racarr_ | lol | 20:16 |
| racarr_ | Whee...fresh install | 22:03 |
| racarr_ | feels nice :p | 22:04 |
| racarr_ | so how do I update this | 23:45 |
| racarr_ | server-ABI-sha1sums file | 23:45 |
| 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:47 |
| racarr_ | ok nvm maybe it will be fine | 23:48 |
| racarr_ | conflicts galore | 23:48 |
| racarr_ | ...sorry speaking outloud in half sentences | 23:48 |
| RAOF | Heh. | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!