| 02:10 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/carrier-1-v3.13-rc1-all-20131125.diff |
| 10:07 | dv_ | hmm |
| 10:08 | dv_ | _rmk_: what is your current work on the imx6? |
| 10:30 | jnettlet | dv_, he just posted a patch last night. You need the link? |
| 10:37 | dv_ | hmm not yet |
| 10:37 | dv_ | just being curious |
| 10:37 | dv_ | also, jnettlet, did you notice that eglswapinterval seems to do nothing? |
| 10:48 | jnettlet | dv_, with the latest vivante drivers on freescale? |
| 10:50 | jnettlet | I remember that it used to exist for GLESv1.1, but never GLESv2 in vivante's drivers. I think even Mesa used to just lock eglSwapInterval to the screens vertical refresh rate. |
| 10:52 | dv_ | hm |
| 10:52 | dv_ | well I see lots of tearing, which isnt good |
| 10:53 | jnettlet | this is using freescale's fb driver and dri? |
| 10:55 | dv_ | 3.5.7-1.0.0-alpha.2 |
| 10:55 | dv_ | this is using x11 and gpu-viv-bin-mx6q-3.5.7-1.0.0-alpha.2-sfp.bin from http://download.ossystems.com.br/bsp/freescale/source/ |
| 10:55 | dv_ | and the vivante x11 driver |
| 10:57 | jnettlet | yeah, so that driver doesn't do anything about vsync, unless it is handled in the vivante_dri.so and I have missed that. Although I doubt it because then the vivante gpu would need to know about the ipu's vsync. |
| 10:58 | dv_ | hmm does not sound like something that can be easily fixed |
| 10:58 | jnettlet | The best way to sort this out is to triple buffer the screen like Android does. This is why a lot of "android" drivers don't support egl SwapInterval. |
| 11:01 | jnettlet | All the screen drawing will be done to a primary shadow offscreen buffer. Then when you hit fences you blit that entire buffer over to the secondary framebuffer, that way whenever the framebuffer gets a vsync it can flip and always guarantee a complete frame is drawn without needing to sync with the GPU. |
| 11:02 | jnettlet | of course it takes up 50% more RAM. |
| 11:09 | yosamity | Hello, is there somebody online who has some experience with ipfire on CuBox? |
| 11:12 | jnettlet | nope, but what is your problem? |
| 11:13 | jnettlet | actually just type out your problem. I have to head out for 45 minutes. |
| 11:14 | dv_ | jnettlet : can the shadowbuffer be enabled with these drivers? |
| 11:18 | jnettlet | dv_, nope the imx ddx has the most basic of framebuffer support. |
| 11:18 | jnettlet | it doesn't even support pageflipping |
| 11:19 | dv_ | Hmm :/ |
| 11:32 | dv_ | jnettlet : Any known unofficial hacks for this? |
| 11:38 | dv_ | I would also be happy with some call that blocks until vsync happened |
| 11:45 | _rmk_ | I think the kernel side supports it, it's just userspace... now if I had my ddx driver fully working, then page flipping would be there... |
| 11:46 | _rmk_ | I've kind'a hacked in my cubox version of the kernel side galcore into my carrier-1 build (symlinks are wonderful!) and it detects the 2D hardware fine. |
| 11:46 | _rmk_ | but I need a solution for allocating the pixmaps from shmem |
| 11:48 | dv_ | interesting |
| 11:50 | _rmk_ | btw, the individual patches are again at: http://www.home.arm.linux.org.uk/~rmk/cubox/carrier-1-v3.13-rc1/ |
| 12:22 | jnettlet | it is cool that this http://www.kickstarter.com/projects/alexklein/kano-a-computer-anyone-can-make could be upgraded with a C1, but it is also disappointing that they consider plugging some cables in "making" a computer. |
| 12:22 | jnettle | 12:22 * jnettlet is pretty sure this used to just be called, setting up your computer. |
| 12:23 | jnettlet | _rmk_, do you mean instead of using bmm? |
| 12:25 | _rmk_ | jnettlet: no, with armada drm, I allocate the pixmaps from shmem internally inside armada drm, but imx drm doesn't have that ability |
| 12:39 | jnettlet | maybe I am just being slow today. You allocate those in userspace though? Don't you then just use the galcore api to map them so the graphics driver can use them? |
| 12:39 | jnettlet | or are you not using your armada-drm module with the imx driver yet? |
| 12:39 | jnettlet | and that is the problem. |
| 14:01 | jnettlet | dv_, if you just want for vsync I can give you a quick patch for that. |
| 14:01 | jnettlet | The IOCTL is already in the kernel framebuffer driver. |
| 14:50 | dv_ | jnettlet : yes that would be nice |
| 16:13 | _rmk_ | jnettlet: do you have a set of patches for ION to replace BMM ? |
| 16:36 | jnettlet | _rmk_, yep. I just pulled in the latest patchset, and did some renaming to make it a more generic name. |
| 16:36 | hste | _rmk_: so many patches.... :) |
| 16:36 | jnettlet | do you want it in a consolidate patch? |
| 16:37 | jnettlet | I even added device-tree support, but haven't finished testing that. |
| 16:38 | jnettlet | Wow fabio is really antsy about getting the carrier1 support in u-boot mainline. |
| 16:38 | hste | :) |
| 16:42 | _rmk_ | jnettlet: well, if it weren't for this rename, we may have had something in the kernel by now too |
| 16:44 | jnettlet | _rmk_, I was actually wondering. Are device-tree entries for devices/drivers not in the kernel accepted upstream? |
| 16:45 | jnettlet | my device-tree is currently carrying patches for ion memory heaps and galcore etc |
| 16:45 | _rmk_ | it means either sticking with the carrier-1 name or having to rename the DT file and the DT compatible string |
| 16:45 | _rmk_ | I rather wish that we weren't going through this renaming thing. |
| 16:47 | jnettlet | that is one of the difficulties of developing a product "in the open" OSS engineers don't want to be restrained with business and product going's ons :-) |
| 16:48 | jnettlet | _rmk_, can't we upstream the .dts file and rename it later just keeping the compat entry for carrier-1? |
| 16:51 | jnettlet | _rmk_, so how do you want your ION patches? consolidated or a la carte? |
| 16:51 | _rmk_ | a la carte :) I'm thinking about merging them into my cubox kernel tree |
| 16:51 | _rmk_ | how stable are they? |
| 16:52 | jnettlet | I have just merged the latest changes but we have never had an issue on the XO's that shipped with it. |
| 17:27 | jnettlet | _rmk_, just testing the device-tree stuff quick. |
| 17:59 | dv_ | so what is the chosen name for the carrier one? |
| 18:00 | _rmk_ | not yet known |
| 18:00 | dv | 18:00 * dv_ still likes SolidOne, SolidTwo, SolidFour most out of all suggestions |
| 18:27 | jnettlet | dv_, you will get your vote |
| 18:27 | jnettlet | patience young jedi |
| 23:52 | dv_ | jnettlet: btw do you have a link for the vsync patch you mentioned ? |