| 10:04 | jnettlet | dv_, how is your vivante sink going? |
| 10:21 | dv_ | didnt have the time to continue, but it doesnt look good. |
| 10:21 | dv_ | can application associate a custom buffer with an X11 pixmap? |
| 10:21 | dv_ | I have a hardware video decoder on an embedded platform using the freescale imx SoC. it decodes to a physically contiguous buffer. the idea is then to associate this buffer somehow with a pixmap, so that the decoded frames can be shown on screen by using that pixmap. |
| 10:21 | dv_ | dv_: an app cannot - only a driver can |
| 10:22 | dv_ | isnt there some kind of simple 2D API that we could implement here? |
| 10:52 | jnettlet | dv_, was that from the gstreamer channel? |
| 10:53 | dv_ | no. #xorg-devel |
| 10:57 | jnettlet | well to be exact we aren't implementing pure zero-copy. We just want to use the GPU to blit the buffer to the display rather than copying the buffer and then putting it onto the display. |
| 10:57 | dv_ | true |
| 10:58 | dv_ | complete zero-copy would blit directly to framebuffer |
| 10:58 | dv_ | err, I mean, write directly to framebuffer |
| 10:59 | jnettlet | well complete zero-copy would be with an overlay and you would just tell the graphics hardware that the overlay exists that the decoded frames address. |
| 10:59 | jnettlet | but that is only if your overlay supports yuv -> rgb conversion |
| 10:59 | jnettlet | but without an overlay a single gpu blit is the next best thing. |
| 10:59 | dv_ | yeah |
| 11:00 | dv_ | thats what video4linux can do for example |
| 11:00 | dv_ | but there is no standard way to do that with v4l |
| 11:00 | jnettlet | and that was originally how a lot of drivers hacked around this. |
| 11:00 | dv_ | freescale added a hack to pass on physical addresses, but it works for only one video output at the same time, and doesnt play nice with compositors |
| 11:02 | dv_ | btw. thats also why overlays are only of limited use |
| 11:05 | dv_ | it is true though that this blit limits the throughput. on many embedded platforms, 1080p60 is only achievable with such overlays |
| 11:05 | jnettlet | all this stems from the fact xorg is written around first having to move things from system RAM to video RAM. |
| 11:05 | dv_ | but there is no other option.. |
| 11:05 | dv_ | yes, indeed |
| 11:06 | dv_ | and since it is written for PCs first and foremost, the special concerns of embedded platforms are not addressed |
| 11:06 | jnettlet | the vivante GPU can easily do 1080p@60 |
| 11:06 | dv_ | hmm I should rerun my 1080p60 tests with it then |
| 11:07 | dv_ | maybe the limiting factor was the VPU after all. |
| 11:07 | dv_ | anyway, wayland is used in the automotive sector. so embedded concerns *are* considered. |
| 11:07 | jnettlet | the limiting factor could be the VPU or the memory bandwidth |
| 11:09 | dv_ | hm. we could add the marvell hack to the imx xorg driver :) |
| 11:13 | jnettlet | what kind of memory does the iMX6 vpu use? |
| 11:13 | jnettlet | curious if it uses uncached memory like vMeta. |
| 11:14 | dv_ | uncached, yes |
| 11:14 | dv_ | which causes bizarre results |
| 11:15 | dv_ | it is faster to draw into a virtual memory block, and then memcpy this to a dma buffer, instead of drawing into the dma buffer directly |
| 11:15 | dv_ | because of missing write-combine |
| 11:15 | dv_ | it is not a hw problem though it seems. just a matter of putting writecombine and caching into the API. |
| 11:16 | jnettlet | what is it using for memory allocation? |
| 11:17 | dv_ | oh thats the fun part |
| 11:17 | dv_ | there are at least three different sets of allocation functions |
| 11:17 | dv_ | (for physically contiguous memory) |
| 11:17 | dv_ | one for the VPU decoder, one for the encoder, one for the IPU |
| 11:17 | dv_ | neither allows me to specify writecombine or cached |
| 11:18 | dv_ | I have heard about efforts to unify that into a "contiguous memory allocator". havent gotten updates though. |
| 11:18 | jnettlet | and that part of the code is closed? |
| 11:18 | dv_ | the VPU ones, no. the library they are defined in is open. |
| 11:19 | dv_ | the IPU allocators are essentially ioctl calls |
| 11:19 | jnettlet | oh so it is done in the kernel? |
| 11:19 | dv_ | in fact, to use the IPU, you have to use kernel headers |
| 11:19 | dv_ | from what I have seen, yes. internally, the VPU parts of the imx-lib also use ioctl calls, though they seem to be different ones. |
| 11:21 | dv_ | I have been thinking about a future project, once I finish my gstreamer plugins (and other stuff). some kind of reimplementation of the imx-lib and vpu wrapper |
| 11:21 | dv_ | to have one more sane API for IPU and VPU use. and *one* allocator. |
| 11:23 | jnettlet | do their current API's use virtual addresses or do they pass back physical addressed like vMeta requires? |
| 11:24 | dv_ | the VPU allocators return virtual, physical, and "cpu addresses" |
| 11:24 | jnettlet | haha |
| 11:24 | dv_ | the IPU one returns only a physical address. you get a virtual one by mmap'ing |
| 11:25 | jnettlet | cover the entire range |
| 11:25 | dv_ | (I suspect the VPU ones mmap internally) |
| 11:25 | jnettlet | okay so they are just as bad as vMeta |
| 11:25 | dv_ | actually worse, because vmeta has only one allocator api |
| 11:25 | dv_ | also, the VPU API is less flexible than vMeta's |
| 11:26 | jnettlet | well Marvell was smart enough to abstract out their allocator api to be able to handle multiple allocation backends. |
| 11:26 | dv_ | its that thing I mentioned here a while ago, that you cannot allocate new output buffers during playback if necessary |
| 11:27 | dv_ | btw. any idea what "cpu addresses" could be? |
| 11:29 | jnettlet | without looking at it 100% my guess would be the address based on the hardware offset rather than the offset used as the base address of physical memory. |
| 11:32 | jnettlet | I am sure _rmk_ can probably give a thorough explanation. |
| 11:33 | dv_ | right, reminds me of something |
| 11:33 | _rmk_ | shesselba: I'm sending my patch to fix the hdmi audio muting directly to Linus now |
| 11:33 | dv_ | _rmk_: you work with vaapi because you want to use vmeta in VLC, right? |
| 11:33 | dv_ | _rmk_: then why not just add vmeta directly to libavcodec? |
| 11:39 | _rmk_ | because hardware decode on libavcodec is only supported via vaapi or vdpau, and while it may be possible to modify libavcodec directly, it'll also need the library users modified too |
| 11:39 | dv_ | from what I have seen, there is an internal API for hardware codecs |
| 11:40 | _rmk_ | but... that still won't get around vlc doing copying of the rendered image |
| 11:40 | dv_ | true. |
| 11:40 | dv_ | unless you can tunnel the physical buffer somehow |
| 11:41 | _rmk_ | oh? what API? |
| 11:42 | dv_ | well thats what I mean with "somehow" :) |
| 11:42 | dv_ | good question for #libav though |
| 11:43 | _rmk_ | you said you've seen an API for doing this in libav... |
| 11:44 | dv_ | ah, the decoding |
| 11:44 | dv_ | wait a sec |
| 11:46 | dv_ | http://ffmpeg.org/doxygen/trunk/structAVHWAccel.html |
| 11:47 | dv_ | there is also vdpau and vaapi code inside libavcodec that can be used as an example |
| 11:48 | jnettlet | dv_, do you have the link to the 2d engine docs on Freescale's dev site? |
| 11:48 | jnettle | 11:48 * jnettlet only has the docs for the older version. |
| 11:49 | dv_ | you need to be registered on the freescale site |
| 11:49 | _rmk_ | dv: it's still a slice level API |
| 11:50 | _rmk_ | iow, still not the ES level |
| 11:50 | jnettlet | dv_, I am. |
| 11:50 | dv_ | I found it inside the L3.0.35_4.0.0_docs tarball |
| 11:51 | dv_ | trying to find a link |
| 11:51 | dv_ | _rmk_: I dont see anything that specifies header information separately |
| 11:56 | dv_ | jnettlet: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q |
| 11:56 | dv_ | try L3.0.35_4.1.0_LINUX_MMDOCS |
| 11:56 | jnettlet | okay thanks |
| 11:58 | dv_ | oh wait, I think DOCS, not MMDOCS |
| 11:59 | jnettlet | okay. and it is *NEW* |
| 12:00 | dv_ | in fact, I have only looked at the 4.0.0 one |
| 12:00 | dv_ | hmm |
| 12:00 | dv_ | okay. in L3.0.35_4.1.0_130816_docs/doc/mx6/ , look at "i.MX_6_G2D API.pdf" |
| 12:01 | jnettlet | yep got it. thanks |
| 12:01 | dv_ | uh no. thats new. I meant i.MX_6_2D_API.pdf |
| 12:01 | dv_ | no idea what G2D is. the second one is the GAL API. |
| 12:03 | jnettlet | g2d is the simpler 2d only api |
| 12:04 | dv_ | _rmk_: #libav-devel confirms, it is a slice level API. |
| 12:04 | dv_ | but one guy may have code to work around that |
| 12:04 | dv_ | he did stuff for intel hw en/decoding |
| 12:04 | dv_ | talk to lu_zero |
| 12:06 | dv_ | or better yet, just go to #libav-devel |
| 13:10 | wumpus | is g2d some open API? or again vivante proprietary shit? |
| 13:13 | steev | it's not vivante specific |
| 13:13 | steev | but i don't know if it's open or not |
| 13:14 | wumpus | it's an incredibly hard-to-google name at least :) |
| 13:14 | steev | indeed |
| 13:14 | steev | i only know as i used to work with the amd drivers for the imx5 |
| 13:15 | steev | due to that, i can't work on any of the open source stuff :/ |
| 13:15 | wumpus | would be nice to have some cross-platform api for simple 2D engines, there doesn't seem to be one |
| 13:15 | steev | ogre? |
| 13:15 | wumpus | isn't ogre a 3d engine? :o or is there some other? |
| 13:16 | steev | i thought they did 2d and 3d |
| 13:16 | wumpus | I know about directfb, blitsville, etc, but not what their status is |
| 13:16 | wumpus | ogre is high level and builds upon opengl es, something low-level would be needed that for example Xorg EXA drivers could use |
| 13:16 | steev | i could be wrong though, it's been known to happen |
| 13:17 | wumpus | the EXA api itself would do, but it's nto really useful outside of X, so there appearsto be no way of writing a generic 2D driver without cooking up my own api |
| 13:17 | jnettlet | wumpus, it is a more simplistic wrapper to the 2d portion of libGAL |
| 13:17 | jnettlet | their directfb driver uses it I believe |
| 13:18 | wumpus | directfb is maybe promising |
| 13:18 | wumpus | as they're working on a KMS backend too |
| 13:18 | wumpus | and SDL can use it |
| 13:19 | jnettlet | Vivante was pushing us to use directfb as they said it was 3 times as fast on their hardware as X |
| 13:20 | wumpus | couldn't X (theoretically) use directfb as backend? |
| 13:20 | wumpus | a directfb EXA driver could remoe the need for specific X drivers |
| 13:21 | jnettlet | I guess theoretically it could if you really needed it. But generally you would much rather have the graphics toolkit you were using support it directly. |
| 13:21 | jnettlet | except for legacy compatibility |
| 13:22 | wumpus | well the thing is, wayland needs no gpu specific drivers, just some EGL extensions |
| 13:22 | wumpus | it's annoying that Xorg still needs them |
| 13:23 | wumpus | I'll have wayland support way before X |
| 13:23 | jnettlet | have you tested Vivante's wayland driver yet? |
| 13:23 | wumpus | nope |
| 13:24 | jnettlet | I wonder if we could write a vivante backend for wayland like they have done for the raspberry pi. |
| 13:24 | wumpus | haven't used for even looked at the vivante blobs for a long time, it's for the better :) |
| 13:24 | jnettlet | I like the idea of Wayland but would rather keep things on the 2d engine for basic drawing. |
| 13:25 | wumpus | yeah, me too, I just don't want to write N different drivers for the 2D engine |
| 13:25 | jnettlet | definitely. I wish I hadn't looked at the vivante source, so I could help out more. |
| 13:25 | wumpus | that's why I was talking abouta general cross-platform 2D API, that's not bound to X specifically |
| 13:26 | wumpus | and directfb looks most promising for that for now |
| 13:26 | jnettlet | I tested X on directfb early on and it needs a lot of work. |
| 13:27 | wumpus | but it can be done already? |
| 13:29 | jnettlet | yeah it is unmaintained now but it was called XDirectFB. clever huh :-) |
| 13:29 | wumpus | that's a pity |
| 13:30 | wumpus | seems they tried all kinds of fancy stuff |
| 13:31 | wumpus | I guess they eventually realized that wayland already exist |
| 13:55 | dv_ | jnettlet: there is wayland support for the imx6 |
| 13:55 | dv_ | maybe it can be reused/generalized |
| 13:55 | dv_ | but yeah, some simple 2D API would be useful |
| 15:12 | rabeeh | wumpus: in the i.MX6 series there is an internal SRAM; i was wondering if that can be mapped to do some caching for the GPU? |
| 15:12 | rabeeh | if not caching then some sort of fast memory that can be used for extensive GPU operation? |
| 15:15 | jnettlet | rabeeh, how big is the SRAM on the i.MX6? |
| 15:15 | wumpus | rabeeh: maybe, I'm not sure whether the GPU can access the SRAM |
| 15:15 | rabeeh | 128KB on the solo and dual lite; 256k on the dual and quad |
| 15:16 | wumpus | that'd be big enough to store the command queues I suppose |
| 15:16 | rabeeh | is the command queue something heavy on the DDR bus? |
| 15:17 | wumpus | I think where SRAM is most useful is when you're running some algorithm with a small working set, I'm not sure there are much of those in GPU rendering |
| 15:17 | wumpus | there is of course pixel format and vertex format conversion, but those you'd like to avoid in the first place, and they have a very small working set that would even fit in registers |
| 15:17 | wumpus | same for texture tiling... |
| 15:17 | wumpus | nah, heaviest on the DDR bus is rendering itself (and texturing) |
| 15:18 | jnettlet | well our Marvell chipsets use the SRAM to do DMA rotations and such. |
| 15:18 | wumpus | but it'd be a pretty small framebuffer/texture :) |
| 15:18 | wumpus | even the gcwzero framebuffer wouldn't fit in it :P |
| 15:18 | wumpus | well on 16 bit it would |
| 15:19 | dv_ | wumpus: fillrate heavy stuff could be interesting on the cubox-i |
| 15:19 | dv_ | wumpus: since it has ddr3 and rather high clock rate |
| 15:19 | dv_ | (compared to most other embedded platforms that is) |
| 15:19 | wumpus | rabeeh: the command queue is not that heavy, well at least if you're using the GLES driver in a proper way, thus not submitting too many batches |
| 15:19 | wumpus | dv_: yes that's very nice :) |
| 15:20 | dv_ | rabeeh: no.1 is the fillrate |
| 15:20 | wumpus | that's very cool about the cuboxes that they have fast memory |
| 15:20 | dv_ | its why a geforce gtx 660 can do deferred shading while an embedded platform cant |
| 15:21 | dv_ | (performance-wise I mean) |
| 15:21 | wumpus | even a R300 could do deferred shading :) |
| 15:21 | wumpus | with floating point textures and multi render targets |
| 15:21 | dv_ | yeah, but all of them have dedicated GDDR RAM on the card, very closely located to the chip |
| 15:21 | wumpus | indeed |
| 15:21 | dv_ | with 192- or even 256bit bus |
| 15:22 | wumpus | right, it's just not comparable |
| 15:22 | wumpus | plus they have large caches on the gpu itself, lots more silicon available |
| 15:22 | wumpus | then again, comparing embedded versus desktop isn't really fair |
| 15:22 | wumpus | very different goals |
| 15:23 | dv_ | yes. power consumption alone is from a different planet |
| 15:23 | dv_ | I remember reports about nvidia's difficulties with the fermi architecture, because they were stressing the power limits of PCI-express |
| 15:24 | dv_ | yes, even *with* an additional 12V power connector |
| 15:24 | wumpus | most people that use imx will not care about heavy 3d rendering at all, let alone gaming, so most would be wasted |
| 15:24 | dv_ | yeah |
| 15:24 | dv_ | some casual games, perhaps flash compositor effects, thats it |
| 15:25 | dv_ | *flashy |
| 15:25 | wumpus | yeah, it's fast enough for that |
| 15:27 | dv_ | hmm gtx660 has a TDP of 140 W |
| 15:27 | dv_ | how many cubox-i are needed to equal that :D |
| 15:28 | wumpus | about 40, i think :) |
| 15:30 | dv_ | oh, and wumpus, I think you said once that you are looking into getting etnaviv into mesa? I mean, upstream? |
| 15:30 | wumpus | yes, that's eventually the goal |
| 15:30 | wumpus | but I need dmabuf support first |
| 15:30 | wumpus | which needs _rmk_'s work on the kernel drivers |
| 15:31 | wumpus | currently it doesn't play well with DRM/GEM/etc |
| 15:40 | _rmk_ | do I try resubmitting the drm kernel stuff... |
| 15:41 | _rmk_ | or do I wait for the hoohar to happen over me sending the tda998x fix direct to Linus |
| 15:42 | _rmk_ | (interestingly, Al Viro was complaining about the crappy state of the exynos drm driver recently... which pisses me off that airlied allowed it in with it being rather crap) |
| 15:43 | jnettlet | _rmk_, what did airlied not like about the armada drm driver? |
| 15:44 | _rmk_ | jnettlet: basically, when I wrote it, I thought "this is silly, the core DRM code should provide functions which lookup object type X and return a typed struct of the appropriate type" |
| 15:45 | _rmk_ | so I created a header file with some helpers in |
| 15:45 | _rmk_ | airlied refused to take it until that file was moved to somewhere others could use it. |
| 15:45 | _rmk_ | ... which is no reason to _not_ take the patch set and move it later. |
| 15:45 | jnettlet | correct. |
| 15:45 | _rmk_ | but no, he wanted it moved there and then. |
| 15:45 | wumpus | right |
| 15:45 | wumpus | that's one way to hold patches up forever |
| 15:46 | jnettlet | that is what you get for trying to make things easier. |
| 15:46 | _rmk_ | so my response to that was: don't expect me to move it any time soon |
| 15:46 | _rmk_ | and my conclusion is: if you write crap code which fails to work, you can get it into the kernel. If you think about what you're doing, expect a fscking hard time |
| 15:47 | _rmk_ | I finally got around to moving that header file last weekend... |
| 15:47 | _rmk_ | but of course, DRM has seen a lot of changes during the last merge window and I'm on 3.11 not 3.12-rc1 |
| 15:47 | dv_ | makes me wonder how things get done at all in the kernel |
| 15:56 | _rmk_ | hmm... google+ just popped up several possibilities for #cubox |
| 15:57 | _rmk_ | lets see what happens when I merge v3.12-rc2 into the cubox-3.11 branch |
| 15:58 | _rmk_ | might help if the fingers worked properly, and typed 'remote' not 'remove' |
| 16:00 | _rmk_ | 10 conflicting files |
| 16:12 | _rmk_ | building... |
| 16:22 | rabeeh | all: early dev machines are out |
| 16:23 | rabeeh | they just told me it was sent few hours ago; probably a follow up email with tracking number will follow |
| 16:25 | _rmk_ | \o/ |
| 16:28 | rabeeh | someone wants to try the rpi camera on it? |
| 16:28 | rabeeh | the header is compatible and the voltage levels etc... |
| 16:28 | rabeeh | oh; before you guys get suprised; the board is almost identical to the rpi |
| 16:29 | purch | I should have applied for dev. Two months is a long time =) |
| 16:29 | rabeeh | purch: sorry; maybe in the next batch |
| 16:29 | rabeeh | what kind of dev can you do? |
| 16:29 | _rmk_ | rabeeh: you're not trying to tell us something? :p |
| 16:30 | rabeeh | well.. the accessories do well on this board; we can test lots of features |
| 16:31 | lubiana | _rmk_, where can i find the cubox-3.11 branch? |
| 16:45 | purch | rabeeh: first upgrade this setup http://www.solid-run.com/phpbb/viewtopic.php?f=4&t=1124 and then start building weather station (vantage vue) with additional one-wire measuring devices and webcams |
| 16:46 | rabeeh | purch: please send me your email address and i will queue you up for next batch |
| 16:46 | rabeeh | my email - [email protected] |
| 16:46 | _rmk_ | first boot of v3.12-rc2... seems to work on the face of it |
| 16:47 | _rmk_ | a number of changes in Armada DRM were needed tho... |
| 16:47 | _rmk_ | drivers/gpu/drm/armada/armada_drv.c | 1 - |
| 16:47 | _rmk_ | 3 files changed, 7 insertions(+), 40 deletions(-) |
| 16:48 | _rmk_ | lubiana: I tend not to publish the tree because no commit in it is particularly "stable" |
| 16:48 | lubiana | ah |
| 16:48 | lubiana | ok |
| 16:49 | _rmk_ | also I'm not entirely convinced that I can publish it with things like the vendor HDMI stuff in it... and there's a few files in the GPU stuff which clearly state that they're not GPL (which I think can be dropped anyway) |
| 16:53 | _rmk_ | hmm |
| 16:55 | purch | rabeeh: done |
| 16:56 | _rmk_ | that's a "something's broken" sort of hmm. |
| 17:08 | _rmk_ | not the kernel's fault |
| 17:18 | _rmk | 17:18 * _rmk_ wonders how many of you are on g+ |
| 17:22 | rabeeh | _rmk_: i am |
| 17:25 | _rmk_ | and I think I've just found you :) |
| 17:25 | _rmk_ | and Sebastian |
| 17:26 | _rmk_ | ah, so Li Li went to Nvidia |
| 17:39 | jnettlet | _rmk_, point me at any files you have concerns about for the Vivante driver, and I will get them verified, or re-licensed. |
| 17:40 | jnettlet | although I would rather just switch to the v4 codebase, to match up Freescale and Marvell versions |
| 17:51 | _rmk_ | jnettlet: when you encounter file headers which say "The material in this file is confidential and contains trade secrets"... |
| 17:51 | _rmk_ | arch/arm/mach-dove/gc600_driver_dove/galcore_ko_src/Android.mk.def |
| 17:51 | _rmk_ | arch/arm/mach-dove/gc600_driver_dove/galcore_ko_src/makefile.linux.def |
| 17:51 | _rmk_ | arch/arm/mach-dove/gc600_driver_dove/galcore_ko_src/hal/makefile.linux |
| 17:51 | _rmk_ | arch/arm/mach-dove/gc600_driver_dove/galcore_ko_src/hal/user/gc_hal_user_context.h |
| 17:51 | _rmk_ | arch/arm/mach-dove/gc600_driver_dove/galcore_ko_src/hal/user/gc_hal_user_precomp.h |
| 17:51 | _rmk_ | arch/arm/mach-dove/gc600_driver_dove/galcore_ko_src/hal/user/gcProfiler.h |
| 17:52 | _rmk_ | arch/arm/mach-dove/gc600_driver_dove/galcore_ko_src/hal/user/gc_hal_user_brush.h |
| 17:52 | _rmk_ | arch/arm/mach-dove/gc600_driver_dove/galcore_ko_src/hal/user/gc_hal_user_compiler.h |
| 17:52 | _rmk_ | arch/arm/mach-dove/gc600_driver_dove/galcore_ko_src/hal/user/gc_hal_user.h |
| 17:52 | _rmk_ | I suspect several of those should not be there |
| 17:58 | wumpus | _rmk_: yes, there is a lot of user-space only stuff in the kernel drivers, especially the dove ones |
| 17:59 | wumpus | we could cut thousands of lines from the vivante (v4) kernel driver for ingenic |
| 17:59 | wumpus | but the dove one is worse and even has some interface headers for the GAL user space |
| 18:00 | wumpus | which, I suppose, can be useful for interested parties but don't belong in the kernel |
| 18:03 | jnettlet | _rmk_, yes the user directory doesn't belong there |
| 18:04 | jnettlet | wumpus, unfortunately in v4 gc_hal_kernel_context.c is licensed the same and links to those files. |
| 18:04 | wumpus | ugh |
| 18:05 | wumpus | another reason to start a more linuxish kernel driver from scratch I guess |
| 18:06 | wumpus | we'd hope to get there with a cut and replace approach, but if licenses for necessary files are messed up too... |
| 18:07 | wumpus | jnettlet: I just checked gc_hal_kernel_context.c and gc_hal_kernel_context.h in v4 in etna_viv/kernel_drivers and they're GPL licensed |
| 18:08 | jnettlet | wumpus, yep. I think the last commit that Vivante/Marvell sent me had the licensing changed. |
| 18:08 | jnettlet | what a clusterf*** |
| 18:08 | wumpus | indeed... |
| 18:08 | wumpus | also the way in which they mix up kernel space and user space structures in their interface, it's terrible |
| 18:09 | jnettlet | okay another reason for us to get on a standard kernel driver |
| 18:09 | jnettlet | don't even get me started |
| 18:09 | wumpus | and putting everything in one ioctl.. whyyy |
| 18:10 | jnettlet | wumpus, okay I will pull down those drivers into my kernel then. |
| 18:17 | jnettlet | wumpus, yep the imx6_v4_0_0 drivers are the newest ones and are all GPL. |
| 18:18 | jnettlet | the only question is did they come in the tarball with the README that says that anything included can't be used except on Freescale hardware? |
| 18:19 | jnettlet | Although I don't think they can do that with GPL licensed source. |
| 18:20 | jnettlet | _rmk_, I think we have a properly licensed clean version to work from. |
| 18:21 | dv_ | jnettlet: arent there 4.1.0 ones? |
| 18:21 | jnettlet | dv_, actually 4.6.9 |
| 18:22 | jnettlet | rev 1210 |
| 18:22 | jnettlet | build 1210...sorry |
| 18:25 | wumpus | jnettlet: such restrictions are not permitted on GPL code |
| 18:26 | wumpus | of course you one could add a clause, let's say "it's not allowed to use this in nuclear weapons", but that'd no longer be GPL |
| 18:26 | jnettlet | wumpus, right. so I think that is our "release" version. |
| 19:11 | cbxbiker61 | nvidia to begin publishing open gpu documentation! Finally the big players have all figured out that supporting opensource is the way to go. |
| 19:17 | jnettlet | cbxbiker61, I wonder if that has any correlation with the new Steam Box announcement. |
| 19:19 | cbxbiker61 | i didn't remember that the steam box was using nvidia... but yeah, steambox and amd doing arm64/radeon late next year could be the straw that broke the camel's back |
| 19:58 | purch | anything similar to this https://github.com/RobertCNelson/netinstall for cubox-i? |
| 20:03 | cbxbiker61 | purch, i don't think so, but that is "only" a script and should be pretty easy to enhance to do the job |
| 20:04 | cbxbiker61 | i bookmarked it and I'll have a closer look at it when I get the cubox-i |
| 20:08 | purch | worked like a charm for wandboard quad |
| 20:09 | purch | could be a easy setup for not-so-technical people |
| 20:10 | cbxbiker61 | yeah, running the installer on a non-cubox-i machine should be a lot easier |
| 20:11 | purch | for linux people |
| 20:11 | cbxbiker61 | although i'm pretty sure Rabeeh wants to have a stand-alone installer for the cubox-i just as the regular cubox |
| 20:13 | cbxbiker61 | in fact the idea that he floated a while ago was to have a raw image that could just be dumped to the cubox-i, and then the main partition could be resized |
| 20:14 | purch | one thing was in mind that a similar netinstaller for cubox where could be different kernels |
| 20:14 | cbxbiker61 | that is a problem for me at the moment since i intend to have the main partition as f2fs and f2fs doesn't have a partition resize tool yet |
| 20:14 | purch | what's that? |
| 20:14 | jnettle | 20:14 * jnettlet shakes fist at samsung for its lack of resize tool |
| 20:14 | cbxbiker61 | flash-friendly file system |
| 20:15 | purch | had to google it |
| 20:15 | purch | have to look more to it |
| 20:15 | cbxbiker61 | i've been tweeking my systems to run f2fs root filesystems, just finished doing a fresh install to my x86_64 media system |
| 20:16 | cbxbiker61 | certain packages need a bit of tweeking the get the mount options correct, i.e. the kernel and systemd |
| 20:17 | purch | ubuntu supports that? |
| 20:17 | cbxbiker61 | not sure |
| 20:17 | jnettlet | I doubt it. |
| 20:17 | cbxbiker61 | i started working with it as soon as it entered the kernel |
| 20:18 | jnettlet | well the driver has been in mainline since 3.8. I believe you need a separate ppa for the tools |
| 20:19 | purch | https://launchpad.net/ubuntu/+source/f2fs-tools |
| 20:21 | purch | saucy should support it properly, so few months |
| 20:29 | _rmk_ | http://ftp.arm.linux.org.uk/cgit/linux-cubox.git/ |
| 20:33 | cbxbiker61 | _rmk_ , good stuff |
| 20:34 | jnettlet | _rmk_, if you want to keep consistent the MMP3 is an Armada 620 |
| 20:37 | jnettle | 20:37 * jnettlet can submit patches. |
| 20:39 | _rmk_ | if you want to send me patches against that for MMP3... |
| 20:40 | _rmk_ | I think cgit will eventually catch up with the repo description... |
| 20:40 | jnettlet | yep can do for mmp2 / mmp3 working on both the last couple of days. |
| 20:41 | _rmk_ | git url would be git://ftp.arm.linux.org.uk/~rmk/linux-cubox.git/ |
| 20:41 | jnettlet | don't know if you care, but I would also suggest renaming the functions to just mmp2...most the graphics drivers just use the oldest most compatible hardware version until a major change is needed. |
| 20:41 | _rmk_ | don't forget the branch name because there's no master on that. :) |
| 20:42 | _rmk_ | don't mind in that commit - I only did it as a "proof of concept" :) |
| 20:42 | _rmk_ | based around what limited info I had from the OLPC response I got from a previous posting |
| 20:42 | jnettlet | okay well I have a bunch of stuff that is just getting shuffled at this point. Will be happy to get things consolidated. |
| 20:43 | _rmk_ | let me know if that git url doesn't work (I've got a weird git daemon setup on that machine) |
| 20:44 | _rmk_ | that machine is also known for not being the fastest too, so make sure you're pulling into a tree which already has mainline rather than cloning from it |
| 20:44 | jnettlet | will do. |
| 20:44 | _rmk_ | (there's been plans to replace the machine for the last year but real life keeps getting in the way for the guy sorting out the new hardware :( |
| 20:45 | jnettlet | I know that song all too well. |
| 20:46 | jnettlet | Do you want patches against the 3.11 or 3.12 branch? or don't you care. |
| 20:47 | _rmk_ | don't care - I'll port them onto both branches |
| 20:47 | _rmk_ | eventually the 3.11 branch will get dropped once 3.12 is out |
| 20:48 | jnettlet | well I will backport to and maintain my 3.10 long-term branch regardless. |
| 20:48 | jnettlet | that should cover the community for now. |
| 20:48 | jnettlet | Now if only my stupid mmp2 board would boot off of device-tree. The world would be cozy |
| 20:50 | jnettlet | rabeeh, just got my notificaiton from DHL, they are right on things. |
| 20:51 | _rmk_ | jnettlet: is that the notification of the tracking no? |
| 20:51 | jnettlet | _rmk_, notification of MOMs payment for the delivery. |
| 20:53 | _rmk_ | ah, cgit now has the description on the repo specific page but not the main index yet |
| 20:53 | jnettlet | which reminds me. rabeeh if your shipping people clearly state that the shipment is an Engineering hardware sample not for resale it should allow delivery without additional duty/Vat/Moms etc. |
| 20:56 | jnettlet | _rmk_, will you take a patch to add the GPL licensed vivante driver into the tree? |
| 21:00 | _rmk_ | well, I'd need to work out what to do about the 85 or so galcore patches I have here... |
| 21:01 | _rmk_ | I've been gradually pushing the "update" I did over Rabeeh's version down through my mass of patches over the last month as and when |
| 21:04 | jnettlet | hmmm, merging that into the new driver codebase will be not fun. |
| 21:06 | _rmk_ | indeed |
| 21:07 | _rmk_ | and I kind of wish I hadn't run hal/os/linux/kernel/*.[ch] through indent early on in the series :p |
| 21:07 | jnettlet | actually I did that before every rebase. The code is too messy otherwise. |
| 21:09 | _rmk_ | and I should send you my perl script which deobfuscates the hardware file a bit |
| 21:09 | _rmk_ | though I'm not sure vivante would like that |
| 21:10 | jnettlet | it is GPL...too late. |
| 21:10 | jnettlet | :-P |
| 21:10 | _rmk_ | quite true, but gotta play nice so they keep giving code updates |
| 21:11 | jnettlet | I am still working on getting a contact within Vivante. |
| 21:11 | jnettlet | It is on an agenda somewhere in SanFran |
| 21:12 | jnettlet | well bringing it up internally is. |
| 21:13 | jnettlet | Probably best to leave the code as is for the in kernel driver, and pass the perl script over to wumpus to host as part of etnaviv. They already can't like what he is doing. |
| 21:13 | jnettlet | Good cop bad cop |
| 21:15 | _rmk_ | :) |
| 21:15 | jnettle | 21:15 * jnettlet goes in search of food. |
| 21:19 | wumpus | I don't think they care about a deobfuscation script; it appears they run the source through macro expansion to get rid of the register names, not so much to intentionally obfuscate it |
| 21:21 | wumpus | the a:b stuff is a fairly standard way of defining bit ranges, they did it at nvidia too, it's just that it looks obfuscated when expanded |
| 21:22 | _rmk_ | the simple version is this: |
| 21:22 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/misc/deobfuscate-simple-vivante.pl |
| 21:23 | _rmk_ | you can go a little further but it requires effort in defining some register definitions ourselves |
| 21:25 | wumpus | yep, in principle I could use the register definitions from etnaviv, but this is a good start |
| 21:51 | _rmk_ | wumpus: I do have a more complex version of that script |
| 21:52 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/misc/deobfuscate-complex-vivante.pl |
| 21:56 | purch | huh, who writes those? |
| 21:57 | _rmk_ | me |
| 22:00 | purch | too many dollar signs and back slashes for my eyes |
| 22:01 | _rmk_ | that's the side effect of perl. you should see some of my sed scripts :) |
| 22:02 | purch | not after that please =) |
| 22:04 | purch | I grew out of those sed, bash, awk stuff and happily living in python land atm |
| 22:04 | wumpus | well it's not that bad as far as perl code goes :) |
| 22:05 | _rmk_ | s,',',g;s,",",g;s,^\s\s*,,;s,<\(div[^>]*\|/div\)>,,g;/^/ { x;/./s/\n/\t/gp;x;s/^.*data-thing-id="\(.*\)">/\1/;h;d; }; /^/ { /data-column-key="[12]"/ { s/^[^>]*>//; H; }; /data-column-key="4".*href=.*mp3/ { s/^.*/@AUDIO@/;H; }; d; }; /^/ { s/^[^>]*>//;H;s/.*//;x;s/\n/\t/gp; }; |
| 22:06 | _rmk_ | you might mistake that for line noise :) |
| 22:07 | dv_ | _rmk_: check out the regex for validating email addresses: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html |
| 22:07 | _rmk_ | :) |
| 22:08 | _rmk_ | I've written one for URLs from the RFCs, I did it in perl and defined each bit separately |
| 22:08 | dv_ | and its not complete |
| 22:08 | dv_ | because email addresses can contain comments |
| 22:08 | dv_ | abc(this is a comment)@def.com |
| 22:09 | _rmk_ | yep. :) |
| 22:09 | dv_ | and since you can have nested brackets, this is no longer a regular grammar |
| 22:10 | _rmk_ | yep, mine was just for http, https, mailto and ftp uris |
| 22:10 | _rmk_ | and missed a few things |
| 22:10 | dv_ | one huge regex is uncommon anyway |
| 22:10 | dv_ | most people use several small ones instead |
| 22:10 | dv_ | more efficient, and causes less headache |
| 22:11 | purch | for email: [^@]+@[^@]+\.[^@]+ |
| 22:11 | dv_ | purch: see my link :) |
| 22:11 | _rmk_ | I just went through RFC2396 for mine and created one line of perl for each bit of BNF :) |
| 22:12 | dv_ | surprisingly, URIs are easier to parse than email addresses |
| 22:13 | dv_ | also, yay! my chromium patches for html5 video using the imx vpu work |
| 22:14 | dv_ | fortunately, the chromium media framework does not expect slices |
| 22:15 | _rmk_ | purch: I assume you've heard that some people describe perl as "write only code" ? |
| 22:15 | dv_ | I read once that a peculiarity of perl code is that it looks the same before and after encryption :) |
| 22:16 | purch | _rmk_: I once had to edit perl script, never again |
| 22:16 | purch | dv_: hehe |
| 22:18 | _rmk_ | dv_: ah, you had the perl decryption engine fitted to your brain then, which transparently kicks in when you see encrypted perl code :) |
| 22:19 | dv_ | like the translator microbes in doctor who |
| 22:20 | purch | The Big Bang Theory now and some sleep ::wave |
| 22:20 | _rmk_ | cu |