[17:30] <bschaefer> slvn_, this is how it looks :)
[17:30] <bschaefer> http://i.imgur.com/Vua6Iap.png
[17:30]  * bschaefer looking into it
[17:31] <bschaefer> it doesnt happen like that on the desktop...
[17:31] <bschaefer> (and touch wasnt working)
[17:31] <slvn_> bschaefer, this is bad, but this is because I provided a bad application
[17:31] <bschaefer> slvn_, no, all apps
[17:31] <bschaefer> even my own
[17:31] <bschaefer> (using opengles2)
[17:31] <bschaefer> not sure if those are software or what
[17:31] <slvn_> then there is a bug :)
[17:31] <bschaefer> yup
[17:32]  * bschaefer looking into it
[17:32] <bschaefer> tic tac toe: http://i.imgur.com/tLA6jtn.png
[17:32] <bschaefer> there must be a reason :)
[17:32] <slvn_> yep bad also ...
[17:32] <slvn_> at least portrait/landscape orientation seems to work :)
[17:33] <slvn_> (but there is the status bar ... would be great to be able to hide it, or to know its size/position)
[17:35] <slvn_> also the colors seems wrongs. it's black and white ok, but there is some noise.
[17:36] <bschaefer> slvn_, you've to set the surface to fullscreen
[17:36] <bschaefer> to move the top bar
[17:37] <slvn_> ok
[17:38] <slvn_> for the Tic Tac Toe, some debug message are enabled .. it might help
[17:38] <slvn_> maybe the resolution that I retrieve if wrong
[17:40] <bschaefer> slvn_, ill use my own for now since i've the source :)
[17:40] <bschaefer> yours will be the test after a fix
[17:40] <slvn_> ok !
[17:57] <slvn_> bschaefer,  Maybe that can help : when we tested the same apps on McPhail device, there was no issue of rendering ! (though I saw no screenshot)
[17:57] <bschaefer> slvn_, was it vivid+overlay?
[17:57] <bschaefer> or was it wily/xenial?
[17:58] <slvn_> I guess his device is vivid. and the app is vivid+overlay
[17:58] <slvn_> the app I sent you is vivid+overlay
[17:58] <bschaefer> well then it shouldnt run :)
[17:58] <bschaefer> if his device is vivid only then mir is like 0.13
[17:59] <slvn_> no sorry, his device is problably vivid+overlay also
[17:59] <bschaefer> yeah
[17:59] <bschaefer> hmm
[17:59] <slvn_> we need you branch :)
[17:59] <slvn_> the app is then vivid+overlay+your_branch
[17:59] <bschaefer> https://code.launchpad.net/~brandontschaefer/+junk/SDL2-new-mir-ABI
[17:59]  * bschaefer is getting his phone setup to debug and hopes he doesnt run out of space
[18:00] <bschaefer> cross compiling takes to long
[18:00] <bschaefer> i also need to check unity8 desktop... to see if the same issue
[18:00] <bschaefer> if thats the case it might be qt/mir
[18:00] <bschaefer> but ... not really sure atm
[18:02] <bschaefer> slvn_, the one thing sdl2 does strangly is talks to mir directly
[18:03] <bschaefer> vs going through the mir platform
[18:03] <bschaefer> which *could* cause strange issues (possibly?)
[18:04] <slvn_> it talks to mir to configure the screen/surface, then it does opengles2 things
[18:04] <slvn_> maybe we could check that the renderer is actually opengles2
[18:04] <bschaefer> wait... i didnt actaully check opengles2...
[18:05] <bschaefer> but it should use opengles
[18:05] <bschaefer> slvn_, i have an app that is 100% opengles2 (otherewise it'll fail)
[18:05]  * bschaefer should test that out
[18:06] <bschaefer> if its all software rendering then it could be my fault (some how getting 1/2 on my stride)
[18:15] <bschaefer> slvn_, http://i.imgur.com/ZEyDjRW.png
[18:16] <slvn_> it could YUV
[18:16] <slvn_> it could be YUV
[18:16] <slvn_> mis interpretation of pixel format
[18:16] <bschaefer> yeah, which would mean 1/2 stride
[18:17] <bschaefer> meaning clone surface
[18:17] <bschaefer> (ie. RGB16 vs RGB32)
[18:23] <slvn_> Could be the algorithm in SDL2 that set the GLES2 config that does somethings wrong ...   see SDL_EGL_ChooseConfig() ..  the first config should be the better
[18:25] <bschaefer> slvn_, it is most likely me picking a pixel format that is to large while the surface is actually a 16
[18:25] <bschaefer> so if i think its rgb32, i create a surface that is twice the size
[18:25] <bschaefer> of the actual surface in sdl2
[18:26] <bschaefer> soo im copying (two chunks of the same thing)
[18:26] <bschaefer> theres also this nice new function:
[18:26] <bschaefer> client/mir_toolkit/mir_connection.h:194:MirPixelFormat mir_connection_get_egl_pixel_format
[18:29] <slvn_> I should patch SDL2/mir backend ?
[18:30] <bschaefer> slvn_, naw its my problem :)
[18:30]  * bschaefer is looking into fixing it
[18:31] <slvn_> ok L)(
[18:31] <slvn_> :)
[18:55] <mcphail> Hi slvn_ and bschaefer. I'm not getting that odd doubling on my phone, nor errors with the rendering of the balloons.
[18:57] <bschaefer> mcphail, what version of sdl2 are you using?
[18:57] <mcphail> bschaefer: whichever one slvn_ bundled with his app. I don't have the source
[18:58] <bschaefer> hmm
[18:58] <bschaefer> mcphail, what are you running on your phone? vivid+overlay?
[18:58] <bschaefer> or wily/xenial?
[18:58] <bschaefer> mcphail, also what phone do you have?
[18:58] <mcphail> bschaefer: I'm running stock, so I presume it is vivid+overlay
[18:58] <bschaefer> as right now it looks like an incorrect pixel format
[18:58]  * bschaefer has a nexus 4
[18:59] <mcphail> perhaps it is the same rendering bug reported by popey a while back?
[19:00] <mcphail> https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1460149
[19:02] <bschaefer> mcphail, i think that was different
[19:02] <bschaefer> that actually looks like corruption
[19:02] <bschaefer> what i have is just pixel format issues
[19:02] <mcphail> bschaefer: see comment 18
[19:03] <bschaefer> i even made a comment on that
[19:03] <bschaefer> umm
[19:03]  * bschaefer re-reads
[19:05] <bschaefer> mcphail, but yeah mir supports 16 PF now...
[19:05] <bschaefer> 16 bit pixel formats
[19:05] <mcphail> aah ok
[19:05] <bschaefer> (in 0.17), unless ... that landed?
[19:05] <bschaefer> later
[19:05] <bschaefer> naw it should have landed in 0.16
[19:05] <mcphail> I think it is 0.16 on the phones?
[19:06] <mcphail> I'm certainly not getting rendering issues on mine (except the tictactoe grid doesn;t have any horizontal bars - probable resolution issue)
[19:07] <bschaefer> mcphail, 0.17 is on the phone
[19:07] <bschaefer> from the overlay
[19:07] <bschaefer> mcphail, what device do you have?
[19:07] <mcphail> krillin (bq 4.5)
[19:08] <bschaefer> i could try it out on that... but im thinking that might not support the pixel format that is getting hit on the N4
[19:08] <mcphail> might explain why the N4 seems to hit more rendering bugs than the bq
[19:09] <mcphail> the issue I get with the games is the touch input doesn't work properly
[19:09] <bschaefer> yeah that... i have to to look into its only
[19:09] <bschaefer> up/down motion still works
[19:09] <bschaefer> at lease was working for me
[19:10] <mcphail> first touch works, but subsequent ones are ignored. Did slvn_ copy you in to the log from my phone?
[19:10] <bschaefer> yeah
[19:10] <bschaefer> err
[19:10] <bschaefer> not the log
[19:10] <bschaefer> but
[19:11] <bschaefer> i've seen that issue before on the N7
[19:11] <slvn_> I can explain this issue
[19:11] <bschaefer> where you get a down, but never an up
[19:11] <slvn_> what happens is there are lot for FINGER_DOWN but no FINGER_UP
[19:11] <bschaefer> yeah
[19:11] <slvn_> not enough FINGER_UP
[19:11] <slvn_> and, I think there are multiple reasons for the missing finger_up
[19:12] <slvn_> one of the reasons, if the "event" action_cancel, that should emit some finger_up
[19:12] <slvn_> which is not in the backend I think
[19:13] <slvn_> other reasons are more obscure ... the way of decoding the datas ...
[19:13] <bschaefer> slvn_, that might explains some issue i dont remember that action
[19:51] <slvn_> bschaefer, mcphail  here's my old SDL_mirevents.c  with modifications to fix/workaround the input issue :  http://paste.ubuntu.com/13210696/
[19:53] <slvn_> see mir_motion_action_cancel and also mir_motion_action_pointer_up
[19:53] <bschaefer> slvn_, that doesnt exist anymore :(
[19:53] <bschaefer> action wise
[19:54] <slvn_> and as a "diff" : http://paste.ubuntu.com/13210720/
[19:55] <slvn_> action_cancel does not exist anymore ?
[19:55] <bschaefer> nope
[19:55] <slvn_>  action_pointer_up
[19:55] <bschaefer> slvn_, mir event 2.0 changed a lot
[19:55] <bschaefer> theres: mir_touch_action_up = 0,     mir_touch_action_down = 1,  mir_touch_action_change = 2
[19:55] <bschaefer> for touch events
[19:55] <slvn_> ... what is important is the "for()" loop in action_pointer_up to do a up on all events.
[19:56] <bschaefer> yeah
[19:56] <slvn_> maybe there is no more action_cancel bug then !
[19:56] <bschaefer> you need to go through and eat all the touch events
[19:56]  * bschaefer looks at his touch code
[19:57] <bschaefer> slvn_, http://paste.ubuntu.com/13210751/
[19:57] <bschaefer> thats the current touch code...
[19:57] <bschaefer> and i loop through it all
[19:57] <bschaefer> but i still see touch issues up/down
[19:57] <slvn_> is there still the android layer under mir to handle touch/input ?
[19:58] <bschaefer> currently yes
[19:58] <slvn_> so this action_cancel probably still exists
[19:58] <bschaefer> not in the mir public api
[19:59] <bschaefer> (android most likly)
[19:59] <slvn_> so maybe it should be translated as several finger_up
[19:59] <bschaefer> slvn_, if its only an issue in SDL2 then i must just be doing something wrong :)
[19:59] <bschaefer> ie. it seems to work fine in all other QT/QML apps
[19:59] <slvn_> are they using multiple fingers?
[20:00] <bschaefer> slvn_, we have having issues with just 1 figure
[20:00] <bschaefer> and i assume yes
[20:02] <slvn_> it's easy to see if the bug is in (SDL+SDL_mir_backend) or in (mir+...)
[20:02] <slvn_> just log the up / down
[20:02] <slvn_> + ids
[20:03] <slvn_> for each finger down, there must be a finger up
[20:03] <slvn_> I mean, that what SDL rely on .. but SDL could also be more robust by implement some timeout etc.
[20:07] <bschaefer> slvn_, one issue i saw is: AddTouchDevice(device_id);
[20:08] <bschaefer> was in the for loop
[20:08] <bschaefer> for each touch event
[20:08] <bschaefer> (that could cause some sort of issue with sdl2 under the hood but idk
[20:12] <slvn_> bschaefer, AddTouchDevice is still in the for loop !
[20:12] <bschaefer> yeah i just moved it
[20:12] <bschaefer> but idk
[20:12] <bschaefer> what it does atm, need to look at that
[20:12] <slvn_> like before
[20:12] <slvn_> no, before and now, it has always been there
[20:12] <bschaefer> im not sure what sdl2 does (if its a mapping of the id then it shouldnt matter)
[20:12] <bschaefer> yeah
[20:12] <bschaefer> im not sure if thats causing a sync issue
[20:13]  * bschaefer just needs to check the mir logs
[20:13] <bschaefer> for up/down touch events
[20:13] <slvn_> AddTouch is for SDL only
[20:14] <bschaefer> ... why does it even compile
[20:14] <bschaefer> i dont see that function anywhere haha....
[20:14] <slvn_> wrapper to SDL_AddTouch
[20:15] <bschaefer> but its not defined anywhere... unless grep is failing me
[20:15] <slvn_> in  SDL/src/events/SDL_touch.c
[20:16] <bschaefer> i see SDL_AddTouch
[20:16] <bschaefer> i just dont see AddTouchDevice
[20:16] <slvn_> and SDL_mirevents.c
[20:16] <slvn_> AddTouchDevice
[20:16] <bschaefer> slvn_, im just saying AddTouchDevice is not defined anywhere
[20:16] <bschaefer> and i dont see a
[20:17] <bschaefer> #define AddTouchDevice SDL_AddTouch
[20:17] <slvn_> no no, in SDL_mirevents.c, static void AddTouchDevice
[20:17] <slvn_> just doing a SDL_AddTouch
[20:17] <bschaefer> slvn_, ug
[20:18] <bschaefer> im not use to
[20:18] <bschaefer> static NEW LINE
[20:18] <bschaefer> AddTouchDev :)
[20:18] <bschaefer> slvn_, confirmed the cloning issue
[20:19] <bschaefer> assume the PF is 32, and setting it to such, even though we are a 16 pF
[20:19] <bschaefer> PF*
[20:20] <slvn_> ok, not sure of the implication though ...
[20:21] <bschaefer> it what causes the cloning
[20:21] <bschaefer> of the surfaces
[20:21] <bschaefer> ie. the two copies
[20:21] <bschaefer> sooo now its just trying to figure out how to pick the correct PF (which can prove to be hard)
[20:21] <mcphail> bschaefer: ha! - so it _is_ the same as the bug above ;)
[20:21] <bschaefer> mcphail, yeah :) (it looks that way)
[20:22] <bschaefer> mcphail, the issue atm is, i just loop through the available pixel formats
[20:22] <bschaefer> and return when one is supported (to use as the PF for the mir surface)
[20:22] <bschaefer> but the PF that is actually given to EGL is 565
[20:22] <bschaefer> and we create a mir surface of 888
[20:23] <mcphail> is there a robust way to fix that?
[20:24] <bschaefer> mcphail, yes but it crashes atm :)
[20:24] <bschaefer> and is fixed in 0.17.1
[20:24] <bschaefer> but overlay+vivid is 0.17.0
[20:35] <mcphail> bschaefer: so close..!
[20:37] <bschaefer> quite :) (well hopefully it fixes it)
[21:29] <slvn_> bschaefer, mcphail  I am leaving the chan. I would be glad to have some news by email. I'll be there tomorrow++
[21:30] <bschaefer> c ya
[21:30] <mcphail> slvn_: cheerio
[21:30] <slvn_> bye!
[21:31] <bschaefer> hmm so far testing output on touch... when i hit a down, i get an up...
[21:31] <bschaefer> but i dont have a good app to test atm :(
[22:56] <bschaefer> mcphail, haha... guess why touch didnt work :)
[22:56] <bschaefer> HandleTouchPress(device_id, id, SDL_FALSE, n_x, n_y, pressure);
[22:56] <bschaefer> was being sent for DOWN
[22:56] <bschaefer> and for UP
[22:56] <bschaefer> HandleTouchPress(device_id, id, SDL_TRUE, n_x, n_y, pressure);
[22:56] <bschaefer> wellllll
[22:56] <bschaefer> SDL_TRUE is the slot for DOWN being true
[22:57] <bschaefer> soo i just flipped those around when i re factored the code...
[22:57] <bschaefer> so when we get a DOWN action we were saying DOWN is false and when we got an UP action we were saying a DOWN has happened
[23:14] <mcphail> bschaefer: nice catch! This is the advantage of having people writing games for the device in SDL - highlights these problems.
[23:15]  * mcphail might retry his Baldur's gate port
[23:18] <bschaefer> o.m.g someone ported that game?
[23:18] <bschaefer> to sdl2?
[23:18] <mcphail> bschaefer: I have a port which gets as far as the menu
[23:18] <mcphail> bschaefer: using gemrb
[23:19] <bschaefer> mcphail, nice! I've not heard of those, but i loved baldurs gate haha
[23:20] <mcphail> bschaefer: unfortunately, my porting has been delayed by the fact I'm wasting so much time playing Planescape Torment on the PC... :)
[23:20] <bschaefer> haha
[23:20] <bschaefer> the down side of porting games, testing to long :)
[23:23] <mcphail> bschaefer: also hampered by the ever-growing list of games on Steam. My life is ruined
[23:24] <bschaefer> haha
[23:24] <bschaefer> very true
[23:25] <mcphail> bschaefer: incredibly cool to see the BG intro on the phone, though
[23:26] <bschaefer> mcphail, yup had the exact feeling when i saw the dota2 intro
[23:26] <bschaefer> (on the desktop)
[23:27] <bschaefer> though i had a multi thread gl context bug after that, that ended with me digging through the video driver...
[23:27] <bschaefer> but still fun... i've to get that working again so much has changed
[23:27]  * bschaefer heads to a bar to do some work
[23:27] <mcphail> bschaefer: the life of a linux gamer will never be easy, i suspect
[23:27] <bschaefer> :)