| 15:04 | frilled | Anybody got issues with dovefb? Mine is some pixels off to the right an up, meaning the uppermost text line has some pixels cut off, as well as the rightmost column. That's on 1920x1080. |
| 15:06 | frilled | (HDMI connection) |
| 16:37 | dv_ | frilled: have you seen this with 1920x1200 only? |
| 16:37 | dv_ | or also with other resolutions? |
| 17:22 | frilled | dv_: 1920x1080 actually. Didn't try others since it's the native displax rez. xorg driver is fine. |
| 17:23 | dv_ | I have seen something similar. its as if the image was enlarged a bit |
| 19:57 | dsd | hi, just wondering if the cubox-packages.tar.gz download on http://www.solid-run.com/mw/index.php/Downloads is up-to-date with the latest stuff you guys have? |
| 19:57 | dsd | i'm working on similar hardware (OLPC XO) and that package has been a huge help in piecing some things together, just curious if marvell might have provided you guys with something newer over the years |
| 20:01 | frilled | dv_, the image i perfectly pixel-clear, but offset to the top right. I'd say 2 or 3 pixels. |
| 20:02 | dv_ | what distro are you using? |
| 20:02 | dv_ | dsd: they have |
| 20:02 | dv_ | it is rather confusing though |
| 20:03 | dv_ | dsd: I mention this in my OE layer: https://github.com/dv1/meta-cubox you can also look into the recipes, and see which tarballs I pick (something from inside cubox-packages.tar.gz , or an entirely different package etc.) |
| 20:03 | dv_ | dsd: also, jnettlet (currently offline) announced that new packages for vmeta, galcore, gstreamer , ipp will be pushed soon |
| 20:06 | frilled | dv_, ArchLinux |
| 20:07 | dv_ | hmm then perhaps it is display dependent. I got an enlarged pic |
| 20:07 | frilled | mh |
| 20:07 | frilled | Any ide where to look for debugging, though? |
| 20:08 | frilled | It's kinda annoying, since the pic itself is crystal clear ... ;) |
| 20:10 | dv_ | unfortunately, no. jnettlet is the person to contact, he co-authored the xorg dovefb driver |
| 20:11 | frilled | btw, who's an ALarm dev around here? |
| 20:11 | frilled | ah, but the xorg display is fine, it's just the text frame buffer |
| 20:11 | dv_ | oh! |
| 20:12 | frilled | console, hat is |
| 20:12 | dv_ | then I am not sure. |
| 20:12 | dv_ | alarm dev, hmm. you have a better luck on the solid-run cubox board then |
| 20:12 | dv_ | pepedog is there, I think he developed the archlinuxarm PKGBUILDs |
| 20:12 | frilled | oh, too bad :) |
| 20:12 | frilled | aha, ok |
| 20:13 | dv_ | well, gotta run. later |
| 20:13 | frilled | thx, bibi |
| 20:48 | dsd | thanks for the info - i know jnettlet as well |
| 20:49 | dsd | we are using fedora, but i was mostly asking about source |
| 21:01 | dsd | in the original ipp code drop (e.g. the one included in the packages tarball) there are libs for various codecs such as |
| 21:01 | dsd | libcodecjpeg*, libcodech263*, libcodecmpeg4* |
| 21:02 | dsd | i'm curious why those are there (they are big, and vmeta should do the codec work in hardware, no?).. and it looks like https://github.com/dv1/meta-cubox does not bother shipping them, just libcodecvmetadec |
| 21:05 | dsd | ah, now i see the description in the readme. you guys dont have those libs for hardfp yet. still curious why we bother with the ones that are handled in hardware by vmeta though |
| 21:56 | dv_ | dsd: the ipp codecs do not use hardware acceleration |
| 21:56 | dv_ | they are just software codecs with iwmmxt optimizations |
| 21:56 | dv_ | and yeah, they only exist for softfp |
| 21:57 | dv_ | dsd: I also strongly recommend you pick the packages I chose in the recipes. some, like the libgfx libraries, exist in several variations, and some of these are broken or just plain outdated |
| 21:58 | dv_ | the libgfx one in particular was fun.. |
| 21:58 | dsd | yeah |
| 22:00 | dsd | for the ipp thing.. why does cubox (and olpc) ship a software codec for MPEG4, while that codec can be handled purely in hardware via vmeta? |
| 22:00 | dv_ | dsd: also, I use the dovefb xorg driver from dev.laptop.org . it is also made for the OLPC. you might have to play around with the defines, though. |
| 22:00 | dv_ | dsd: good question. |
| 22:01 | dv_ | dsd: my guess is that this is one standard package issued for several armada variants |
| 22:01 | dv_ | and some of them don't have vmeta |
| 22:01 | dsd | yeah, could be |
| 22:01 | dv_ | dsd: also keep in mind that regular opengl is not hardware accelerated |
| 22:02 | dv_ | opengl ES is |
| 22:02 | dv_ | so if you want to use a compositor, make sure it uses the right API. (the 3d drivers do not work without X11, btw.) |
| 22:04 | dsd | 3D is a challenge for another day :) glad to see that there might be some experience here to help with that |
| 22:04 | dv_ | once I found the right libgfx libraries, 3d was no problem |
| 22:04 | dv_ | I never tried it with stuff like compiz or emerald though |
| 22:05 | dsd | it looks like cubox and olpc is relatively synced up, and i'm feeling a bit more knowledgeable now on these topics. now i will publish a git repo with olpc's latest xf86-video-dove changes |
| 22:05 | dv_ | yeah, also, jnettlet wanted to do a cleanup of the dovefb driver I think |
| 22:06 | dv_ | well, gotta run again. later |
| 22:06 | dsd | thanks |