| 16:27 | dv_ | rabeeh: in the kernel subdirectory drivers/video/dovefb , there is the nxp_hdmi folder. is this folder hosted somewhere else? it would be better in cases one just wants this folder, and not the rest of the kernel (for example, for libcec) |
| 17:04 | jnettlet | dv_, my contract with OLPC is over for now, so I am porting all my new work to the cubox....finally |
| 17:05 | jnettlet | I have been sick for a week or so, so am a bit behind on everything |
| 17:05 | dv_ | jnettlet: ah, well, I have been using your driver for my OE layer |
| 17:06 | dv_ | jnettlet: you might be interested in: https://github.com/dv1/meta-cubox/blob/master/recipes-graphics/xorg-driver/xf86-video-dove_git.bb and https://github.com/dv1/meta-cubox/blob/master/recipes-graphics/xorg-driver/xf86-video-dove/0001-autoconf-related-fixes.patch |
| 17:06 | dv_ | I determined that video above 1024x768 wont work with DVI displays, but they do with proper HDMI ones |
| 17:06 | jnettlet | dv_, I will take a look. I actually have a newer driver and galcore that I need to test on the cubox. |
| 17:07 | dv_ | I havent had the time to test rabeeh's I2C trick yet |
| 17:07 | jnettlet | there is someone on the forums that says they are successfully using a different in kernel HDMI driver. |
| 17:07 | dv_ | oh, and the xorg.conf is : https://github.com/dv1/meta-cubox/blob/master/recipes-graphics/xorg-xserver/xserver-xf86-config/xorg.conf |
| 17:07 | dv_ | but overall, the driver works for me. I have also been able to watch videos with it, using the XVideo extension |
| 17:08 | dv_ | EXA also worked, but was unstable; for example, matchbox-session caused it to crash for some reason |
| 17:08 | jnettlet | regardless, I have written a basic HDMI driver for the XO-4 so feel pretty confident we can get the cubox stuff working perfectly |
| 17:08 | jnettlet | dv_, that is probably due to memory. |
| 17:09 | dv_ | well, keep me posted about it. I can add new recipes to the layer then. |
| 17:09 | jnettlet | I also have the newest vmeta gstreamer work...including encoding h264 |
| 17:09 | dv_ | nice! I also added vmeta, but so far only got the decoders for hardfp |
| 17:09 | dv_ | also check out rabeeh's kernel fix for vmeta performance |
| 17:10 | jnettlet | I have switched all the memory manager over to ION, backed by CMA. This makes the allocations dynamic for the desktop so you don't get a huge chunk of memory not doing anything if you aren't watching video |
| 17:10 | dv_ | so the vmalloc parameter will go away? |
| 17:10 | jnettlet | it should. I have to test on the cubox still :-) |
| 17:11 | jnettlet | CMA is real, nice where the memory is mapped out in early boot, but can be allocated out if other programs needed, and then reclaimed by drivers later. |
| 17:11 | dv_ | that would be nice, because the amount of memory to pick for vmalloc is never easy |
| 17:11 | dv_ | *never easy to estimate |
| 17:11 | jnettlet | But I have decoded 1080p h264 using only about 40MB's of RAM |
| 17:12 | dv_ | I currently set it to 384MB, which is probably way too much |
| 17:12 | jnettlet | it depends on the type of streams. |
| 17:14 | dv_ | do you have links to your newer xorg dovefb driver and the new vmeta stuff? |
| 17:15 | jnettlet | dv_, well the dovefb driver, is a revamped pxa168fb driver. I need to merge them. The code for this platform is so fractured at this point it is driver me nuts. |
| 17:16 | jnettlet | dv_, what kernel version are you working from? |
| 17:16 | dv_ | rabeeh's 3.6.9 kernel |
| 17:16 | dv_ | from github |
| 17:17 | dv_ | exact revision is here: https://github.com/dv1/meta-cubox/blob/master/recipes-kernel/linux-cubox/linux-cubox_3.6.9.bb |
| 17:17 | dv_ | I have added his vmeta performance patch to master, for testing it out. so far, I havent seen any issues with it, and I have tried out several videos |
| 17:18 | jnettlet | okay if you are ambitious feel free to grab my recent merge's from http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5 that should integrate the ION MM with CMA and an MMP backend which we need |
| 17:18 | jnettlet | dv_, do you have an image I can download to run on my cubox so we are working from the same thing? |
| 17:20 | dv_ | yes. uploading it to dropbox right now. |
| 17:20 | jnettlet | great thanks |
| 17:21 | jnettlet | dv_, are you using gcc 4.8 or 4.7? |
| 17:22 | dv_ | 4.7 |
| 17:22 | dv_ | 4.8 will be included in a later OpenEmbedded release |
| 17:23 | dv_ | I will then add the new -march=marvellpj4 flag to the machine config |
| 17:24 | jnettlet | okay, I was planning on merging the iwmmxt and marvell tuning patches into the Linaro optimized gcc 4.7 tree this weekend to get all the media stuff compiled. |
| 17:24 | jnettlet | I fell behind because our new chipset supported both iwmmxt and neon, so the iwmmxt stuff fell to the back burner |
| 17:25 | dv_ | both? :O |
| 17:25 | jnettlet | yeah the new mmp3 chip from Marvell supports both |
| 17:25 | dv_ | okay, here you go, here is the rootfs: https://www.dropbox.com/s/vjn0xmczrhm6hif/cubox-demo-image-sato-cubox-hardfp-3.tar.bz2 |
| 17:26 | jnettlet | coming down now thanks |
| 17:26 | dv_ | just unpack it on an SD card, first partition. ext2 or ext3. thats it. |
| 17:26 | jnettlet | will do |
| 17:27 | dv_ | I will eventually move on to a 2-partition solution, since it is more flexible (for supporting sata disks, ext4/jfs/reiserfs/... root partitions, etc.) |
| 17:36 | dv_ | jnettlet: also, do you know of the etnaviv project? |
| 17:38 | jnettlet | dv_, yes but I can't partake in any of the reverse engineering as I have knowledge of the galcore userspace source under NDA |
| 17:38 | jnettlet | I don't want to taint the project |
| 17:40 | jnettlet | but I should provide dumps to them for our GC860 and GC2000 chips |
| 17:43 | dv_ | well, wumpus is the man to talk to about this |
| 17:44 | jnettlet | dv_, yeah it is on my list of things to do in my month off |
| 17:52 | dv_ | is the image running? if you need something added or modified, please let me know |
| 17:53 | dv_ | of course you can set up OE and build it yourself, but that takes several hours on my quad core machine (assuming you have >4GB RAM) |
| 17:54 | jnettlet | dv_, ha...I am not that far. I am upgrading Twonky on my Verbatim Mediashare right now. Another Marvell ARM NAS :-) |
| 17:54 | dv_ | plenty busy, hm? :) |
| 17:55 | dv_ | btw. are the gstreamer vmeta plugins being maintained? or has development ceased, and only vmeta itself is being updated? |
| 17:57 | jnettlet | dv_, nope this is the latest and greatest. Marvell merged some of my previous patches, and added a bunch of their own. It is still only gstreamer 0.10...I may have a project to pay for a gstreamer-1.0 upgrade...will see |
| 17:58 | dv_ | yes, support for gstreamer 1.0 is also something I was considering |
| 17:58 | dv_ | especially adopting it for the new gstreamer base classes, which should cut down code size |
| 18:00 | dv_ | the current plugins are pretty big, and the xbmc patch for vmeta based playback are much smaller |
| 18:01 | dv_ | yes, I just checked. the existing plugins are based off GstElement directly. gstreamer core developers advise against doing that these days. |
| 18:04 | dv_ | jnettlet: also keep me posted about the gstreamer 1.0 thing |
| 18:05 | jnettlet | dv_, I am just in early dealings so we will see, but will let you know anything I can. |
| 18:05 | dv_ | alright, thanks |
| 18:05 | jnettlet | The new plugin is definitely better than the current one in circulation |
| 18:06 | jnettlet | and that on top of my ION mm changes make it a lot more desktop friendly |
| 18:06 | dv_ | I thought of setting up a project containing several hw acceleration elements for various platforms. like marvell vmeta, freescale VPUs, TI codecengine etc. |
| 18:06 | dv_ | because some of them are in a pretty broken state, and none has been updated to 1.0 yet |
| 18:09 | dv_ | ah, any chance of public access to the new vmeta gstreamer plugin? |
| 18:11 | jnettlet | dv_, probably this weekend. |
| 18:11 | dv_ | nice, thanks |
| 19:47 | dv_ | oh jnettlet, do you know the reason why the vivante drivers are X11 only? |