| 00:59 | _rmk_ | lioka: here? |
| 00:59 | _rmk_ | lioka: your compat patch - care to add a signed-off-by to it please? |
| 09:33 | lioka | _rmk_: sure. http://ns.lioka.obninsk.ru/0001-compat-api-stuff-added.patch |
| 11:59 | _rmk_ | lioka: thanks |
| 12:01 | Bluerise | _rmk_: Hey. :) Any news on the BSD-license FDT stuff? |
| 13:15 | SYS64738 | hi |
| 13:21 | MarcusVinter | Hey |
| 13:28 | SYS64738 | ha anyone tried this: http://wiki.xbmc.org/index.php?title=HOW-TO:Compile_XBMC_for_Linux (ubuntu 12.04 LTS) on cubox ? |
| 13:28 | SYS64738 | has |
| 13:59 | MarcusVinter | Not done it myself but it looks pretty straight-forward. |
| 14:00 | MarcusVinter | Why? Are you stuck on something? |
| 14:56 | jnettlet | SYS64738, if you do the geexbox install via the cubox installer that has a customized xbmc build included. |
| 15:16 | erikohman | Hi, i'm just wondering the shipping capacity per day? do anyone know this? |
| 15:25 | jnettlet | hi, I know that nobody knows me, but could you tell me all the details about your supply chain and production capacity? :-P |
| 15:32 | rabeeh | :) |
| 15:32 | rabeeh | jnettlet: erikohman? |
| 15:33 | jnettlet | rabeeh, yeah. just flipped over to the channel and saw that. |
| 15:34 | jnettlet | Of course it is good because people are excited to get their product. |
| 15:37 | rabeeh | yeah. people are working like crazy here to get the systems out of the door ASAP |
| 15:45 | dv_ | \o/ |
| 16:25 | neofob | so `openssl speed -evp aes128` gives me -infk (I can't recall exact string) |
| 16:26 | neofob | `openssl speed -evp aes128 -elapsed` gives me about 13MB/s on 8K blocks |
| 17:26 | hste | dv_: Did u see this https://community.freescale.com/thread/314986 |
| 17:46 | dv_ | hste: thanks |
| 17:47 | hste | dv_: or maybe u r their development team :) |
| 17:47 | dv_ | :D |
| 17:47 | dv_ | well it wouldnt surprise me if they have a team somewhere quietly working on this |
| 17:48 | dv_ | freescale seems to have management problems where the left hand does not know what the right one is doing |
| 17:49 | rabeeh | dv_: i agree |
| 17:49 | rabeeh | it's so fragmented work |
| 17:53 | hste | and not any focus on using the soc in a desktop environment |
| 17:54 | hste | but at least they have a community site where question can be asked :) |
| 17:56 | rabeeh | dv_: added comment |
| 17:56 | rabeeh | hste: this is great; but not only support questions; they need to embrace the community |
| 17:57 | dv_ | rabeeh: thanks for the endorsement :) |
| 18:02 | neofob | rabeeh: so why is the number of openssl with and without -elapsed parameter so different on cubox? |
| 18:02 | neofob | openssl speed test, i mean |
| 18:04 | rabeeh | bug? |
| 18:08 | rabeeh | neofob: i can't find elapsed i nthe openssl man page |
| 18:10 | neofob | rabeeh: but openssl accepts that parameter |
| 18:10 | neofob | it says something about using cpu time instead of timer |
| 18:11 | neofob | i do see speedup with cryptodev but running openssl w/o -elapsed parameter can give you a false hope :D |
| 18:11 | neofob | in the end, i don't know which number is more reliable :/ |
| 18:14 | jnettlet | neofob, it is not what it uses, but what it reports. with the -elapsed option the speed test reports the actual amount of time the test took to run. Wihtout it it reports how much cpu time was spent running the tests. |
| 18:14 | neofob | arh, sorry i got it backward; -elapsed measures the elapsed time instead of user cpu time |
| 18:14 | neofob | jnettlet: thanks |
| 18:15 | jnettlet | running without -elapsed should give you a much lower result because it should be using the crypto engine instead of the cpu |
| 18:15 | jnettlet | I guess both should give you lower results because hopefully the test runs faster, but -elapsed should be longer than without it |
| 18:54 | erikohman | Hi, im just wondering what the shiping capacity per day is atm? |
| 19:05 | jnettlet | hmmm. I wonder how many times he is going to show up ask that question and then leave 5 minutes later between now and Monday. |
| 19:22 | hste | jnettlet: I guess maersk have big shipping capasity :) |
| 19:41 | _rmk_ | jnettlet: yes, quite silly behaviour. |
| 19:44 | hste | jnettlet: looks likes its getting windy in denmark and norway tomorrow |
| 19:45 | _rmk_ | hste: and Scotland |
| 19:46 | hste | _rmk_: yes I guess it will be windy there too :) |
| 20:52 | _rmk | 20:52 * _rmk_ pulls lots of code around in xf86-video-armada... now pulled most of the nonspecific DRM code into a separate file |
| 20:53 | _rmk_ | armada_drm.c is now 640 lines. Who needs more? :) |
| 20:56 | jnettlet | hste, is it? I generally don't look at the weather until the morning. |
| 20:56 | _rmk_ | yea, over here they're saying its our first proper winter storm, winds gusting to 75-80mph |
| 20:57 | jnettlet | _rmk_, oh I have your vivante acceleration code pulled into int's own Xorg extension. I am just playing around with integrating that with the vivante GL acceleration DRI implemetation. |
| 20:58 | _rmk_ | have you come to any conclusion about the v4 drivers via freescale? |
| 20:59 | jnettlet | I think we can use them. I will probably put a disclaimer on the download site or included that says the drivers are only for use on Vivante hardware, and can not legally be decompiled blah blah blah blah blah blah |
| 21:01 | jnettlet | But Freescale's appendix A license, which I missed in my initial hasteful reading, seems to mesh up with the Marvell license of the binaries. |
| 21:01 | jnettlet | Free to use on Vivante hardware and redistribute without modification. |
| 21:02 | jnettlet | Not sure what other hardware you would use them on :-) |
| 21:02 | _rmk_ | an FPGA? :) |
| 21:03 | _rmk_ | okay, that's good, it means I can think about updating xf86-video-armada to use the v4 stuff |
| 21:03 | _rmk_ | or your stuff |
| 21:04 | jnettlet | well the good news is I can take a step back and rip out the compatibility layers I have been f'ing around with and just focus on a single "stable" api. |
| 21:05 | _rmk_ | rotfl "stable" :) |
| 21:05 | jnettlet | Then it is just a balancing act of handling 2-3 dri drivers in userspace. |
| 21:06 | _rmk_ | the alternative is I put the knowledge I have of the 2d vivante stuff to good use and push etnaviv forward |
| 21:08 | jnettlet | Our driver model really needs to be. KMS/FB frontend allocates scan out buffers and some small buffers maybe for cursors and glyphs. Then we pass those into the GPU driver which provides the acceleration architecture and can allocate it's own pixbufs. I have most that sorted out. |
| 21:10 | jnettlet | The v4 binary vivante driver has this added layer of supporting GL on it's GLESv2 hardware which is intriguing for desktop usage. Especially since most distros are still not properly compiling 3d libs with the proper backend support. |
| 21:11 | jnettlet | in theory I can designate the vivante dri driver to handle all 3d windows and then have everything else accelerated through my vivaccel extension based on your 2d work. |
| 21:12 | jnettlet | then armada/imx/etc can use whatever framebuffer kms driver they want as long as it can pass some dmabuf fd's into the vivaccel extension. |
| 21:13 | jnettlet | This was always so much easier when you just had videoram and system memory, a PCI/AGP bus and a GPU |
| 21:20 | dv | 21:20 * dv_ is confused |
| 21:20 | dv_ | what is this about the v4 drivers? |
| 21:44 | jnettlet | dv_, that is the latest vivante binary driver version. |
| 21:45 | dv_ | ah |
| 21:45 | dv_ | so your architecture would allow for pluggin in these, and in future some replacement, like robclark's drm |
| 21:46 | dv_ | I mean, support for it (and etnaviv) |
| 21:54 | jnettlet | that is what I am hoping. |