| 05:56 | _dab_ | jnettlet: ping |
| 06:01 | _dab_ | jnettlet: 3.10 is great work. Installed with debian, xfce4. I like it. Yep, there are things that need further work, but the base graphics works really well for me |
| 06:11 | jnettlet | _dab_, thanks. I have a queue of patches I am going to try and get out today. Hopefully fix a lot of bugs. |
| 06:12 | jnettlet | I am also going to try and get direct linux booting out if possible. |
| 06:16 | _dab_ | BTW using i4pro |
| 06:20 | _dab_ | what impressed me; debootstrap minimal debian; apt-get install x-window-system-core xfce4; startx |
| 06:20 | jnettlet | _dab_, sure. Well I am testing on both the high-end and low-end |
| 06:21 | _dab_ | and it worked first shot |
| 06:21 | jnettlet | Is that using the GPU acceleration, or just the framebuffer driver? |
| 06:21 | _dab_ | how do I tell? |
| 06:22 | jnettlet | look at /var/log/Xorg.log |
| 06:22 | jnettlet | Xorg.0.log |
| 06:23 | _dab_ | fbdev |
| 06:28 | jnettlet | which Xorg version is it running? It should be right at the top of the log. |
| 06:29 | _dab_ | 1.15.0 |
| 06:39 | jnettlet | yeah, that is the problem right now. The vivante binary drivers only work with Xorg up to 1.14.3, until they release an updated version. |
| 06:42 | _dab_ | are you putting patches to linux4kix or solidrun git? |
| 06:59 | jnettlet | my patches will go to linux4kix and then I will send a merge request to SolidRun |
| 11:39 | ralix | morning |
| 11:39 | mal-- | hi |
| 12:45 | dtroy | Hi does anyone know if would be possible to get locked bootloader (+unrooted) android on the i-cubox ? I am just not sure how that would work as the OS is loaded from the micro SD ?! |
| 12:52 | rabeeh | dtroy: look at the forums about this. |
| 12:53 | rabeeh | imx.solid-run.com/forums |
| 12:53 | dtroy | I have |
| 12:53 | dtroy | There's not much there |
| 12:55 | rabeeh | http://imx.solid-run.com/forums/viewtopic.php?f=6&t=407&sid=e236ad03836aa4c5ad15253206adbb03 |
| 12:57 | dtroy | Those are instructions to install superSU. I've seen it. So I assume by default the bootloader is not locked to allow you to do that. |
| 12:57 | dtroy | But is there a way to ship cubox devices to customers with a locked bootloader ? |
| 13:27 | tomlohave | rabeeh: ping |
| 13:27 | rabeeh | tomlohave: here |
| 18:40 | rik- | I had a question about xbmc decode performance. On an RPi, for example, if you have hardware support for the codec, it works ok, but without hardware support the CPU doesn't have enough umph to decode well. How does one of the high-end CuBox's compare? |
| 18:40 | rabeeh | rik-: i don't think that someone has really benchmarked that; but the hardware itself is superior |
| 18:40 | rabeeh | for instance cortex-a9 1GHz with neon support vs. arm11 processor |
| 18:41 | rabeeh | and with ffmpeg multi threaded support then the decode can be spread on multiple processors (up to 4 in the case of the i4pro) |
| 18:41 | mk01 | rik-: I was trying but found only video file where XBMC used ffmpeg to decode |
| 18:42 | rabeeh | in my past experience every processor added adds 60-70% more performance on the decode side |
| 18:42 | rabeeh | mk01: hi :) |
| 18:42 | mk01 | rabeeh |
| 18:42 | mk01 | nice weekend again, huh ? |
| 18:42 | rabeeh | i see that you had a busy one :) |
| 18:43 | rik- | based on an older laptop without any GPU help, 1GHz intel chips have trouble at 720p. I don't know enough about arm to compare clock rates. however, better mutlithreading on the software side, it feels like its near to the edge (or beyond, but not way beyond). |
| 18:43 | mk01 | rabeeh: you know, the ugly things happen now and then. ;) |
| 18:44 | mk01 | rabeeh: I was promising around that I stop yesterday in the morning |
| 18:44 | rik- | thanks for your feedback, I'll get the 4core version and do some testing. |
| 18:45 | mk01 | rik: I didn't finish the info |
| 18:45 | rik- | oh, keep going :) |
| 18:45 | mk01 | rik: so the one video was full hd (1920x1080) fw decoded |
| 18:45 | mk01 | on 4cpu cubox |
| 18:46 | rik- | how was that? any tearing? |
| 18:46 | mk01 | clearly AA was turned off |
| 18:46 | mk01 | but the video played |
| 18:47 | mk01 | I woud call the experience as something you would expect from sw decode |
| 18:48 | rabeeh | mk01: in software decoding there are three parts - decode, color space convert and buffer copy |
| 18:48 | mk01 | and still there were free cpu cycles to use as you could browse xbmc menu etc |
| 18:49 | rabeeh | you could only unleash the max performance in the case when color conversion is done by hardware and the code tweaked not to need buffer copy |
| 18:50 | rabeeh | only those two operations can consume huge amount of data between the processors and the memory (each operation works on 1920x1080 matrixes) |
| 18:50 | mk01 | rabeeh: to be honest I'm not specialist in that are nor have teoretical background. but understand the three steps :)) |
| 18:50 | rik- | did you happen to try something in 720p? |
| 18:50 | mk01 | not have much videos of this kind, not really |
| 18:51 | mk01 | on Gotham there is possibility to force SW decode & run it as threaded proccesses |
| 18:52 | mk01 | can try if you want. I assume it to be actually the case when there is no match on codec id for hw decoding |
| 18:54 | rabeeh | mk01: on the latest xbian builds with the 3.10.30 LK; which defconfig are you using? |
| 18:55 | mk01 | but using RPIs for past year and now using cubox 4pro. ... there is not much to compare as the RPI CPU is really there just to provide control over the system. it can really do any real work |
| 18:55 | jnettlet | xbian is using 3.10.30? |
| 18:55 | rabeeh | jnettlet: mk01 had a long weekend :) |
| 18:55 | mk01 | jnettlet: yes |
| 18:56 | jnettlet | rabeeh, ah. Well I am trying to get another slew of patches landed tonight |
| 18:56 | mk01 | promised on last weekend but had to leave for business trip for week |
| 18:56 | rabeeh | jnettlet: great. please send me pull request once you have anything :) |
| 18:57 | rabeeh | mk01: did you fix anything with regards the CEC stuff? |
| 18:57 | jnettlet | including fastboot based on u-boot...I got started on integrating with barebox but that will have to wait just a bit longer. |
| 18:57 | mk01 | rabeeh |
| 18:57 | mk01 | yes |
| 18:57 | mk01 | I restored CEC back to work |
| 18:57 | jnettlet | I am calling it fastboot instead of falcon because there is no chance of it going upstream. |
| 18:58 | jnettlet | mk01, with rmk's driver? |
| 18:58 | mk01 | jnettlet |
| 18:58 | mk01 | nope. |
| 18:58 | mk01 | jnettlet: with IMX and IMX-HDMI |
| 18:58 | jnettlet | mk01, did you have to patch libCEC? |
| 18:59 | mk01 | jnettlet: I was still waiting for the updates as you tald me that rmk is rethinking the concept |
| 18:59 | jnettlet | well libCEC needs work. |
| 18:59 | mk01 | jnettlet: wanted to avoid further libCEC patching so not really. only ONE fix on top of initial IMX support |
| 19:00 | jnettlet | is it in git? |
| 19:00 | mk01 | jnettlet: asked you three times lately how to provide it :) apparently asked overnights with nobody online |
| 19:01 | mk01 | I don't have forks of your kernel or libcec |
| 19:01 | mk01 | only clones |
| 19:01 | mk01 | so can provide diffs |
| 19:01 | mk01 | git diffs |
| 19:02 | jnettlet | mk01, oh you patched the kernel driver as well? |
| 19:02 | mk01 | or can really fork them both to xbianonpi and commit to them |
| 19:02 | mk01 | then it would be git |
| 19:02 | jnettlet | up to you. If you just want to give me patches I can commit them under your info. |
| 19:03 | rabeeh | jnettlet: mk01 maintains debian packages of everything (including the kernel, gpu drivers etc...) |
| 19:03 | mk01 | jnettlet: two files are changed, mxc_ipuv3_fb.c and imx-hdmi-cec.c |
| 19:03 | rabeeh | i can already see duplicate work here since few debian developers approached me for debian upstreaming |
| 19:04 | rabeeh | i need to get back to them and connect all the working forces together to avoid duplication |
| 19:04 | mk01 | rabeeh: you should. |
| 19:05 | rabeeh | Matus Kral: is the black cat on your github avator yours? |
| 19:05 | jnettlet | rabeeh, dv_ and I were talking about actually starting an MX6 github community to expose all the various projects. Then the different vendors/distros can fork or cherry-pick work from there. |
| 19:06 | mk01 | rabeeh: I was asking this as btw in email a while back... not to expect it to happen anytime soon but at least have some idea |
| 19:06 | mk01 | rabeeh: yes |
| 19:06 | mk01 | rabeeh: yes -> cat. actually are two. siblings. |
| 19:06 | rabeeh | jnettlet: IMHO wiki page would be more useful |
| 19:07 | rabeeh | you can easily get lost in github |
| 19:07 | jnettlet | rabeeh, well really we wanted a place that we could track bugs |
| 19:13 | rabeeh | mk01: what do you think about LK 3.10.30 vs. 3.0.35? |
| 19:13 | mk01 | :)) each of you having different perspective to the running process so I will provide third one :) - the git is still too far away from user. wanting ready system to start and having all the work from development being translated to updates -> package updates. at the end this is somehow accessible to them by people having build systems and sharing the stuff but having apt-repo as supplement to upstream would be a dealbreaker |
| 19:14 | mk01 | rabeeh: you know what ? during the past weeks I got quite used to the 3.0.35 |
| 19:16 | mk01 | but the problem is ther that you made the default setup quite polished and running with confidence. really. but any change in module setup for instance was very often breaking the build tree. |
| 19:17 | rabeeh | mk01: but after seeing the performance boost on the graphics side there is no way back |
| 19:18 | rabeeh | i'm not sure if you have noticed that or not; but lots of things that were lagging on the previous kernel are now simply fluid |
| 19:19 | mk01 | now with 3.10.30 I have back BTRFS - I'm like drug addict to the concept of CoW FS with separate volumes. |
| 19:19 | rabeeh | for the default config i think we need to address that; and it can be either - |
| 19:19 | rabeeh | 1. beef up imx_v7_cubox-i_hummingboard_defconfig to provide desktop like modules (i.e. all the usb drivers etc...) |
| 19:20 | rabeeh | 2. clone imx_v7_cubox-i_hummingboard_defconfig and create imx_v7_cubox-i_hummingboard_desktop_defconfig |
| 19:21 | mk01 | rabeeh: to the fluidity - not that I realized specially gfx boosts, but yes, the 3.10 is a way ahead with many conepts completely rewritten if I remember the history |
| 19:22 | rabeeh | mk01: maybe you don't see that a lot in Xbian since you are running a trimmed down menu |
| 19:22 | jnettlet | oh rabeeh I forgot to tell you. We are very close to having a 5 second power to xbmc screen |
| 19:22 | rabeeh | if you look at the default xbmc menu then the zoom in/out are simply fluid with the new kernel (even with the rss is running) |
| 19:22 | rabeeh | jnettlet: god damn it |
| 19:22 | rabeeh | when; who? |
| 19:23 | rabeeh | openbricks? |
| 19:23 | jnettlet | on geexbox but I still need to land some stuff. |
| 19:23 | jnettlet | yeah. 300ms u-boot about 1-1.5 kernel and around 3 for userspace |
| 19:23 | rabeeh | oh; from 40 seconds to 5 seconds.. simply WOW |
| 19:24 | rabeeh | how much is it micro SD dependent? |
| 19:24 | jnettlet | still need to test that |
| 19:24 | rabeeh | falcon mode? |
| 19:25 | jnettlet | I am calling it fastboot mode, as I really didn't use falcon mode at all. I more hacked on SPL |
| 19:25 | rabeeh | do you run u-boot.img? or SPL --> kernel? |
| 19:25 | jnettlet | it started with me just wanting to figure out what needed to be done for barebox |
| 19:25 | jnettlet | SPL -> kernel |
| 19:25 | rabeeh | is that SPL --> kernel or SPL --> kernel + dtb? |
| 19:26 | jnettlet | SPL -> kernel with dynamic dtb loaded separately |
| 19:26 | rabeeh | so potentially a single image to support CBi + HB autodetect is still doable |
| 19:26 | jnettlet | although I need to fix the memory substitution in the device-tree |
| 19:26 | mk01 | jnettlet: nice topic - rabeeh made me aware of falcon but I had no time to implement. but what is the different approach ? |
| 19:27 | jnettlet | it is like falcon mode, but falcon mode sucks and I have u-boot hate. So I just hacked up all the broken stuff. |
| 19:27 | mk01 | XBian is currently using boot script with direct load of kernel & ramfs & dtb file + bootz with bootdelay=1 |
| 19:27 | jnettlet | rabeeh, I also found out the SPL mode is broken and is running MMC at the slowest clock speed possible |
| 19:28 | rabee | 19:28 * rabeeh is not surprised |
| 19:28 | rabeeh | jnettlet: so a busy weekend :) |
| 19:29 | jnettlet | I implemented it and the kernel was taking 4 seconds to load. Fixed it up...bam 300ms |
| 19:29 | jnettlet | and that is just standard SD speed of 20mhz |
| 19:30 | tomlohave | jnettlet: you are doing an awesome job :p |
| 19:30 | tomlohave | Congrats |
| 19:31 | mk01 | jnettlet: did you commit to git or not public yet? |
| 19:31 | tomlohave | rabeeh: does wifi is different on i2 compared to i4 ? |
| 19:31 | jnettlet | mk01, uboot work is not public yet. I still need to fix a few things I have hacked in there. |
| 19:31 | rabeeh | tomlohave i2 or i2w? |
| 19:31 | rabeeh | i2 has no wifi |
| 19:32 | rabeeh | CBi has 6 versions - i1,i1w,i2,i2w,i2u and i4pro :) |
| 19:32 | tomlohave | i2w, maybe :-) |
| 19:32 | rabeeh | it says on the bottom of the CuBox-i |
| 19:32 | mk01 | jnettlet one question - 3.0.35 was not blanking the display on reboot so with reboot u-boot was visible as expected. 3.10.30 blanks display somwhere before issuing reboot and display stays blank until kernel again initializes fb driver |
| 19:32 | jnettlet | tomlohave, you missed it, but mk01 says he has CEC working |
| 19:32 | rabeeh | the wifi function is on SD1 interface and is auto detected |
| 19:33 | tomlohave | I saw it ;-) |
| 19:33 | tomlohave | waiting to see that |
| 19:33 | tomlohave | rabeeh : brcmfmac4330-sdio.txt is requested on i2w |
| 19:33 | jnettlet | mk01, that sounds like something isn't getting reset properly. My display shows u-boot on reboot. |
| 19:34 | jnettlet | mk01, any chance on reboot you can git esc and check to see the timing your monitor thinks it is doing? |
| 19:34 | rabeeh | there are two wireless chips supported in CuBox-i - bcm4329 and bcm4330 |
| 19:34 | tomlohave | a symlink to brcmfmac4329-sdio.txt doesn't work |
| 19:34 | rabeeh | the bcm driver automatically detects the correct chip and loads the firmware and the nvram |
| 19:34 | tomlohave | maybe a plain file ... |
| 19:35 | tomlohave | difficult to test without hardware :p |
| 19:35 | mk01 | jnettlet: actually the screen blanks and them get out of sync completely as during u-boot checking the usb (what I seen on hub leds & hdds) it goes to "mode not supported" |
| 19:35 | rabeeh | brcmfmac4330-sdio.txt and brcmfmac4329-sdio.txt are totally different files |
| 19:36 | mk01 | of course it loads kernel and cca at 2s it initializes hdmi properly with FB driver load |
| 19:36 | tomlohave | rabeeh good to know, and where can you find it ? |
| 19:36 | rabeeh | tomlohave: https://github.com/SolidRun/linux-imx6/tree/imx_3.0.35_4.1.0/firmware/brcm |
| 19:36 | jnettlet | mk01, that doesn't surprise me. The clocks in u-boot are kind of screwy. But with the new boot process you don't even have time to worry about it. |
| 19:36 | tomlohave | thanks |
| 19:37 | rik- | I ordered a CuBox |
| 19:37 | rik- | we'll see how it runs xbmc |
| 19:37 | mk01 | jnettlet: hah ! :) |
| 19:38 | rik- | now I need a multi-spindle enclosure with estata |
| 19:39 | rabeeh | tomlohave: objcopy -I ihex -O binary bcm4330_nvram.txt.ihex bcm4330_nvram.txt |
| 19:39 | rabeeh | the files are stored in ihex format since they are part of the kernel; the above command converts those files to what the drive would expect |
| 19:40 | mk01 | to the CEC topic. the problem is with fb driver doing full re-setup (clocks, irqs etc) on almost each action relevant to mode check / change anything. what means it mess the shared irq without considering running cec in paralell. |
| 19:43 | mk01 | I;m definitely not a kernel programmer nor have the knowledge so sorry for the terminology. so what I did with the patch is that on HDMI reinit I send stop to cec and start after clocks & irqs are back configured by hdmi fb driver |
| 19:44 | rabeeh | mk01: what happens when powering on / off the tv? or switching to different hdmi input? |
| 19:44 | rabeeh | are all of those issues gone with this hack? |
| 19:44 | mk01 | holding as expected |
| 19:45 | mk01 | as I do not leave cec off for all the time when HDMI is down. cec can deal with it. the only problem are the "transitions" |
| 19:45 | jnettlet | mk01, ah...okay I already have a patch cleaning up the irq handling in the fbdev driver sitting for me to look at. |
| 19:46 | mk01 | jnettlet: so probably it will be conflicting. ... anyhow will generate the diffs as it was also needed to rebase Wolfgars 3.0.35 cec patch to 3.10.30 |
| 19:46 | jnettlet | mk01, send them my way. thanks |
| 19:47 | mk01 | and the port & physical address for CEC was read from wrong edid registers. this is fixed too |
| 19:47 | mk01 | so CEC properly detects its connect paths. |
| 19:49 | mk01 | and the last really small patch was to libCEC and IMX support which is really the bare minimum to support IMX cec so I fixed POLLing to bus to non existent LogicalAddresses which by docs should not throw an error but if transmit is not acked and message was a poll not error should be generated. otherwise CEC was conflicting on choosing LA if more devices were attached on the bus |
| 19:50 | mk01 | will send the generated files to you and rabeeh |
| 19:59 | mk01 | rabeeh: are you still online ? |
| 20:00 | xraxor | mk01 whenever you say about u-boot trowing tv to "not supported mode" it happens on my Sony TV, but my LG shows the SolidRun logo and all |
| 20:00 | mk01 | xraxor: but initial boot after poweroff / on is ok , right ? |
| 20:01 | xraxor | i never seen SolidRun logo from u-boot on my sony tv |
| 20:01 | rabeeh | mk01: yes |
| 20:02 | mk01 | ah then it's a bit different. as I see poweron cycle logo ok. it goes off only after soft cycle via reboot |
| 20:02 | xraxor | never, thats why the screen was just black when we were doing tests, i could not see it , on lg is fine |
| 20:02 | xraxor | ok, so might be just my tv then |
| 20:02 | rabeeh | xraxor: probably your TV |
| 20:03 | rabeeh | but CuBox-i u-boot fault |
| 20:03 | rabeeh | if you are using CuBox-i4pro then the hdmi refresh is set to 72hz; which almost on TV supports |
| 20:03 | rabeeh | 1024x768@72hz |
| 20:03 | xraxor | no probs, CEC is working great, and on problem im having is screen goes black for like a sec during playback, not always but somettimes |
| 20:03 | mk01 | rabeeh you asked if all those issues are gone with this hack. answer is the point is solved. there are still cases during video decoding (on those files / codecs / conditions which are causing the known overrun / underrun / device not responding errors). if this happens, this triggers two cases. |
| 20:04 | xraxor | that might be it rabeeh, as my Sony tv is 60hz and my LG is 100hz. thanks |
| 20:04 | mk01 | rabeeh one is simple reinit as already told -> cec may or may not survive actual connection, if it doesn't survive it gets reinitialized upon choosing the same CEC device again from TV menu |
| 20:06 | rabeeh | mk01: i'm not familiar with overrun/underrun issues on i4pro |
| 20:06 | rabeeh | we used to have those on LK 3.0.35 until the IPU to DDR TOS was set correctly |
| 20:06 | rabeeh | mk01: do you have one running right now on your setup? can you run devmem? |
| 20:06 | rabeeh | devmem 0x020e0018 |
| 20:06 | rabeeh | (as root) |
| 20:06 | mk01 | rabeeh: but sometimes if the playing fails on most fatal device not responding (IVU unit), the cec gets lock released on race condition doing poll & read on empty buffer with no signals - simply means the cec device is busy and never gets released with owning process in loop |
| 20:08 | mk01 | ok, maybe wasn't fully correct. wait, will check the xbmc log |
| 20:15 | mk01 | 20:13:42 T:1323299840 ERROR: GetPicture - player is ahead of time (6555.989728) |
| 20:15 | mk01 | 20:13:42 T:1323299840 NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 3 |
| 20:15 | mk01 | 20:13:42 T:1323299840 NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 4 |
| 20:15 | mk01 | 20:13:42 T:1323299840 ERROR: GetPicture - player is ahead of time (95.629728) |
| 20:15 | mk01 | 20:13:42 T:1323299840 NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 8 |
| 20:15 | mk01 | 20:13:42 T:1323299840 NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 1 |
| 20:15 | mk01 | 20:13:42 T:1323299840 NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 5 |
| 20:15 | mk01 | 20:13:42 T:1323299840 NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 8 |
| 20:16 | mk01 | if this combines with random audio hdmi reporting wanting data but none awailable as HW buffer missing |
| 20:16 | mk01 | the screen is resyncing what can lead to the CEC race condition |
| 20:17 | rabeeh | mk01: can this be reliable reproduced? |
| 20:17 | mk01 | YES |
| 20:17 | rabeeh | which content is that? please PM link if you have |
| 20:17 | rabeeh | what about kernel messages? |
| 20:18 | mk01 | it is live TV from TVheadend source DVBT mpeg2 |
| 20:18 | mk01 | none kernel messages even on loglevel = 8 |
| 20:18 | mk01 | there were kernel errors on 3.0.35 but none on 3.10 |
| 20:19 | mk01 | rabeeh: I can record the stream & share to you. the recorder TS is doing exactly the same |
| 20:20 | rabeeh | which bitrate is this? |
| 20:20 | rabeeh | HD or SD? |
| 20:20 | mk01 | SD |
| 20:20 | rabeeh | btw - is it using the newer deinterlacing scheme? |
| 20:21 | rabeeh | or the TV is doing the deinterlacing? |
| 20:21 | mk01 | I have deinterlacing set to off in XBMC |
| 20:22 | mk01 | if you give me 5 minutes I was just recompiling XBMC with debug outputs from deoderIMX exactly on MEDIA INFOs |
| 20:24 | mk01 | rabeeh: I will send the diffs to your email as jnetlet is not responding and I have no contact to him. so forward upon receiving please to him |
| 20:25 | rabeeh | mk01: np. thanks |
| 20:31 | mk01 | rabeeh: just sent |
| 20:35 | _dab_ | re boot timings; with a trimmed down uboot, 3.10.30 (diff config) and minimal debian |
| 20:35 | _dab_ | I get a 3second boot, 1.5 to debian |
| 20:38 | _dab_ | no gui |
| 20:43 | jnettlet | sure, but with probably nothing running. |
| 20:45 | _dab_ | of course, but I call that pretty quick! with your uboot change, it sounds more like very quick |
| 21:15 | dv_ | rabeeh, dv_ and I were talking about actually starting an MX6 github community to expose all the various projects. Then the different vendors/distros can fork or cherry-pick work from there. <- the guys over at #imx6-dev might also be interested in this |
| 23:21 | rabeeh | dv_: lets join forces then for imx6-dev |
| 23:21 | dv_ | rabeeh: I already sent a mail to github, asking if it would somehow be possible to "link" existing repos to a common imx6 development space |
| 23:21 | rabeeh | do you have an example github repo that demonstrates what you have in mind? |
| 23:22 | dv_ | jnettlet considered forking, but I am not a fan of that. forking means updates will not carry over |
| 23:22 | dv_ | there seem to be several xbmc-imx repos for example |
| 23:23 | mk01 | dv_ : normally it is possible if you move ownership to a group / "company" |
| 23:23 | dv_ | also, jnettlet's kernel, rmk's kernel and xorg driver efforts, etnaviv, .. |
| 23:23 | mk01 | but I assume we don't want to change ownership ? |
| 23:23 | dv_ | mk01: that would be problematic to me, since I moved gstreamer-imx to Freescale already |
| 23:23 | dv_ | and I guess the other projects would hesitate to move |
| 23:27 | rabeeh | dv_: projects like whom? |
| 23:27 | rabeeh | etnaviv? |
| 23:27 | dv_ | yeah, or the xbmc ones |
| 23:27 | rabeeh | i guess you are right then |
| 23:27 | dv_ | I mean, jnettlet is right, it is too fragmented. but forking is not the way in my opinion |
| 23:28 | rabeeh | on the other hand i'm sure the different product support is duplicating work again and again |
| 23:28 | dv_ | hopefully, sort of "symlinks" are possible after all. I'm curious what the github admins will say |
| 23:29 | dv_ | yes, but it would get worse with forking. nobody would be certain where to continue development then, because in some cases, keeping both forks up to date would be necessary |
| 23:29 | dv_ | for example, my gstreamer-imx stuff is on the Freescale account to make it visible to people who want 1.0 plugins |
| 23:30 | mk01 | was it needed to move it from you to fsc ? |
| 23:30 | dv_ | so for example somebody wants to issue a pull request. where should it go? |
| 23:30 | dv_ | mk01: it was beneficial |
| 23:31 | dv_ | it made integration into meta-fsl-arm easier too |
| 23:31 | mk01 | we on XBian having cca 25 repos in total do for packages which are |
| 23:31 | mk01 | "authored" or originaly developed outside XBian tree |
| 23:31 | mk01 | we keep the original with author |
| 23:32 | mk01 | do a fork |
| 23:32 | mk01 | and define a team with the original author full rw access to the XBian fork |
| 23:32 | dv_ | well the ideal solution would be to have one common imx6 devel page, where new projects can be added, or existing ones can be kind of symlinked |
| 23:32 | mk01 | so it get's geveloped directly under one common company |
| 23:33 | rabeeh | mk01: but in your case it's easier since all your patches are in Debian/patches directory; so cherry pick is somehow much more easier than digging inside a git tree |
| 23:33 | mk01 | with direct access for original authors |
| 23:33 | mk01 | but still is clear ownership |
| 23:33 | mk01 | etc |
| 23:33 | mk01 | e-e |
| 23:33 | mk01 | the xbian-patches repo is out of use |
| 23:33 | mk01 | should be decomissioned |
| 23:34 | mk01 | commits are going to specific repos |
| 23:34 | mk01 | (meaning packages) |
| 23:34 | dv_ | but in this system, the author must now push to two repos |
| 23:34 | dv_ | what if he forgets? |
| 23:34 | mk01 | no |
| 23:34 | mk01 | he pushes to the fork under XBian |
| 23:34 | dv_ | and what about his original repo? |
| 23:34 | mk01 | then just merges to own |
| 23:35 | mk01 | this can happen automatically |
| 23:35 | dv_ | automatic merge would solve the stale repo problem, but not the other one - where should people send pull requests etc. to? |
| 23:35 | mk01 | of course for sure not best solution, but we somehow found this as most transparent / accessible to user and still controllable by author |
| 23:36 | dv_ | I foresee that 50% of users issue requests to the original repo, and 50% to the fork. not good. |
| 23:36 | mk01 | we expect always follow the XBian tree so to xbianonpi/repo |
| 23:36 | mk01 | regardless if it is original or fork |
| 23:37 | dv_ | I am already confused by the various meta-fsl-arm versions (one in github, another in yoctoproject.org etc.) for example |
| 23:37 | mk01 | yes, it happens sometimes |
| 23:37 | dv_ | hm. perhaps it is the only way. still, I want to be sure. |
| 23:38 | mk01 | biggest impact there is that sometimes you don't follow (or some authors) don't follow notifications on own origin repos, because focus on XBian tree |
| 23:38 | mk01 | sometimes requests/issues are then missed for days / weeks |
| 23:38 | dv_ | there is another slight difference: the focus is not the same. xbian stuff is focused on rootfs building and deployment. |
| 23:39 | dv_ | the original repos on development |
| 23:39 | dv_ | but in an imx6 devel space , both the original and the fork would be focused on development |
| 23:40 | mk01 | to be honest, original approach was the same |
| 23:40 | mk01 | but when it started to grow |
| 23:40 | mk01 | with many individuals with completely different skills towards building installing sharing etc |
| 23:41 | mk01 | it was quite mess to even keep one discussion in sync |
| 23:41 | mk01 | as everybody has own approach to apply the provided develpment/code |
| 23:42 | mk01 | it was so crazy that simply on one day I took all the code hosten under repo, created common "build" system and redistributed the results as it is now |
| 23:44 | mk01 | as we solved one issue now the problem is that the development itself looks like being lost |
| 23:45 | dv_ | hmm |
| 23:47 | mk01 | and the perception goes (as your own) towards built root - although I strictly fight back if I hear it. |
| 23:48 | mk01 | but back to the topic IMX |
| 23:49 | mk01 | I know we speak and define here the development level of IMX problematics |
| 23:51 | mk01 | but it would be very appreciated by users to have the binary forms provided by entity able to handle the automation / storage / distro focus |
| 23:52 | dv_ | for me, the most important thing is to be aware of all the projects |
| 23:52 | mk01 | yup, it has to start somewhere |
| 23:52 | dv_ | this is the number one problem with the current fragmentation. you might be reinventing the wheel without knowing it. |
| 23:52 | rik-- | mk01: do you have a recommendation for a 4- or 5-bay esata-attached enclosure to work with the cubox? I'm hoping it has the multiplier necessary to talk with more than one drive. |
| 23:54 | mk01 | rik--: nope, I don't have cause my requirement is at 2.5" size with the 4-5 bays and I found this not on market. then I was hoping for at least double 2.5bays - stackable . not existing either |
| 23:55 | rik-- | yeah, there's a sparcity of 2.5 bays outside the rackmount market |
| 23:55 | mk01 | but 3.5 should be quite wide portfolio there. I know rabeeh has some models in list there is even thread on forum with specific models be recommended or under direct test by user |
| 23:56 | rik-- | I have time to do research... a few weeks before the cubox comes. y'all have pre-production dev. versions? |
| 23:57 | mk01 | so currently my rootfs is on 2x500gb dissks in raid0 in HUB .. but having other 3 500gb wasted in trunk |
| 23:57 | mk01 | :-/ |
| 23:58 | mk01 | nope, I have std model |
| 23:58 | mk01 | from the first "wave" |