| 14:11 | doublemalt | hi :) |
| 14:12 | doublemalt | Anyone knows how to get the serianl number of a cubox? dmidecode gives me a bus error |
| 14:25 | doublemalt | rather: who knows a ARM equivalent to dmi decode |
| 14:25 | doublemalt | ? |
| 15:59 | vpeter | DoubleMalt: I was using this in batch - |
| 15:59 | vpeter | bash |
| 16:02 | doublemalt | vpeter: thx. this helps! |
| 16:04 | vpeter | Wasusing few different boards and this was used to distinguish them (one image for all systems). |
| 16:07 | jnettlet | anyone had a chance to try the new kernel out. I just pushed one more fix for an old driver that probably nobody uses on the platform. |
| 16:15 | humpelstilzchen | hmm which kernel should we follow? I'm on |
| 16:19 | catwich | Humpelstilzchen: |
| 16:20 | humpelstilzchen | k |
| 16:35 | mk01 | jnettlet: did you succeeded on fixing the leak(or bad allocations) on viv-5 which was loosing EGL_context on EGLdisplay-destroy/re-create (on resolution change) ? |
| 16:47 | jnettlet | mk01, I believe I switched resolutions under Kodi. |
| 16:47 | jnettlet | although the current Kodi -rc seems to be quite a mess on the MX6 |
| 16:48 | jnettlet | Humpelstilzchen, that kernel is based on the Yocto community Freescale kernel. Hopefully we will be merging most those changes back to them. |
| 16:49 | mk01 | jnettlet: indeed - but that one was/is outside of xbmc sources. if you still have kodi install on it, please try to switch modes few more times - best not only Hz change, but reslutions with different mem allocation for display |
| 16:50 | mk01 | jnettlet: it could survived one - two changes, but sooner or later the re-created EGLDisplay got a different |
| 16:51 | mk01 | or simply I can compile and run it too... tell me, what lib version you use with it ? |
| 16:52 | jnettlet | whatever the latest is from yocto |
| 16:52 | mk01 | ok |
| 16:53 | jnettlet | sorry just came down from the pool, and don't have everything setup in the hotel yet |
| 16:53 | mk01 | NP |
| 16:56 | mk01 | then I might test it myself. |
| 17:11 | jnettlet | mk01, just changed resolutions about 8 times. |
| 17:11 | jnettlet | do I need to do anything else? |
| 17:11 | mk01 | nope |
| 17:12 | mk01 | then you fixed it |
| 17:12 | mk01 | if anything then this should be upstreamed to FSL as otherwise the v5 is unusable |
| 17:12 | jnettlet | the v5 driver are a mess |
| 17:54 | mk01 | so basically - EGLDisplayCreate (first one) gets an address - then EGLCreateContext based on that ptr creates context (at address2). now during change of res |
| 17:55 | mk01 | EGLunbindcontext -> ok, EGLDisplayDestroy -> ok, EGLdisplaycreate (with FB reinitialised with new mode) -> ok |
| 17:55 | mk01 | BUT |
| 17:55 | mk01 | if the new EGLDIsplay ptr is different from previous, EGLContextBind fails as you see |
| 17:56 | mk01 | if (by any chance) on EGLDispCreate the ptr is as the one from previous EGLDIsplay, the context fine to bind |
| 17:56 | mk01 | and resolution is changed |
| 17:57 | mk01 | (only as btw - normally one would reinit the context data and all would work, but somehow XBMC never ever imagined something like context reinit) |
| 17:58 | mk01 | could it be this is OUTSIDE of our reach (kernel code) ? |
| 17:59 | jnettlet | sounds like it is a combination of Kodi being a bit sloppy and the binary vivante drivers being a bit broken. They generally always have regarding contexts |
| 18:01 | mk01 | I woould even like to hear from guys at FSL/VIV, if by accident the v4 was working with that approach only thanks this being bug - now resolved in v5 libs |
| 18:01 | jnettlet | that could be a possibility as well |
| 18:02 | mk01 | unfortunatelly the EGL standard says nothing if context has to be destroyed when EGLDIsplay is destroyed |
| 18:02 | jnettlet | nope |
| 18:03 | mk01 | nope meaning - should not be destroyed or it is not defined ? |
| 18:04 | jnettlet | nope being it is unclear what should happen |
| 18:04 | mk01 | ok |
| 18:07 | mk01 | (in neither case the v5 flow is ok, as if ptr stays, it works, if has changed, context is seen as incompatible) |
| 18:10 | mk01 | very last sentence to this topic - that is not the usual use case with imx6 - everybody (on android) is re-creating the context on such events (egldisplay destroy)). |
| 18:11 | mk01 | I only found ONE project (i have the feeling it was directfb) doing the same - but that is not yet updated for v5 (and I wonder why) |
| 18:11 | mk01 | ;) |
| 19:46 | r0nd | anyone tried using a bluetooth headset with cubox? |