| 03:09 | DHowett | the cubox (orig) is hf, right? |
| 03:10 | DHowett | hm, yes. it appears that dove is |
| 03:58 | ojn | DHowett: yeah it lacks NEON though |
| 03:58 | ojn | well, I'm not sure what you mean with "is hf", but it has the vfp needed for running armhf |
| 04:06 | DHowett | ojn: that'd be it (thanks!) |
| 10:12 | jnettlet | rabeeh, apparently GeeXboX has done some optimizations for the iMX6 http://www.youtube.com/watch?v=Enr-NtYYcMI |
| 10:48 | _rmk_ | hmm, apparantly, pengutronix say that the IC can only deal with 1024x1024, so that's not going to be useful for 1080p overlays |
| 10:48 | _rmk_ | nor even 720p overlays |
| 10:48 | _rmk_ | freescale fail. |
| 10:55 | bencoh | meh |
| 10:57 | jnettlet | _rmk_, yeah the fsl driver tiles the screen to handle larger imaages. |
| 10:59 | jnettlet | I guess they actually call it split not tile. |
| 10:59 | _rmk_ | well, I think I'm going to leave that to others to fix. |
| 12:55 | dv_ | jnettlet: that would mean copying pixel data into up to 4 tiles |
| 12:55 | dv_ | jnettlet: does not sound efficient. although the IPU can copy to two destinations at the same time I think. |
| 12:55 | dv_ | but then I might as well just use regular, non-overlay output |
| 12:56 | jnettlet | why 4 tiles? |
| 12:56 | dv_ | for 1920x1080 for example |
| 12:56 | _rmk_ | 1080p is 1920x1080, which is larger than 1024x1024 in both X and Y directions |
| 12:56 | jnettlet | right duh |
| 12:56 | _rmk_ | :) |
| 12:56 | dv_ | perhaps freescale intended to use overlays only for stuff like OSD etc. |
| 12:58 | jnettlet | is the 1024x1024 source or destination size? |
| 12:58 | dv_ | the VPU, IPU, and GPU can output 1080p smoothly without them. and if you use compositing, what is the remaining advantage of overlays? |
| 13:00 | dv_ | true zerocopy is only possible with them, but as said, performance doesnt seem to be a problem |
| 13:01 | _rmk_ | flipping the displayed buffer on display refresh, so you don't get updates mid-scanout of the buffer |
| 13:02 | dv_ | this can be achieved with the GPU though. its one central point of wayland. |
| 13:02 | _rmk_ | only if you know where the CRTC is reading from, and I don't think we do, either on Dove nor on MX6 |
| 13:02 | dv_ | but ok, the GPU eats more power.. |
| 13:02 | dv_ | hmm |
| 13:03 | dv_ | depends on what the eglswapbuffers function does |
| 13:05 | jnettlet | with a shadowbuffer you can draw offscreen and just use the GPU to blit the fullscreen when vblank occurs. |
| 13:06 | jnettlet | the 2D core clocked all the way down should be able to easily handle that. |
| 13:06 | dv_ | yeah. and we are back to the old problem again of using the vivante 2d api from userspace. :) |
| 13:07 | jnettlet | I don't think there is anything stopping us from doing it within the kernel. |
| 13:07 | dv_ | ah, no. forgot that this is about drm planes. |
| 13:09 | _rmk_ | I think we need drm to export some capabilities about these planes |
| 13:10 | dv_ | and how would these planes be filled? |
| 13:10 | _rmk_ | and I think this is not going to make airlied happy... esp when he finds out its imx-drm. |
| 13:11 | _rmk_ | or... I think we just stop supporting drm planes with imx-drm. |
| 13:12 | jnettlet | or we update the drm ipuv3 code so it has the same functionality as the freescale standalone ipu3 driver |
| 13:12 | jnettlet | or we use the freescale ipu3 driver and adapt the drm driver to use that. |
| 13:13 | jnettle | 13:13 * jnettlet is really tired of chasing codebases |
| 13:13 | _rmk_ | and I'm getting quite tired of chasing masses of iMX problems |
| 13:14 | jnettlet | which reminds I still need to chase down why the cpu_idle code causes IO lag |
| 13:15 | dv_ | no wonder, you guys have been intensely working on this |
| 13:16 | jnettlet | chasing the dragon |
| 13:16 | _rmk_ | I have three dragons here... they're all well behaved though. :) |
| 13:17 | dv_ | jnettlet: btw any news on the memory allocation? |
| 13:17 | dv_ | err, I mean, on the 3.10 kernel? should I switch the kernel used in the meta-fsl-arm-extra fork from 3.0.35 to 3.10 now? |
| 13:18 | jnettlet | dv_, oh yeah. I have re-merged all of _rmk_'s newest work to the 3.10 fsl kernel. However there are a couple of driver conflicts I had to sort out. |
| 13:18 | dv_ | https://github.com/linux4kix/linux-imx6/tree/solidrun-imx_3.10.9_1.0.0_alpha <- here ? |
| 13:18 | jnettlet | but other than that everything else should be good to go. I should probably make sure my ION mm patchset doesn't need to be updated. |
| 13:19 | _rmk_ | that's something else I should look at... |
| 13:19 | jnettlet | dv_, that is a problem I have to sort out. |
| 13:19 | _rmk_ | putting ION onto the cubox, and dropping bmm |
| 13:19 | dv_ | jnettlet: okay, I just mean if this is the right repo and branch where you will put the changes |
| 13:19 | jnettlet | other people are now using that branch and _rmk_'s newest patches are a complete rebase |
| 13:20 | dv_ | oh, I see |
| 13:20 | _rmk_ | jnettlet: sorry about that |
| 13:20 | jnettle | 13:20 * jnettlet is contemplating just replacing that branch and making people re-pull it. |
| 13:20 | jnettlet | _rmk_, no worries it is alpha :-) |
| 13:20 | dv_ | jnettlet: go ahead, its an alpha branch anyway |
| 13:20 | _rmk_ | indeed, and it's going to happen again at some point... when the pinmux stuff gets sorted. |
| 13:21 | dv_ | but its git, why not just create a new branch? |
| 13:21 | jnettle | 13:21 * jnettlet doesn't need to be told again |
| 13:21 | _rmk_ | also when I do more work on the component stuff too |
| 13:22 | jnettlet | fair enough. |
| 13:22 | _rmk_ | jnettlet: I'd suggest not worrying about the patch last night for lioka |
| 13:22 | jnettlet | okay |
| 13:22 | _rmk_ | save yourself some work, stick with what you've already got and when I've got it more sorted then see about updating. |
| 13:23 | jnettlet | re-merging your work is not so bad now that I have most drm/cma/etc patches that are needed to be pulled down to support modern drivers sorted out. |
| 14:53 | lioka | 1 |
| 14:55 | jnettlet | 2 |
| 14:55 | _rmk_ | 3 |
| 14:58 | lioka | oops. wrong window. |
| 15:09 | jnettlet | oh. me too. How weird. |
| 15:10 | _rmk_ | good thing mine was intentional then, otherwise we'd all be making the same mistake. |
| 15:53 | _rmk_ | damn it. why does this stuff have to be soo hard. |
| 15:54 | _rmk_ | ion doesn't use dmabuf stuff at all... it's in its own little world. |
| 15:54 | _rmk_ | some of what it does implement is a reimplementation of dmabuf |
| 16:01 | dv_ | why do things simple when you can do them in a complicated way? |
| 16:04 | liok | 16:04 * lioka just realized that CONFIG_I2C_IMX=m leads to edid absense and 1024x768 at max |
| 16:04 | lioka | so yes |
| 16:05 | lioka | we like it hard way |
| 16:11 | _rmk_ | lioka: yes, I don't like that... that's just silly. |
| 16:11 | _rmk_ | lioka: the problem there is compounded when you consider we now have deferred probing... |
| 16:12 | _rmk_ | what happens if the IMX i2c driver defers for some reason, and initialises after DRM... |
| 16:12 | lioka | and some fedora guy at lkml wants imx-drm stuff modularized. naive. |
| 16:12 | _rmk_ | DRM never gets to see the DDC I2C, because imx-hdmi never defers for lack of DDC. |
| 16:13 | _rmk_ | this is one of the big issues I have with deferred probing. It sounds like it solves problems but it doesn't, it instead creates different problems. |
| 16:13 | _rmk_ | there's a big difference between "this resource isn't present and will never be present" and "this resource isn't present yet but will appear later" |
| 16:14 | _rmk_ | in the former case, a driver may decide it can proceed to initialise without the resource. |
| 16:14 | _rmk_ | in the latter case, a driver may decide to itself defer so that it can get the resource (eg, in this case the i2c) |
| 16:14 | _rmk_ | now, as far as imx-drm being modularised, that's getting easier to achieve... I'm not there yet, but with the component.[ch] stuff, it will be possible once that's finished. |
| 16:17 | lioka | _rmk_: yep, i've imagined something like this. what's really weird (from random packaging monkey like me p.o.v) there's no indication of such promlem at all |
| 16:18 | _rmk_ | lioka: the problem with imx-drm is you have to load each of the modules in the right order otherwise things will explode - eg, arrays will be walked off the end... |
| 16:19 | _rmk_ | it probably won't be obvious when that happens though |
| 16:19 | lioka | _rmk_: right now there are six or so circular deps at least |
| 16:20 | _rmk_ | let me just build it modular here and see what happens with my stuff. |
| 16:21 | _rmk_ | given that ubuntu does parallel loading, it won't be nice atm... but at least it shouldn't end up crashing. I'll probably end up with it not initialising. |
| 16:22 | _rmk_ | this may be... fun. |
| 16:29 | _rmk_ | well, depmod passes... |
| 16:30 | _rmk_ | needed a few symbol exports fixed, and the hdmi module to be organised a bit better... but then dw-hdmi-audio and imx-hdmi isn't properly sorted yet. |
| 16:30 | _rmk_ | ... rebooting |
| 16:32 | _rmk_ | lets try that again with a proper license in component.c |
| 16:33 | liok | 16:33 * lioka relocates to home |
| 16:34 | lioka | be back in 2h |
| 16:34 | _rmk_ | that's better. |
| 16:37 | _rmk_ | and ipuv3-plane needs a license too |
| 16:40 | _rmk_ | ooh, I think it worked. |
| 16:41 | jnettlet | _rmk_, there is a patch in the Linaro tree that bridges dma-buf and ion. |
| 16:41 | _rmk_ | and yes, I have picture! |
| 16:42 | jnettlet | excellent! |
| 16:42 | _rmk_ | and what a beautiful picture it is. (well, it would be otherwise I wouldn't have it as a background) :) |
| 16:43 | jnettlet | but the ion vs dmabuf debacle has been going on for almost 2 years now. Both are getting implemented from what I understand with ion being able to import and export to dmabuf |
| 16:45 | jnettlet | the main reason I chose ion was it allowed custom ioctl's which allowed me to pass the physical address that a lot of the userspace drivers needed. |
| 16:46 | jnettlet | and android supports it so it killed 2 birds with one stone |
| 17:40 | jnettlet | _rmk_, did you implement the tiling needed for scaling with the ipu? |
| 17:41 | _rmk_ | I'm not touching the scaling problem atm |
| 17:42 | jnettlet | so just showing 1:1 |
| 17:42 | _rmk_ | well, trying vlc with it, I just get nothing; there's no way for the app to know that it can't be scaled at display time |
| 17:42 | _rmk_ | or I don't think there is... |
| 17:42 | _rmk_ | and the apps don't have code to fix that up anyway |
| 17:44 | jnettlet | _rmk_, in vlc pressing 'o' will force native resolution playback of the video. |
| 17:44 | jnettle | 17:44 * jnettlet hesitates. let me check that. |
| 17:44 | jnettlet | yes 'o' |
| 17:44 | _rmk_ | I _could_ press 'o' or other keys _if_ I had a keyboard on the carrier-1 :) |
| 17:44 | jnettlet | oh you need cli |
| 17:44 | _rmk_ | there's probably an option for it |
| 18:49 | lioka | _rmk_: sooo, few EXPORT_SIMBOL's and MODULE_LICENSE ans that's all ? |
| 18:50 | lioka | s,SI,SY |
| 19:06 | _rmk_ | a few other tweaks as well, want a new patch? |
| 19:06 | lioka | sure |
| 19:06 | _rmk_ | same base url but carrier-1-v3.12-all-20131112.diff |
| 19:07 | lioka | ok |
| 20:34 | rabeeh | svere: got C1? |
| 20:52 | svere | rabeeh: not yet :-( |
| 20:53 | svere | will call dhl tomorrow again to see what the current state is |
| 20:54 | svere | rabeeh: if it continues at this speed i probably get a cubox-i before i see my C1 :-((( |
| 20:55 | _rmk_ | at least rabeeh didn't call it a C4 |
| 20:56 | svere | lol |
| 20:56 | svere | _rmk_: i read in the log about the scaling discussion |
| 20:57 | svere | _rmk_: where did you find that it can only scale up to 1024 by 1024? |
| 20:57 | _rmk_ | that's from a reply I received from pengutronix, but I don't see it in the manual... I haven't looked that hard though |
| 20:59 | svere | yeah i read it up and on page 2802 it says: (beware the spamming) |
| 20:59 | svere | ? Input: from sensor or from system memory |
| 20:59 | svere | ? Frame size: up to 4096x4096 pixels |
| 20:59 | svere | ? Rate: up to 200M pixels/sec (e.g. 5 MP @ 30 fps + 35% blanking intervals) |
| 20:59 | svere | ? Order: rows, progressive. If resizing is not used, interlaced order is also |
| 20:59 | svere | acceptable. |
| 20:59 | svere | ? Pixel format: YUV/RGB, 8 bits/value |
| 20:59 | svere | ? Processing chain: |
| 20:59 | svere | ? Resizing |
| 20:59 | svere | ? Fully flexible resizing ratio Maximal downsizing ratio: 8:1. Subject to this |
| 20:59 | svere | limitation, any N->M resizing can be performed. |
| 20:59 | svere | ? Independent horizontal and vertical resizing ratios. |
| 20:59 | svere | ? Color conversion/correction - linear (multiplicative & additive) programmable, |
| 21:04 | _rmk_ | "The big problem with the IPU is that the IC block can only output up to 1024*1024 directly to the DC block. Anything larger needs to be tiled into multiple runs and go through RAM, which kind of defeats the purpose of an overlay plane." |
| 21:18 | jnettlet | well that would be fine for optimizing playback embedded in a browser. It would just need some GPU assist when bumped to fullscreen |
| 21:20 | _rmk_ | yea, it just means that special drivers are going to be needed which know about that |
| 21:20 | svere | _rmk_: found it on page 471 |
| 21:20 | svere | Image Converter: |
| 21:20 | svere | The frame resolution supported is up to 4096x4096 for input and up to 1024x1024 for |
| 21:20 | svere | output. Wider frames can be processed by the IC by splitting them to vertical stripes. |
| 21:20 | _rmk_ | yea, I see it, and I just chuckled. |
| 21:21 | _rmk_ | what if your image height is larger than 1024 lines... :) |
| 21:21 | svere | :-) |
| 21:21 | _rmk_ | does that mean you have to split it into vertical stripes too? |
| 21:22 | jnettlet | yep a bunch of tiles |
| 21:22 | svere | nobody will ever need more than 640k |
| 21:22 | _rmk_ | the next paragraph is also fun, and really informative. |
| 21:22 | _rmk_ | I think they omitted some numbers there |
| 21:22 | jnettlet | and they will have 4k screens in phones next year. |
| 21:22 | _rmk_ | or maybe they intend for you to fill in your own numbers :) |
| 21:23 | jnettlet | +1 |
| 21:23 | svere | _rmk_: you can put the numbers you need ;-) |
| 21:24 | _rmk_ | yes, either that or "please find a way to use this hardware block and report back when you have some measured bandwidths, thanks." |
| 21:24 | jnettlet | as I continue to preach. you don't need to stream hi-def video to your 4-5" cell phone screen. You are wasting bandwidth! |
| 21:24 | _rmk_ | jnettlet: indeed... you don't need 1080p on your 20" TV either. |
| 21:24 | jnettlet | nope |
| 21:25 | jnettlet | but that is the buzz word so we keep feeding it to the ignorant and they keep demanding it |
| 21:25 | _rmk_ | many TVs smaller than 32", although they accept 1080p, have to downscale it to the panel size which will be smaller than 1080 lines. |
| 21:26 | jnettlet | and you can only see the difference if you have perfect vision and sit < 1 meter from the screen |
| 21:27 | _rmk_ | yea, I'm about 1m from this 32", but the difference between SD and HD broadcasts is quite noticable, but that's mainly because the SD broadcasts are at such a low mpeg2 data rate, you can see a lot of mpeg artifacts |
| 21:28 | _rmk_ | with the cubox feeding it, even with a SD video, it's fine. |
| 21:28 | _rmk_ | again, part of the miseducation of the public |
| 21:29 | jnettle | 21:29 * jnettlet feels 480p at a good bit rate is good up to 10" screens, then 720p up to 32" then 1080p up to a screen I haven't seen in person yet. |
| 21:29 | jnettlet | 4k should be great for cinemas |
| 21:29 | _rmk_ | the last point on HD vs SD, especially when watching films is this: when you're watching a film, are you admiring the detail you can see or are you following the story? |
| 21:31 | _rmk_ | jnettlet: I think some of the producers aren't happy with 4k in cinemas and want more |
| 21:32 | jnettlet | with OLPC we were putting bids together, and one of the "requirements" was needed to playback 1080p video. It didn't matter that the tablet/notebook minimum resolution was 1024x768. |
| 21:32 | _rmk_ | however, for still images, that's a different matter of course |
| 21:32 | jnettlet | of course |
| 21:32 | _rmk_ | there you have time to get lost in the detail of the image |
| 21:33 | jnettlet | and also create smaller images from a single high-res image |
| 22:36 | dv_ | 1080p looks great on my 1920x1200 TFT :) |