| 01:35 | ths1 | Hello ! i'm not shure to understand this post http://imx.solid-run.com/forums/viewtopic.php?f=10&t=808 "yes, this does allow me to access all the resolutions of my DVI monitor, including 1920x1200." |
| 01:35 | ths1 | how it works ... ? |
| 01:49 | dv__ | ths1: certain modes are not in the list of CEA modes (specific to HDMI) but are allowed by DVI |
| 01:49 | dv__ | without this patch, non-CEA stuff will be rejected |
| 01:49 | dv__ | it is a hack, really |
| 01:50 | dv__ | but it works for now |
| 01:50 | ths1 | dv__: but i'm not arrive to compil new file |
| 01:50 | dv__ | ? |
| 01:50 | dv__ | "i'm not arrive to compil new file" ? |
| 01:51 | ths1 | for test this hack, i need file, u-boot ? Non ? |
| 01:52 | dv__ | this is a kernel patch |
| 01:52 | coinsen | ths1: the guy linked a pre-compiled kernel. you can try it out by downloading it and copying it to /boot/uImage |
| 01:53 | ths1 | ok, it doesn't work for me .. my DVI screen goes on sleep mode |
| 01:53 | ths1 | after boot |
| 01:53 | coinsen | ths1: i have the same problem |
| 01:54 | ths1 | hello coinsen |
| 01:54 | coinsen | ths1: jnettlet is working on a solution, but you have to be patient |
| 01:54 | coinsen | it seems like it has something to do with the HDMI <-> DVI converter stuff AND 5:4 aspect-ratio-displays |
| 01:55 | coinsen | so it is possible that this patch works for people who have a hdmi <-> dvi setup, but a 16:9 display |
| 01:56 | ths1 | coinsen: I wait ... but is that this is a priority problem? |
| 01:56 | ths1 | i would like to know if i must think to find hdmi screen to begin to work |
| 02:00 | coinsen | ths1: if you dont want to wait for the patch, use either kernel 3.0.35 or a hdmi display |
| 02:02 | ths1 | coinsen: why the problem is not in kernel 3.0.35 ? |
| 02:02 | Coburn | anyone seen rmk? |
| 02:03 | ths1 | and how to use it ? must i do this: http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard#Kernel_3.0.35_.28patched_with_BSP_4.1.0_and_CuBox-i_and_HummingBoard_support.29 |
| 02:04 | coinsen | ths1: the problem is also in 3.0.35, but at least it is able to boot and display vga resolution (640x480) |
| 02:05 | coinsen | ths1: it depends on your distribution, the default arch linux image comes with kernel 3.0.35 |
| 02:05 | ths1 | i would like to use Debian |
| 02:05 | coinsen | sorry, gotta go to bed now. gn8 everyone |
| 02:05 | coinsen | tomorrow ;) |
| 02:05 | ths1 | i will ask you tomorow ;-) |
| 02:06 | ths1 | good night |
| 02:06 | coinsen | ok, gn8 |
| 09:51 | shadeslayer | btw are the GPU drivers for the CuBox I opensourced? |
| 09:53 | shadeslayer | ah, https://github.com/laanwj/etna_viv |
| 09:55 | shadeslayer | wumpus: I suppose you're the one behind that ^^ ? |
| 09:56 | wumpus | yes |
| 09:58 | shadeslayer | wumpus: how much time does it take to get started on writing a driver ? ( Note that I have no background in opengl, mesa, x11, dri, etc ) |
| 09:58 | shadeslaye | 09:58 * shadeslayer is currently evaluating projects for weekend hacking viability ;) |
| 10:03 | wumpus | I have no clue |
| 10:03 | wumpus | depends on prior experience and such |
| 10:03 | wumpus | what kind of driver do you want to make? |
| 10:05 | shadeslayer | wumpus: I want to contribute to yours :) |
| 10:06 | shadeslayer | wumpus: mostly done some intermediate C/C++ programming |
| 10:06 | shadeslayer | nothing to do with graphics though |
| 10:07 | wumpus | writing etnaviv took me boatloads of time |
| 10:07 | wumpus | so to be honest? no, you won't do it in a weekend |
| 10:08 | shadeslayer | I see |
| 10:09 | wumpus | luckily I've already done most of the things, you don't have to do any reverse engineering work anymore, so you'll likely not spend that much time to do anything |
| 10:09 | wumpus | but it completely depends on what you want to do |
| 10:12 | shadeslayer | weekend hacking, learning bits and pieces |
| 10:12 | shadeslayer | so whatever's available |
| 10:50 | dv_ | shadeslayer: I think wumpus would benefit greatly from further integration of etnaviv into mesa upstream |
| 10:51 | wumpus | an X driver that could work with etnaviv would also be very useful |
| 10:51 | dv_ | yes |
| 10:51 | dv_ | if I had time, I would try, but I am already plenty busy :/ |
| 10:52 | wumpus | yes me too :/ |
| 10:52 | dv_ | a wayland driver as well, hm? |
| 10:52 | dv_ | although, that should be easier I guess |
| 10:52 | dv_ | once etnaviv is in mesa |
| 10:53 | wumpus | most work is probably in the kernel there, the vivante driver is not a DRM driver, which makes all kinds of interactions with mesa really hacky |
| 10:54 | wumpus | although you could emulate most of it in a drm_etnaviv library |
| 10:55 | dv_ | ideally it would be a clean DRM driver with KMS support, right? |
| 10:55 | wumpus | (I made a start with bo emulation in libetnaviv) |
| 10:55 | wumpus | yes |
| 10:56 | dv_ | I must admit, I easily confuse KMS, DRM, etc. |
| 10:56 | dv_ | as well as robclark's efforts and rmk's |
| 10:57 | dv_ | iirc , DRM is used for both communication to whatever outputs the displayed pixels (which is also where KMS comes into play), and for transmission of big buffers between userspace and kernel space |
| 10:58 | dv_ | dmabuf is a means to this end, and the whole architecture which defines that is called DRI |
| 10:58 | dv_ | right so far? |
| 11:00 | wumpus | yes that seems correct, DRM is what is used to manage buffers on the GPU as well as accessing them from the CPU (as well as sending GPU command streams from userspace, for some drivers).. it's the lowest-level part of the GPU driver |
| 11:00 | wumpus | KMS is also part of DRM and makes sure the buffers end up displayed/scan-outed |
| 11:01 | dv_ | but galcore completely sidesteps all of this and does it all by its own |
| 11:01 | dv_ | except the modesetting I gues |
| 11:02 | wumpus | yes, galcore sidesteps everything, it implements its own memory management, as well as command buffer submission, as well as tons of other unrelated things that shouldn't even be in a GPU driver :-) |
| 11:02 | wumpus | indeed not the modesetting because Vivante GPUs can't do that, they just render from buffers to buffers |
| 11:02 | jnettlet | wumpus, you may think I am crazy but my first etnaviv based driver is probably going to be directfb. They are doing some cool work that allows weston to 2d composite with their architecture and then presents a "unified" EGL that wayland can use. |
| 11:02 | dv_ | what is actually setting the mode in the imx6? |
| 11:02 | dv_ | and what is displaying it? mxc_hdmi ? |
| 11:03 | wumpus | modesetting is handled by display controller which differs from SoC to SoC |
| 11:03 | dv_ | jnettlet: oh so there is code that uses EGL with directfb |
| 11:03 | jnettlet | with that layer accelerated we could use SDL/DirectFB-Xorg |
| 11:03 | dv_ | I always thought this is an unholy combination no one ever uses. at least I cant find documentation for it |
| 11:03 | wumpus | on SoCs, scanout is usually completely unrelated to the GPU |
| 11:03 | wumpus | jnettlet: it makes sense |
| 11:04 | wumpus | jnettlet: directfb is by far the easiest to accomplish with etnaviv |
| 11:04 | wumpus | as it already directly renders to fb :-) |
| 11:04 | jnettlet | wumpus, it would let us write 1 driver layer and support Xorg/Wayland+Weston/FB |
| 11:04 | jnettlet | wumpus, exactly |
| 11:04 | dv_ | wumpus: so, an etnaviv x11 driver should be designed in a way that is scanout independent (setting up most of the stuff) and a small part is SoC specific |
| 11:04 | jnettlet | fastest path to implementation with more support |
| 11:05 | wumpus | dv_: yep, no idea how other ARM SoC GPU drivers handle that, but we should likely do the same |
| 11:05 | dv_ | jnettlet: wait what? you would write a directfb-based driver which would then render to x11 through directfb? |
| 11:05 | jnettlet | they have already landed their Weston 2D compositor code upstream. |
| 11:05 | jnettlet | There is already an Xorg server that runs on top of DirectFB |
| 11:06 | jnettlet | basically the same thing that Weston/Wayland is doing with their implementation. |
| 11:06 | wumpus | jnettlet: seems there are even some people out there in the wild using etnaviv for rendering, something like qt quick on top of GLES2 on top of etnaviv... but they haven't told me much as to how they're using it exactly |
| 11:06 | dv_ | so weston is rendering to directfb ... didnt know that. |
| 11:06 | jnettlet | wumpus, yeah the pengutronix guys had some demos |
| 11:06 | dv_ | oh these guys again |
| 11:06 | dv_ | did they actually deliver code? |
| 11:06 | jnettlet | dv_, it isn't. Directfb added a patch that allowed it to. |
| 11:07 | jnettlet | which gives us a generic 2d interface to write to, without worrying about Weston/Wayland churn. |
| 11:07 | jnettlet | http://www.directfb.org/index.php?path=Documentation%2FPresentations |
| 11:07 | jnettlet | check out the top two presentations. |
| 11:07 | dv_ | so, directfb as the basis for xorg, wayland etc. |
| 11:07 | dv_ | hmm |
| 11:08 | wumpus | for wayland you don't need anything like directfb AFAIK |
| 11:09 | wumpus | from what I was told, just GLES2 + the right extensions and inter-process synchronization would be enough |
| 11:09 | dv_ | yes |
| 11:09 | dv_ | I actually prefer GLES+EGL as the basis |
| 11:09 | dv_ | but it is kinda GPU specific |
| 11:09 | jnettlet | wumpus, correct. What the directfb guys are proposing though is a unified EGL interface |
| 11:09 | wumpus | jnettlet: right |
| 11:10 | jnettlet | so many vendors do their specific things. |
| 11:10 | dv_ | but isnt this the purpose of EGL? to be an abstraction layer for the client APIs? |
| 11:10 | dv_ | you just shift the platform dependent part further down, to dfb |
| 11:11 | wumpus | the only drawback with full EGL/GLES2 is that you wouldn't have 2D acceleration, then again, in practice modern applications use all kinds of fancy effects for which you want a 3D engine |
| 11:11 | dv_ | wumpus: on embedded you do want to use dedicated 2D cores for power saving though |
| 11:11 | jnettlet | wumpus, yes but the 3D core uses a lot more power |
| 11:12 | wumpus | but if for example android is an example, do we really care? |
| 11:12 | jnettlet | dv_, the problem is that then you need different EGL libraries for the windowing backend you are using. |
| 11:13 | dv_ | hmm, which isnt the case with directfb |
| 11:13 | wumpus | the 2D core at least in vivante is extremely limited |
| 11:13 | jnettlet | in theory this was supposed to be fixed by DRI, but since that requires more levels of openness than most drivers want to do you are stuck with Vivante having 5 libEGL.so's |
| 11:13 | dv_ | also, I can imagine with a unified interface you could use a client DFB context for purely 2D drawing |
| 11:13 | jnettlet | dv_, that is what they have added to weston |
| 11:13 | dv_ | so weston can make use of such a client DFB context if available |
| 11:14 | jnettlet | yep, already |
| 11:14 | dv_ | okay, the unified library + the additional client contexts are extra features not available with pure EGL |
| 11:14 | jnettlet | and use that to accelerate 2d drawing operations |
| 11:14 | dv_ | now I wonder though how this would be unified |
| 11:15 | dv_ | what stops vendors from making a dfb-x11.so, a dfb-wayland.so etc. ? |
| 11:15 | jnettlet | well people would need to start using it. |
| 11:15 | dv_ | (for the window handles and all that) |
| 11:15 | jnettlet | because the window handles just get in the way. Really all we car about is pixbufs at the driver level. |
| 11:16 | jnettlet | and that is what directfb is really good at. |
| 11:16 | dv_ | so the unified frontend would translate the display manager specific handles into something unified and DFB specific |
| 11:16 | dv_ | the vendors then need to implement just that |
| 11:16 | jnettlet | yep |
| 11:16 | dv_ | ah, okay |
| 11:16 | jnettlet | I am not saying it is perfect, but I think it is a good idea. |
| 11:17 | dv_ | that is indeed one weak point of EGL - they didnt address this translation properly |
| 11:17 | wumpus | also the vivante 3D engine has a few complications with tiled/multitiled surfaces, last time it was not really clear how to handle those in the case of DRM |
| 11:17 | jnettlet | with limited developer resources it would be possible to focus on one driver set and have some support for lots of windowing options |
| 11:17 | dv_ | EGLNativeDisplay etc are just typedefs, so it can easily happen that multiple EGLs become necessary |
| 11:18 | wumpus | currently it expects linear pixmaps in most places, without facilities to untile/tile where needed as for most desktop hardware that's handled by the GPU transparantly |
| 11:19 | jnettlet | wumpus, I think intel wrote a software layer to do that for one of their drivers that didn't support it in hardware |
| 11:19 | jnettlet | if my memory serves me correctly. |
| 11:19 | wumpus | well the vivante hardware can tile/untile, but it is a limited blit-like operation, it cannot like Intel pretend that a certain memory area is untiled to the CPU |
| 11:20 | wumpus | hm okay |
| 11:20 | wumpus | that'd be useful :) |
| 11:21 | jnettlet | not to mention this also opens up some possible cool features, like. Boot directly to a web-browser on a directfb surface. Then click a button to launch a desktop around the already open web browser and turn that into a window :-) |
| 11:22 | MarcusVinter | Good morning everyone. I'm wondering if anyone has tried to upload the bluetooth firmware before using brcm_patchram_plus? I'm getting the following message: writing |
| 11:22 | MarcusVinter | 01 18 fc 06 00 00 c0 c6 2d 00 |
| 11:22 | MarcusVinter | received 7 |
| 11:22 | MarcusVinter | 04 0e 04 01 18 fc 00 |
| 11:22 | MarcusVinter | Done setting baudrate |
| 11:22 | MarcusVinter | Can't set hci protocol |
| 11:59 | rabeeh | MarcusVinter: what is your full command for brcm_patchram_plus? |
| 12:00 | rabeeh | when android loads the bt driver for bcm4330 it runs - |
| 12:00 | rabeeh | brcm_patchram_plus -d --patchram /system/etc/firmware/brcm/bcm4330.hcd --baudrate 3000000 --enable_hci --use_baudrate_for_download /dev/ttymxc3 --no2bytes --enable_lpm --tosleep=50000 |
| 12:14 | MarcusVinter | Mine was: brcm_patchram_plus -d --patchram /lib/firmware/brcm/bcm4329.hcd --baudrate 3000000 --use_baudrate_for_download /dev/ttymxc3 --enable_hci |
| 12:14 | MarcusVinter | Thanks i'll try the other params now and see if it helps. |
| 12:14 | coinsen | i just joined - what are you talking about? ;) |
| 12:14 | coinsen | brcm seems like wifi stuff |
| 12:15 | MarcusVinter | Bluetooth on linux lol |
| 12:15 | coinsen | oh okay |
| 12:15 | coinsen | :D |
| 12:17 | MarcusVinter | rabeeh, so far its repeating "writing, 01 03 0c 00" over and over. I'll leave it a while and see if anything happens. |
| 12:21 | coinsen | btw, i'm running xbmc on archlinux (default kernel 3.0.35) - the menu is quite fast, however, when it comes to video playback, it lags. so the video is slow and hangs |
| 12:21 | coinsen | anyone knows a solution for that? |
| 12:22 | MarcusVinter | What device? |
| 12:22 | coinsen | the quad core cubox |
| 12:22 | MarcusVinter | :O nice. I'm not sure myself, I haven't used xbmc really. |
| 12:23 | MarcusVinter | Is it the geexbox image? |
| 12:23 | coinsen | no, its selfmade installed xbmc on archlinux :) |
| 12:23 | MarcusVinter | Why not use the geexbox one might I ask? |
| 12:24 | coinsen | good point - ill try it out to verify. i would like to stay with arch because it gives me more freedom ;) i'd like to use the cubox as a nas at the same time |
| 12:25 | MarcusVinter | I'm not an expert but your build probably doesnt utilize the video processor properly. |
| 12:25 | MarcusVinter | Here: http://download.solid-run.com/pub/solidrun/cubox-i/GeexBox-xbmc/geexbox-devel-20131212-r16611.cuboxi/ |
| 12:26 | MarcusVinter | I think you want the second to bottom one, size 225712280 |
| 12:36 | MarcusVinter | rabeeh, maybe is because my patch is bcm4329.hcd where as the android one is bcm4330.hcd? |
| 12:40 | MarcusVinter | This guy had the same problem as me, but never mentions how he fixed it. |
| 12:40 | MarcusVinter | http://imx.solid-run.com/forums/viewtopic.php?f=16&t=461&start=20#p3128 |
| 13:04 | rabeeh | if you have a bcm4329 chip then the command would be - |
| 13:04 | rabeeh | brcm_patchram_plus -d --patchram /system/etc/firmware/brcm/bcm4329.hcd --baudrate 3000000 --enable_hci --use_baudrate_for_download /dev/ttymxc3 |
| 13:29 | MarcusVinter | Damn, I still get "Can't set hci protocol". I cant figure this out. |
| 13:38 | rabeeh | MarcusVinter: which kernel? and what is the .config |
| 14:03 | MarcusVinter | The kernel is one you built. 3.0.35-g0f2006c-dirty |
| 14:04 | MarcusVinter | .config contains a folder "pulse" and config "Trolltech.conf" |
| 17:39 | MarcusVinter | Anything wrong with that kernel rabeeh? |
| 17:52 | Skynet2mainframe | hello |
| 17:53 | MarcusVinter | Hey |
| 17:55 | Skynet2mainframe | has anyone got news of the next dispatch? |
| 18:01 | coinsen | dis what? |
| 18:04 | Skynet2mainframe | when next shipment is? |
| 18:11 | MarcusVinter | Damn, someone named davorin had the same problem in Jan but not sure if he found solution |
| 18:49 | coinsen | btw, does anyone know if kvm or xen runs on cubox-i? |
| 18:57 | mal- | i dont think so.. |
| 18:57 | mal- | but perhaps seen |
| 18:57 | mal- | soon |
| 18:57 | mal- | http://imx.solid-run.com/forums/viewtopic.php?f=8&t=801&p=5543 |