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