**** BEGIN LOGGING AT Wed Mar 01 03:00:03 2017 Mar 01 08:54:22 it's kinda creepy how low all voltages on the omap5 are compared to e.g. the am335x Mar 01 08:56:09 low voltages are creepy? =) Mar 01 08:58:58 tomba: I'm used to seeing 1.1V nominal, 0.9V retention for most things Mar 01 08:59:26 so yeah, seeing 0.85 V @ 500 MHz feels creepy to me Mar 01 08:59:27 :P Mar 01 08:59:42 =) Mar 01 08:59:52 1.05 V @ 1 GHz Mar 01 09:00:13 am335x requires 1.35 V for 1 GHz Mar 01 09:00:30 that's a pretty big difference Mar 01 09:02:33 tomba: btw, is it just me or is dma-buf export of tiler buffers horribly broken? Mar 01 09:03:14 tiler 2d buffers? Mar 01 09:03:29 or DMM buffers in general? Mar 01 09:04:12 2d yes Mar 01 09:04:45 it seems the export should provide a sg-list with one element per line in that case Mar 01 09:04:52 it's very well possible it is horribly broken. we don't support it and don't test it. Mar 01 09:05:43 without it you can't get sgx to render into a tiler framebuffer for example Mar 01 09:05:45 but we'll be looking at tiler 2d in near future, so thanks for pointing it out =) I'll add a note. Mar 01 09:06:22 and if you do have (hack) patches, feel free to mail me Mar 01 09:07:16 of course it would probably be better to have sgx do rotation itself, there's support for that in the WSEGL layer. unfortunately however it seems unused by TI's userspace libs for sgx, so right now the mere fact this feature exists isn't terribly helpful Mar 01 09:08:59 the WSEGL layer is simple enough though that I may try to make an open source version of e.g. libpvrDRMWSEGL one day... I already have headers for both the interfaces it uses and the interface it provides, and a pretty decent idea of what it does, but that's still further down the horizon Mar 01 09:09:34 hmm how would the user use the rotation from wsegl? Mar 01 09:10:25 those interfaces, are they open source? I think I looked at some point if it would be possible to make open source WSEGL plugings, but I came to the conclusion that it's not possible Mar 01 09:11:43 I have dual MIT/GPLv2 licensed headers for both services (libsrv_um) and WSEGL version 4 Mar 01 09:12:27 I've been working on cleaning them up a bit and adding comments Mar 01 09:13:20 and I'm not sure what the best way to control the rotation would be. in a system with compositor/display manager like wayland it would presumably come from there Mar 01 09:13:37 really? where did you get those =). I only have strictly confidential headers. Mar 01 09:13:44 one way or the other, WSEGL needs to return the rotation from certain calls Mar 01 09:14:04 the GL layer will then apply that rotation Mar 01 09:14:21 not sure, I think one of your (TI's) sdks Mar 01 09:14:29 and/or The Internet Mar 01 09:14:29 yeah, I don't quite get the rotation support there... I mean, just render in rotated orientation. That's what SGX is made to do. Why have separate rotation support... Mar 01 09:14:55 it will render in rotated orientation, the point is that the caller doesn't need to know about this Mar 01 09:15:00 ok... well, be careful if they came from the Internet. some wise guy could have just changed the header. Mar 01 09:16:00 right, but what's the point? it sounds to me that will make things just more complicated. Mar 01 09:16:45 if you use GLES, you have to deal with coordinates etc anyway. and the display is still in a certain orientation, so if you do other stuff like drm planes, DSP, whatever, you then have another orientation than SGX Mar 01 09:17:29 the point is that dealing with drm may be done by different code than the client application... you don't want to have to change every program to support rotation Mar 01 09:17:41 and it seems I got the headers from TI SDKs Mar 01 09:19:38 wsegl.h v4 is in the TI Graphics SDK 5.01.01.02 Mar 01 09:21:04 ok... Well, I think you usually have some kind of compositor, which is the one dealing with DRM. that compositor can rotate the application buffers when compositing. Mar 01 09:21:29 GPL-licensed services.h and servicesext.h are in many places, while dual MIT/GPL licensed versions can be found e.g. in the rowboat-hardware-ti-sgx tree Mar 01 09:21:31 so probably there are use cases for the rotation, but maybe not that many. which could be the reason it's not implemented. Mar 01 09:21:39 not in case of full-screen Mar 01 09:22:37 good point Mar 01 09:23:07 full-screen rotated graphics is obviously an important use case for the pyra :) Mar 01 09:23:32 umm, wouldn't the compositor take care of the display rotation? Mar 01 09:23:43 I need to ask about the WSEGL rotation from our gfx guys Mar 01 09:25:45 tomba: even when windowed, there are clever compositor optimizations that would also need the client to render in correct orientation, e.g. composite the screen just once, then use hw compositing in dss to combine that static image with the changing 3d content in a window Mar 01 09:25:53 zmatt: in my repo, I can only see GPL/MIT on the kernel driver side Mar 01 09:26:24 is that header actually different? (i.e. did they really use the same header name with different contents? that would be annoying...) Mar 01 09:27:43 * KotH hands zmatt a piece of chocolate Mar 01 09:28:21 it looks to me like the same interface is used in both kernel and userspace? i.e. libsrv_um acts like a kind of RPC from userspace to kernel driver Mar 01 09:29:58 because those functions I see declared in the kernel header also exist as symbols in libsrv_um Mar 01 09:29:59 zmatt: which one? services.h seems to be about identical. but, for example, wsegl.h is only on the userspace side. and at least my DRI3 wsegl includes files that are only on the userspace side. Mar 01 09:30:12 yeah I was talking about services Mar 01 09:30:40 I don't think you're able to do a wsegl with just that Mar 01 09:30:58 no, but you should with that + wsegl.h, which I also have Mar 01 09:31:16 there's include/wsegl/wsegl.h in the graphics SDK Mar 01 09:31:50 ok... interesting that the headers and their licenses are so different =) Mar 01 09:33:10 but looking at wsegl.h, it doesn't contain much. I think you have to use PVR's internal funcs to do stuff. at least my DRI3 code does that. possibly there are ways around it, I don' tknow. Mar 01 09:34:18 libpvrDRMWSEGL and libpvrGBMWSEGL don't seem to rely on much Mar 01 09:34:57 a handful of calls from libsrv_um, some libdrm calls, this weird libdbm which seems to be a reinvention of libgbm Mar 01 09:35:56 I'm not saying it will be easy with the info I have right now, but it looks like it might be quite doable Mar 01 09:36:19 it's not on the top of the priority list anyhow Mar 01 09:36:48 but the alternative (without modifying end applications) is letting sgx render into a tiler buffer Mar 01 09:36:52 and that means dma-buf export Mar 01 09:36:57 which is currently broken :) Mar 01 09:37:17 afk, I'll be back a bit later Mar 01 09:37:29 probably a lot easier to fix that though than recreating a WSEGL lib Mar 01 09:37:34 yeah I kinda have to do stuff too Mar 01 09:45:25 thinkfat: sorry I skipped over your question, I hope you picked up on the fact that it was implicitly answered immediately above and below it :) Mar 01 09:47:39 zmatt: yup Mar 01 10:03:10 zmatt: it'd be great if we had the needed interfaces public. my DRI3 wsegl doesn't use much from SGX, and is much simpler than the DRI2 solution. if I could publish that, then, with etnaviv, we have everything needed in open to get fully accelerated 2D + 3D on X11. Mar 01 10:05:09 tomba: be sure to check the graphics sdk ( http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html ) Mar 01 10:07:11 tomba: that's been the most essential source, since it's the only place I found the (MIT/GPLv2) wsegl v4 header... other places only had v2 Mar 01 10:10:45 ok, I'm gonna catch a train, bbl Mar 01 16:04:35 hi, everyone Mar 01 16:05:13 anybody help me for this error: "dpkg-source: error: unrecognized file for a v2.0 source package"? Mar 01 16:06:45 I build kernel, and I have files: *.dsc, *.orig.tar.gz, *.debian.tar.gz Mar 01 16:07:06 Just don't know how install these files. Mar 01 18:05:22 Hello People Mar 01 20:27:42 Hi all :) Mar 01 20:27:58 Hi ubap, how are you? Mar 01 20:28:18 ubap: ^^ Mar 01 20:30:47 Hi im fine. Thanks. How is the hacking going?? Mar 01 20:33:58 ubap: Unfortunately nothing interesting Mar 02 01:30:21 We are trying to get analog inputs running under node.js Mar 02 01:31:25 thus far we consistently get 615-619 returned despite the voltage being applied Mar 02 01:32:59 Has anyone gotten this to work ? Mar 02 01:47:08 Anyone know if there should be 1.8V present on VDD_ADC on the BBB? Mar 02 01:48:45 There is not in our case which makes me suspect the LDO3 on the TPS65217C is not being enabled **** ENDING LOGGING AT Thu Mar 02 03:00:01 2017