=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === duflu_ is now known as duflu [07:59] RAOF: yay, can I kill xmir-thread-proxy then? :P [08:46] duflu: @unfreeze-1, can I see the effect of this branch on the desktop too with full screen glmark2, or only on the phone? [08:46] alf__: Both (or in fact now only desktop since the workaround landed). bypass and overlays both have the same extra buffer requirement [08:47] duflu: thanks [08:50] mlankhorst: I'm a bit rusty on the subject.. do you know how long vblank actually lasts? [08:50] I think it's only a couple millisec at most? [08:55] yeah [08:55] why? [08:55] might be less with reduced blanking [08:56] mlankhorst: Just thinking about optimizations. And thinking I can rule out trying to do all rendering during vblank [08:57] mlankhorst: What's "reduced blanked" used for? [08:58] "reduced blanking" [08:58] less bandwidth requirement since there's no point in sending a blank signal for long on an old crt.. [08:58] nobody has a crt any more, it's all digital ;) [08:58] mlankhorst: Oh custom modes, as in Xorg? [08:58] https://en.wikipedia.org/wiki/Coordinated_Video_Timings#Reduced_blanking [08:59] no it's a standard [09:06] mlankhorst: Thanks. I estimate vblank is typically around 1ms then [09:06] Sometimes [09:06] That's useful [09:07] So we must always page flip or be efficient to reprogram CRTCs quickly [09:09] Or use atomic modesetting :P [09:15] will be there in time for final mir release ;-) [10:12] greyback_: WM status: Making another attempt at building default policy into libmirserver this week. [10:13] And about to make an attempt at dinner [10:13] duflu: ack. I've nothing of consequence to contribute [10:14] greyback_: Sounds positive. :/ OK then, night. [10:14] enjoy [10:18] why doesn't mir use render nodes when available? [10:41] alan_g: sorry I got the MRs mixed up, but yeah I was testing https://code.launchpad.net/~alan-griffiths/qtmir/new-migrate-to-mir-Server-API/+merge/243177 on my laptop and unity8 failed to start with it installed [10:41] greyback_: ack. I was just looking. BTW please tell me that "// FIXME(gerry) this will go very bad for >1 display buffer" has nothing to do with the problem. [10:42] alan_g: that refers to qtmir not supporting multi monitor. Not the problem here unfortunately [10:42] or fortunately.. [10:43] I thought so. But I thought I'd ask as you're here. === greyback__ is now known as greyback === dandrader is now known as dandrader|afk === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === dandrader|afk is now known as dandrader === chihchun_afk is now known as chihchun [12:04] hm weird [12:05] is anyone else running into the nesting limit of mir? [12:06] I've not tried it recently, but I have had 7 levels of nesting going on an N4 before getting bored [12:06] I'm testing on amd64, fails on the 4th level :P [12:07] http://paste.debian.net/134556/ [12:07] last one fails with: [12:07] get chip id failed: -1 [13] [12:07] param: 4, val: 0 [12:07] [intel_init_bufmgr:1068] Error initializing buffer manager. [12:09] in interests of simplicity I was debugging with Xmir, none of my breakpoints on the host or first level nesting fire on drmAuthMagic :/ [12:10] 3rd level being xmir, fourth being glxgears. those work at least.. [12:10] hm I guess I could do hardmode and force xmir to open a new fd for itself, reduces debugging by 1 :) [12:13] yeah, fails slightly faster.. mir_connection_drm_auth_magic is not handled correctly in nested case I guess.. === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [13:49] greyback: is there a Qt-style approach you'd favour to https://code.launchpad.net/~alan-griffiths/qtmir/new-migrate-to-mir-Server-API/+merge/243177 -c290 [13:49] (I'm still trying to confirm that the race fixed there is the condition you encountered.) === dandrader is now known as dandrader|lunch [14:03] alan_g: what you've got there is fine. Like we tend to prefer QMutex to std::mutex and things like that, but it's not essential === dandrader_ is now known as dandrader === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [15:10] the event time in mir is measured in nanoseconds? [15:15] ok, seems to be the case [15:16] attente_: yep, it's mir_event /= 1000000 to get what gdk likes ;) [15:18] RAOF: hey, do you have any idea why doing https://github.com/GNOME/gtk/commit/37ad6e11477060c74c2818210583b6fa37b1b027?diff=split (so submitting all the modified quads in a single VBO), breaks things in gdkgl? [15:18] Trevinho: thanks, just saw your change [15:19] attente_: maybe adding a #define for that might have been nicer [15:21] Trevinho: yeah, that sounds good === om26er is now known as om26er|dinner [16:50] camako, yeah, the android side its easy to keep the display around... iirc, the mesa side has some complication with VT's [16:50] camako, sorry, hit up+enter from yesterday [16:50] :-) [16:53] bschaefer: ping [16:53] oO what have I done [16:53] bschaefer: ping? [16:54] greyback, pong [16:54] bschaefer: hey, I want to test your SDL work (to finally review https://code.launchpad.net/~brandontschaefer/qtmir/correct-xrgb-support/+merge/238937) [16:54] greyback, sweet [16:54] bschaefer: do I need to build anything? [16:55] and can you gie me name of a game or 2 I can test [16:55] I would like to see what's needed to have Qt support mir_pixel_format_xrgb_8888 on big endian platforms [16:55] greyback, that actually doesn't fix the issue :( [16:55] ah [16:56] i tested the fix me self, thought would be nice to get another set of eyes [16:56] bschaefer: but it's something I can help with [16:56] greyback, right soo [16:56] greyback, a game hmm [16:57] greyback, for the phone you'll need a game that actually *fits* the size of the phone [16:57] which the only one that actually exists in main is scumvm [16:57] greyback, but its easier just to hack the size of the tests the come with the sdl branch [16:58] bschaefer: ok, I'll take the sdl branch. I need a custom branch? [16:58] greyback, yeah [16:58] Trevinho, what changes did you make to that branch? [16:58] or should i just give him my other one :) [16:59] bschaefer: ehm, what? [16:59] Trevinho, your sdl1.2 branch :) [16:59] greyback, mine: lp:~brandontschaefer/+junk/sdl1.2-mir [16:59] Trevinho, fixed some memory issues i had in mine IIRC [17:00] bschaefer: nice, did you include also the fixes for resolution stuff? [17:00] Trevinho, nope, i was wondering if we should just give greyback your branch [17:00] as its *more* up-to-date [17:00] bschaefer: not sure, as you prefer [17:00] greyback, just use mine for now, until i can see what was changed :) [17:00] greyback: mine is at https://code.launchpad.net/~3v1n0/+junk/sdl1.2-mir [17:00] ok [17:00] greyback, soo what you'll need to do on the phone [17:01] greyback: if you get crashes with it (as I had), just use mine :) [17:01] ./configure --disable-video-opengl [17:01] it's basically the same, but with few fixe [17:01] by adding that to debian/rules [17:01] greyback, let me double check if i did that already [17:01] bschaefer: why disabling opengl? no gles support? [17:01] no i haven't :( [17:01] greyback, this is true, are you running on the desktop? [17:01] ok [17:01] or the phone? [17:02] I'll be doing both [17:02] for the phone you'll need to disable opengl, as SDL1.2 does NOT support gles [17:02] and if you include opengl [17:02] it thinks its supported on the phone [17:02] since the headers exists [17:02] (annoying but idk the correct fix for that one) [17:02] bschaefer: btw the main thing you should incluide in your branch is http://bazaar.launchpad.net/~3v1n0/+junk/sdl1.2-mir/revision/13 [17:03] as in the desktop it will lead to crashes [17:03] Trevinho, ooo yeah [17:03] Trevinho, i realized this later when doing glfw but i've not changed that in sdl1.2 :) [17:03] thanks! [17:04] greyback, but pretty much, let me know when something isn't working :) [17:04] and i can help you haha [17:04] bschaefer: will do [17:04] bschaefer: np... I've tested with wormux and mplayer and both works well with it... Although the sdl1.2 fullscreen way seems quite oldish (it basically tries to change the resolution instead that increasing the window size) [17:04] good luck! [17:05] I've enough to play with for now [17:05] cool [17:05] bschaefer: and sdl2? [17:05] greyback, sdl2... i've not seen any color issues [17:05] bschaefer: ok, and it just works? [17:05] greyback, but its not using software renderering [17:06] it uses opengles on the phone, which might be *why* its working [17:06] greyback, i can test that out [17:06] greyback, but pretty much yes, SDL2 is a more completed port, and its also upstream :) [17:06] bschaefer: ok. What would you run to test it? [17:06] I just want to know these things so I test qtmir with them [17:06] hmm theres no great SDL2 examples, i've a few of my own [17:07] but theres tests in sdl2 it self [17:07] ok, those will do nicely [17:07] greyback, or this haha: https://github.com/BrandonSchaefer/SDLMazeGenerator [17:07] it just generates mazes [17:07] in SDL2 [17:07] perfect [17:08] it looks pretty, but it depends on a backend thingy: [17:08] so I see [17:08] https://github.com/BrandonSchaefer/SDLBackend [17:08] no biggie [17:08] greyback, pretty simple thing, i was just using that for most of my examples i've floating around [17:08] mainly to test SDL2 [17:09] bschaefer: great, thanks. If I've problems I'll be in touch :) [17:10] greyback, sweet, good luck! (also that MazeGenerator has the WIDTH/HEIGHT hard coded in. at ui/Main.cpp) [17:10] ack [17:22] greyback: where does the unity8 log go? [17:23] alan_g: ~/.cache/upstart/unity8.log [17:23] alan_g: note lp:~alan-griffiths/qtmir/new-migrate-to-mir-Server-API running nicely now, just need to check one thing [17:26] greyback: interesting (I won't mention it crashes strangely for me...) [17:26] alan_g: does it? Maybe I should test more... [17:29] greyback: but I'm having trouble running u8 even without my changes - so it may be unrelated. [17:29] But please do test some more [17:29] will do [17:36] * alan_g isn't sure how to test u8 and is prepared to believe greyback's results over his own for now. === om26er|dinner is now known as om26er [17:54] greyback: false alarm: It is the "refactored" branch that is crashing for me. The new-migrate-to-mir-Server-API branch seems stable. [17:54] * alan_g forgot a "push" [17:55] greyback: BTW is there a way to exit a u8 desktop session? (other than killing it from a VT) [18:05] * alan_g starts to dislike qmake === alan_g is now known as alan_g|EOD === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === greyback_ is now known as greyback [22:03] Trevinho: Breaks gdkgl in general, or only under Mir? [23:35] RAOF: under mir [23:35] RAOF: basically I get corrupted textures (well 2d textures), while the gl area is still working fine [23:36] by 2d textures I mean the cairo surface that should be drawn through gl, while the opengl view (for example, the classic gl gears) that are embedded works fine [23:36] There didn't seem to be anything there that would interact directly with anything Mir-specific... [23:37] RAOF: exactly... It only just changes the things so that it submit them at once or per each quad [23:38] RAOF: but for some reason that change breaks gdkgl in mir... at least in my setup (it would be even more weird if that could be driver specific)