| 00:31 | heap | foresto: i dont need RAID i need LVM |
| 00:31 | heap | these days RAID is waste of money i think .. ill backup everything into cloud |
| 00:35 | curlymo | or use ZFS :) |
| 00:35 | curlymo | i use it for my offsite ZFS backup on my HB i2eX. |
| 00:36 | curlymo | by default shipped in the xbian apt pool together with kernel 3.14.14 |
| 01:05 | heap | nice |
| 01:06 | heap | so this enclosure should work fine with esata + cubox? |
| 01:16 | heap | i dont know there are enclosures that support JBOD/RAID and there are some that dont |
| 01:16 | heap | do i need the one with JBOD support? |
| 12:43 | topi` | I'm trying to get gstreamer to work, using imxipusink, it works just fine under framebuffer console, but if I run X, then it doesn't display anything |
| 12:43 | topi` | any ideas? |
| 12:44 | jnettlet | topi`, that will only work on the raw framebuffer |
| 12:44 | catscrash | Cheers. I noticed only progressive output like 1080p is possible in the cubox kernel. I'd love to be able to output 1080i to my projector. Can you tell me why it was deactivated? Is there anything one can do to make it work? |
| 12:47 | MarcusVinter | Good morning! |
| 12:50 | topi` | jnettlet: it also works, if I start gstreamer in the virtual console, and then switch to the console where X is |
| 12:50 | topi` | it starts to draw over X's content (windows and such) |
| 12:50 | sopparus | anyone gotten spdif or usb audio to work on adroid? |
| 12:51 | sopparus | does anyone care/work about it or should I use my cubox for something else |
| 12:51 | sopparus | couse I was planning to use it as a spotify connect target only |
| 12:51 | sopparus | just to notice I cant.. :) |
| 12:51 | topi` | jnettlet: we also need to support HTML5 video tag on webkit, and webkit-gtk is using gstreamer with some OpenGL abstractions to provide accelerated video decoding... how far are we in getting OpenGL (or maybe GLES) working with the 3.14 kernel? |
| 12:54 | jnettlet | topi`, it works already |
| 12:55 | jnettlet | but the webkit-gtk HTML5 implementation is absolute garbage |
| 12:55 | topi` | yes, we're thinking of just launching mplayer on top of the browser |
| 12:55 | jnettlet | Chromium has already been patched to fully support video acceleration |
| 12:55 | cbxbiker61 | jnettlet, there's OpenGL libs for imx now? |
| 12:56 | topi` | cbxbiker61: I believe Freescale is working on it |
| 12:56 | jnettlet | cbxbiker61, from FSL/Vivante yes |
| 12:56 | jnettlet | You just need to use an older version of X |
| 12:56 | topi` | that's out of question |
| 12:57 | jnettlet | Then you are going to have to wait because the newer drivers that will be out 1st quarter next year will only support Xorg 1.15 from what I understand. |
| 12:57 | cbxbiker61 | i just saw on phoronix that Mesa code is improving on rpi, i just can't imagine doing anything real interesting on pi/Mesa |
| 12:57 | jnettlet | I haven't looked at the ABI changes to see if they will be automatically obsolete |
| 12:58 | topi` | there'll be an ABI check in Xorg's module loader... |
| 12:58 | jnettlet | cbxbiker61, actually the GPU is one of the better chips on that device. Still nothing to roar about |
| 12:58 | jnettlet | topi`, you can disable that |
| 12:58 | topi` | ok |
| 12:59 | cbxbiker61 | it's good for video decode, i'm just not sure how well the GL would work, and the CPU is just so damn slow |
| 12:59 | jnettlet | and no NEON |
| 12:59 | cbxbiker61 | yep |
| 12:59 | jnettlet | not ideal for multimedia |
| 13:00 | topi` | no ARMv7 is a dealbreaker |
| 13:00 | topi` | we don't want to have a zillion different versions, debian/armhf will have to work for every platform |
| 13:01 | cbxbiker61 | yeah armv7 gives you a lot of sub-arch choices |
| 13:01 | topi` | I can't understand why the RPi guys didn't design the original RPI around an ARMv7 architecture in the first place (cortex-a8 *is* very old) |
| 13:01 | cbxbiker61 | cost was primary |
| 13:01 | topi` | going with an ARMv6 cpu made the product obsolete already before it shipped |
| 13:02 | topi` | there are very cheap armv7 chips around |
| 13:02 | topi` | some are ridiculously cheap, like the Cortex-A5 cores |
| 13:02 | fritsch | the pi's cpu is so slow, that it got a special resampler |
| 13:02 | fritsch | gpu driven |
| 13:02 | fritsch | cause it could not cope with creating the ffmpeg resampler context |
| 13:02 | fritsch | in reasonable time |
| 13:02 | cbxbiker61 | A5 wasn't around when the pi launched was it? |
| 13:02 | fritsch | needed roughly 300 to 500ms |
| 13:03 | fritsch | but yeah, the PI (in xbmc environment) got the best ever support I have seen in that environment |
| 13:03 | fritsch | without that massive amount of work done by popcornmix |
| 13:03 | topi` | cortex-A5 was announced in 2009 |
| 13:03 | fritsch | nobody would use it anymore today |
| 13:03 | fritsch | if the same optimization for cubox happens, then we can be happy |
| 13:03 | topi` | maybe there were no suitable SoCs using it... |
| 13:04 | cbxbiker61 | fritsch, kodi is running pretty well for me now on cubox-i |
| 13:04 | fritsch | cbxbiker61: yeah, yeah ... some things the pi can do are currently worked on and still missing |
| 13:04 | cbxbiker61 | a few odd crashes here and there that seem to be caused by bad data |
| 13:05 | curlymo | @fritsch, like what? |
| 13:05 | fritsch | that's fine, yesterday we fixed the refreshrate switching issue |
| 13:05 | fritsch | and wolfgar made a fix for some uncommon h264 formats |
| 13:05 | fritsch | with that in, hope to be allowed to push that today |
| 13:05 | fritsch | helix is pretty fine |
| 13:06 | fritsch | missing for now: 100% perfect deinterlacing for 1080i50 content, we are "roughly" there, 10% missing perhaps for the i4pro |
| 13:06 | fritsch | hopefully I get time over christmas to look into a bobbing shader ... |
| 13:06 | cbxbiker61 | fritsch, i'm confident that kodi on the imx6 will stabilize at a level equal to the rpi, the pi has had a long time to work out the kinks |
| 13:06 | fritsch | kodi+1, yes |
| 13:07 | fritsch | we won't pull the deinterlacing work by Jan to kodi |
| 13:07 | fritsch | but when master is open again, that's the first thing we will pull in for IMX |
| 13:07 | jnettlet | The i4p should be fine for 1080i50 content. it is the iMX6DL that is the problem. I can only get it up to 23fps |
| 13:07 | fritsch | jnettlet: i think it's currently rather an xbmc problem |
| 13:07 | fritsch | jnettlet: seen the sample i posted in PR? |
| 13:07 | jnettlet | nope |
| 13:08 | fritsch | https://github.com/xbmc/xbmc/pull/5805 <- code (you will know I think) |
| 13:08 | fritsch | would be nice to get some words on the "userspace splitting" we do from your kernel pov |
| 13:08 | fritsch | and here are the samples: |
| 13:09 | cbxbiker61 | fritsch, it's a boon to cubox-i having you work on the code |
| 13:09 | fritsch | http://solidrun.maltegrosse.de/~fritsch/ <- samples |
| 13:09 | fritsch | basically I jumped in to form a team at an upstream location |
| 13:09 | jnettlet | fritsch, well there are all sorts of horrible bugs in the frame rendering code |
| 13:10 | fritsch | jnettlet: i would be soo happy if you could comment and review |
| 13:10 | fritsch | bugs are there to be fixed :-) |
| 13:10 | fritsch | the samples are typical LiveTV (720p50, 1080i50, 576i50) |
| 13:10 | fritsch | if those work, all is fine |
| 13:11 | jnettlet | I found more than a few places that do a min(value, 1) then pass that to a function that immediately does a max(value, TIMEOUT) so basically you are always getting the same TIMEOUT and missing vsyncs |
| 13:11 | cbxbiker61 | i switched to Blue Glass Nova skin, it makes kodi feel much cleaner/modern |
| 13:11 | jnettlet | fritsch, yeah with my kodi version I can play all those okay |
| 13:12 | fritsch | jnettlet: any link to your patches? |
| 13:12 | jnettlet | although the audio can get out of sink |
| 13:12 | jnettlet | fritsch, nothing pushed. I haven't had the time |
| 13:12 | fritsch | if render is too slow and skipping / dropping does not work, it won't stay in sync, yes |
| 13:12 | fritsch | after 200ms the dvdplayer does a resync |
| 13:13 | fritsch | besides that there is an advanced architecture, bound to a refclock (video wise not there on imx) to care for such things in combination with vblanks |
| 13:13 | fritsch | we are not yet finished :-) |
| 13:13 | fritsch | but state is not bad at all |
| 13:13 | fritsch | but, concerning your improvements: it would be very nice to see that code - as it's not working for the rest of the planet |
| 13:14 | fritsch | and doing that work twice or triple |
| 13:15 | fritsch | is not good (especially as you sell a TV version of the box) |
| 13:15 | fritsch | okay, so much about politics. As I have you here, one question: |
| 13:15 | fritsch | The GC-880, what about it's performance? Should it be able to cope with the named content, too? |
| 13:16 | fritsch | cbxbiker61: and about the "boon". Others do the code (I only did Audio code), but to concentrate development at one point, where everyboday can contribute and get "the" code, was my intention |
| 13:16 | fritsch | cbxbiker61: besides that I really like the form factor |
| 13:17 | jnettlet | easily. we are only outputting at 60fps max |
| 13:17 | cbxbiker61 | yes, the box is nice ff |
| 13:18 | fritsch | jnettlet: so, 1080i50 + output should be no issue at all? Even at doublerate, e.g. frame per field? |
| 13:18 | fritsch | output at 50hz then |
| 13:18 | jnettlet | it is a problem with the current rendering pipeline not the GPU. |
| 13:19 | fritsch | okay |
| 13:19 | jnettlet | the iMX6S has no chance |
| 13:19 | jnettlet | 400mhz 32-bit |
| 13:19 | jnettlet | you need atleast 64-bit to have any chance |
| 13:19 | fritsch | okay, so the way we do the dma buffers and use the EGL interaction is plain wrong? |
| 13:20 | fritsch | jnettlet: imx6s - sorry for that dump question - which box has that one? |
| 13:21 | jnettlet | that is the lowest end microsoms |
| 13:21 | fritsch | jnettlet: as you know wolfgar and smallint, please give them some pointers, so they don't concentrate into the wrong direction. Thy invest a whole lot of time to make your product kodi aware. |
| 13:21 | jnettlet | most the problems I have found are more general xbmc inefficiencies than any of their work. |
| 13:22 | jnettlet | really the entire video renderer needs to be burned to the ground and re-architected |
| 13:23 | fritsch | we have some very efficient Interop methods in the GL case |
| 13:23 | fritsch | that e.g. vdpau is using |
| 13:23 | fritsch | but, internal discussion wants to redo a big part of this after helix |
| 13:23 | jnettlet | but you can test with gstreamer. it has no problems with any of this content. |
| 13:23 | fritsch | anything more concrete, where we could win something in short term? |
| 13:24 | fritsch | the step from decoding buffer to EGL is via the dma buffers is not a very "far" step |
| 13:24 | fritsch | and there it's not touched anymore |
| 13:24 | fritsch | so I am quite curious |
| 13:33 | jnettlet | fritsch, lots of little things. too hard to explain. Right now I am working on fixing the VPU clocks in our kernel. It will allow clocking the VPU faster on demand |
| 13:34 | jnettlet | It will need testing. the FSL docs say the VPU can be clocked up to 520Mhz |
| 13:35 | jnettlet | I think FSL limits it due to the thermal management necessary but now that I have a better reverse scaling driver I think we can push it more. |
| 13:36 | fritsch | jnettlet: okay, will stay tuned in that regard. If you need something from upstream kodi or find something really, really bullshit, just tell me :-) |
| 13:36 | fritsch | then we can do something about it |
| 13:38 | catscrash | There's a patch for interlaced output to HDMI for iMX6 Kernel here: https://community.freescale.com/docs/DOC-100657 is this something that could be implemented into openelec? |
| 13:39 | fritsch | nope |
| 13:39 | fritsch | as the way our render works is progressive |
| 13:39 | fritsch | you would need to bypass a lot of infrastructure |
| 13:45 | catscrash | damn. So there's nothing I can do to get interlaced output? |
| 14:05 | rabeeh | catscrash: what? you want 1080i50 output to the TV? |
| 14:05 | rabeeh | the discussions is how to get CuBox-i to de-interlace while outputting to the TV progressive |
| 14:05 | rabeeh | is that what you mean? |
| 14:06 | catscrash | no, I actually want 1080i50 or 1080i60 output |
| 14:06 | catscrash | my projector can do SBS only in 780p or 1080i |
| 14:06 | catscrash | but not in 1080p |
| 14:06 | rabeeh | hmm.... i don't know if that it's even possible by the IPU |
| 14:07 | rabeeh | i.e regardless if there is driver support or not; i don't know if the IPU can do that at all. |
| 14:07 | catscrash | mh, ok |
| 14:07 | catscrash | with the rpi it was a thing of setting the right mode number in the config file |
| 14:08 | catscrash | otherwise I'd need to recode everything to Top-Bottom 3D, that I can play with 1080p24 |
| 14:08 | rabeeh | let me search in the docs again |
| 14:08 | catscrash | thanks :) |
| 14:10 | rabeeh | oh - first link - https://community.freescale.com/docs/DOC-100657 |
| 14:10 | rabeeh | but those are for LK 3.0.035 |
| 14:10 | catscrash | yep, that was the one I posted earlier, but fritsch said it's not possible |
| 14:11 | sopparus | rabeeh, do you know if anyone is working on spdif/usb audio support on android, or is something not many care about? |
| 14:11 | jnettlet | fritsch, is there plans for a gbm driver anytime soon? |
| 14:12 | topi` | jnettlet: it seems there's WebKit for Wayland under construction, I wonder if that'll have better ways to playback web video than the webkit-gtk port? |
| 14:13 | rabeeh | sopparus: i though fsl had that supported somewhere |
| 14:13 | topi` | "EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content." |
| 14:13 | jnettlet | topi`, are you morally against using chromium? |
| 14:13 | sopparus | rabeeh, what is fsl?:) |
| 14:13 | rabeeh | freescale |
| 14:13 | topi` | jnettlet: I don't know of any way of embedding chromium inside my python code |
| 14:13 | topi` | webkit-gtk bindings for python are robust |
| 14:13 | sopparus | hmz |
| 14:14 | jnettlet | topi`, there is a chromium embedded layer |
| 14:14 | jnettlet | https://code.google.com/p/cefpython/ |
| 14:14 | topi` | also I need to check chromium's license |
| 14:17 | jnettlet | topi`, having dealt with webkit-gtk's HTML5 support for the OLPC project. I would definitely not recommend you build a product on it. With current versions the JIT engine for javascript is broken on ARM again |
| 14:19 | topi` | ugh |
| 14:32 | fritsch | jnettlet: nope, not planned |
| 14:32 | jnettlet | fritsch, what are the plans for KMS only drivers? |
| 15:23 | topi` | damn, Unknown CMake Command APPEND_PLATFORM_SOURCES while trying to build cef 3.2217.1950 |
| 15:24 | topi` | I'm not a fan of CMake, particularly |
| 15:28 | jnettlet | topi`, it is because you have too much self esteem. Once you hate yourself some more you will come to terms with CMake |
| 15:30 | curlymo | @jnettlet, totally agreed! :) |
| 15:31 | fritsch | jnettlet: https://github.com/xbmc/xbmc/pull/2681 <- |
| 15:32 | MarcusVinter | rabeeh, did you get time to look at my email? |
| 15:33 | topi` | it's complaining about not finding cmake_minimum_requirements(...) although the bloody line IS right there in CMakeLists.txt |
| 15:33 | topi` | *sigh* |
| 15:34 | topi` | jnettlet: there's a "readymade" python setup.py for installing cef3 python bindings, but it's including a amd64 version of the libcef shared library, which is a problem for an ARM host... so I need to recompile that for armv7 |
| 15:35 | topi` | about time developers would take notice that there ARE other architectures around nowadays... |
| 15:37 | jnettlet | lol |
| 15:43 | jnettlet | fritsch, that seems to be a more sane implementation |
| 15:44 | jnettlet | topi`, we are working on getting a bunch of optimized chromium builds. It may make sense for us to include libcef to that |
| 15:49 | topi` | ok |
| 22:09 | rabeeh | all : please notice thermal patches from jnettlet - https://github.com/SolidRun/linux-imx6-3.14/commits/linux-linaro-lsk-v3.14-mx6 |
| 22:10 | curlymo | but what is going to bake my eggs now? |
| 22:10 | rabeeh | with them i'm able to run the gpu and the cpus on HummingBoard quad without any heatsink since it is capable of lowering the processor speeds really nice |
| 22:11 | rabeeh | curlmo: i'm sorry to tell that you need to get another platform now to bake the eggs :) |
| 22:11 | curlymo | doesn't this sort of implement CPU/GPU governers? |
| 22:11 | rabeeh | it can still can bake eggs; but you really need to punish it now |
| 22:11 | rabeeh | yes; those patches hooks the thermal sensor on decisions on what to do with the cpu/gpu freq |
| 22:12 | rabeeh | we notice that in some applications only playing with the cpu freq while keeping the gpu freq as-is will give almost same user experience (xbmc for example) |
| 22:12 | rabeeh | this is mostly since the processor are running on idle, but the clock and the pll is running in full speed |
| 22:13 | curlymo | i'm asking because i once forced the RPi CPU governor to performance in XBian because the governor switch time created a noticeable lagg |
| 22:15 | rabeeh | it doesn't on imx6 |
| 22:16 | rabeeh | the switchover is almost instant since they have glitchless muxes |
| 22:16 | curlymo | what's the FREQ switch time? |
| 22:16 | rabeeh | i think it's almost instant |
| 22:16 | rabeeh | jnettlet can confirm this |
| 22:16 | curlymo | the arm had i think about 100x higher once then a modern intel |
| 22:16 | curlymo | ones |
| 22:20 | rabeeh | curlymo: it depends on the SoC integration; ARM processors doesn't care when and how it gets it's clock |
| 22:21 | rabeeh | it depends on the pll generation and it's divisor afterwards |