| === mibofra is now known as Guest51348 | ||
| === mibofra is now known as Guest77133 | ||
| === chihchun_afk is now known as chihchun | ||
| === guest42345 is now known as oniix | ||
| === chihchun is now known as chihchun_afk | ||
| robert_ancell | What is the expected behaviour if a surface is created with an unsupported surface format? In XMir on Nexus 4 we use an unsupported format and the green and blue channels are swapped. Is something mapping between the formats and making a mistake or is this something we shouldn't be able to do? | 08:01 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| duflu | robert_ancell: I've fixed that in the next release 0.15. Added a client function that chooses the correct pixel format for your EGLConfig so that the colours are right | 08:18 |
| robert_ancell | duflu, bug? | 08:18 |
| robert_ancell | duflu, and that means you can provide any pixel fomat when creating a surface and it always works? | 08:19 |
| duflu | robert_ancell: Bug 1460149 | 08:19 |
| ubot5 | bug 1460149 in mir (Ubuntu) "Visible corruption in SDL apps (Neverball, Neverputt) on Nexus 4 / Nexus 7." [High,Triaged] https://launchpad.net/bugs/1460149 | 08:19 |
| duflu | robert_ancell: No. You need to choose your EGLConfig according to your desire first. Then there is only one right answer for the pixel format and the new function will tell you what it is | 08:19 |
| duflu | Set up EGL first, then create your surface. | 08:20 |
| robert_ancell | duflu, so the current behaviour is undefined or should have Mir thrown a fit by me giving an unsupported format? | 08:20 |
| duflu | robert_ancell: Current behaviour is buggy and hard to identify without the human visual system (if two channels appear wrong). Using the new client function in 0.15 however the colour mix-up won't happen | 08:21 |
| robert_ancell | duflu, you are saying there is a new helper function that will pick the correct format for me, right? | 08:22 |
| duflu | robert_ancell: Yes, it's super simple. Most of Mir's examples/ are already updated to use it | 08:22 |
| robert_ancell | duflu, right, so the question still stands - what is the contract Mir makes regarding passing a pixel format that is not in the supported list. | 08:23 |
| duflu | robert_ancell: It will try and ask your graphics driver (android/mesa) and see if it can create a surface with that format. Now only if the driver can't do it will it fail | 08:24 |
| robert_ancell | What is the definition of supported if there are formats outside that list that work? | 08:25 |
| duflu | robert_ancell: Your problem is you're asking for a supported pixel format, so it works. But the byte order is backwards to what EGL has in mind. So the new client function resolves that | 08:25 |
| robert_ancell | No, I'm asking for an unsupported format (it's hard coded and doesn't check the supported formats) | 08:26 |
| duflu | robert_ancell: "supported" is now defined as whatever the driver can create with. It will try whatever you give it, and fail surface creation if unsupported. Your issue is that it is supported but you're asking for the reverse format of what EGL's using | 08:27 |
| robert_ancell | So "supported" != all formats - "unsupported" | 08:28 |
| duflu | robert_ancell: Supported (for hardware surfaces) is no longer a fixed list in 0.15. We just ask the driver and it will tell you. Because different drivers have different abilities | 08:29 |
| duflu | The "supported list" you get technically is only right for software surfaces, and is a kludge even still | 08:30 |
| duflu | I only identified the problem and started fixing it recently | 08:30 |
| duflu | Actually for other reasons (bugs) Mir 0.15 on desktop will successfully allow all-but-one pixel format for software surfaces. But to support legacy clients that think the supported list is just for hardware, we don't yet advertise it. Probably needs an API extension | 08:32 |
| robert_ancell | OK, I think I'm even more confused than when I started. Does the "supported" list mean anything at all? | 08:33 |
| duflu | robert_ancell: So in summary, if you're using hardware (GL) surfaces, ignore the supported list. The reliable solution is the new function in 0.15 | 08:33 |
| duflu | The "supported list" still has a use for software clients only | 08:33 |
| robert_ancell | So, when does 0.15 land? | 08:33 |
| duflu | robert_ancell: Soon hopefully. We are about to start the release process. Although delays getting 0.14 finished are holding it up (that was major due to a client ABI break)\ | 08:34 |
| duflu | robert_ancell: I know... Mir's handling of pixel formats and byte ordering had a lot to be desired. I've cleaned it up significantly in 0.15 | 08:35 |
| duflu | It's always the way. You fix something hardly anyone is asking for yet, and before the fix it out, everyone needs it | 08:39 |
| robert_ancell | duflu, :) | 08:43 |
| greyback | duflu: hey, thanks for the qtmir patches, I hope to review them today. Sorry for the delay | 09:04 |
| duflu | greyback: No problem. I'm busy enough that I'd rather it took time anyway | 09:05 |
| duflu | robert_ancell: https://code.launchpad.net/~vanvugt/mir/one-for-robert-ancell/+merge/266194 | 09:06 |
| alan_g | alf: I moved this back to review for a fix, could you re-review? https://code.launchpad.net/~alan-griffiths/mir/fix-intermittent-memory-leak/+merge/266127 | 09:07 |
| alf | alan_g: looks good | 09:08 |
| alan_g | thanks | 09:08 |
| robert_ancell | duflu, thx | 09:11 |
| alan_g | greyback_: @add-display-config-option - fixed. (What ping?) | 10:53 |
| greyback_ | alan_g: I swear I pinged you on irc. | 10:55 |
| greyback_ | anyway | 10:55 |
| alan_g | greyback_: in unrelated news I've MP'd an initial WM change to qtmir: https://code.launchpad.net/~alan-griffiths/qtmir/use-WindowManager/+merge/266219 | 11:56 |
| greyback_ | alan_g: sweet, thanks | 11:56 |
| === alan_g is now known as alan_g|lunch | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | alf: don't try to push ~alan-griffiths/unity-system-compositor/add-display-config-option before Mir-0.15 - it depends on -c 2713 (which happend after 0.14 was forked) | 13:16 |
| alf | alan_g: ack | 13:19 |
| alan_g | alf: in case you want to see the end (I hope) of something you started: https://code.launchpad.net/~alan-griffiths/mir/enable-FD-leak-checking-for-acceptance-tests/+merge/266208 | 14:06 |
| alf | alan_g: \o/ | 14:06 |
| === greyback__ is now known as greyback | ||
| alf | alan_g: Is there a way to fix (as a future task) the g_source_attach() leaks that we currently ignore, or is the problem inherent in the way we do things? | 14:16 |
| alan_g | alf: I've not thought about it. | 14:18 |
| alf | alan_g: ok | 14:20 |
| alan_g | But it would be nice | 14:25 |
| === dandrader is now known as dandrader|afk | ||
| === chihchun_afk is now known as chihchun | ||
| alan_g | Rats! Where's Mir-0.15 when I need it? I want to write qtmir code that needs -c 2714... | 15:37 |
| * greyback still waiting for 0.14 in vivid+overlay. Hope it won't be long now | 15:47 | |
| mcphail | yes! ETA would be great | 15:48 |
| === dandrader|afk is now known as dandrader | ||
| === dandrader_ is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|EOD | ||
| davmor2 | mcphail: More than an hour less than a million | 17:34 |
| anpok | greyback_: too long is over.. | 17:41 |
| greyback_ | no wai | 17:42 |
| greyback_ | omg | 17:42 |
| * greyback_ creates a silo | 17:42 | |
| anpok | yeah not sure what I should to with that rest of the week.. | 17:42 |
| anpok | yeah releasing somethig should be good idea | 17:42 |
| === dandrader|afk is now known as dandrader | ||
| === chihchun is now known as chihchun_afk | ||
| === mibofra is now known as Guest27399 | ||
| === Guest27399 is now known as mibofra | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!