06:30 suyashsingh234: hello
10:53 ernstp: I can't verify the libdrm_2.4.102.orig.tar.xz.sig ...
11:12 ernstp: airlied: I found a key on keys.openpgp.org ... but it's not really working:
11:12 ernstp: LC_ALL=C gpg --import ~/Hämtningar/10A6D91DA1B05BD29F6DEBAC0C74F35979C486BE.asc
11:12 ernstp: gpg: key 0C74F35979C486BE: new key but contains no user ID - skipped
12:27 sravn: danvet: could you take a quick look at "drm: hold gem reference until object is no longer accessed". I am pretty surte my analysis is correct but would like someone that knows this stuff to comment on it. And you did some locking update some time ago in this code
12:31 danvet: sravn, that locked is dropped in drm_gem_handle_create_tail
12:31 danvet: and I'm fairly sure I've seen this patch already somewhere ...
12:35 eric_engestrom: ernstp: airlied's key look like this to me: https://git.io/JJcTQ
13:40 sravn: danvet: I did not see it applied. Neither in drm-misc-misc not in upstream. Did not check drm-misc-fixes as I am in the middle of a rebase
13:41 sravn: Replyed to the mail now, hope to see a v2
13:41 danvet: I mean it looks familiar, so maybe just a patch that flew by or so
16:32 robclark: mareko: I guess you didn't get as far as trying to do a deqp run on int16? It's pretty grim..
18:45 Putti: daniels, you know what, xexaxo1 created a patch last november to drm_ioctl.c which allows using DRM_IOCTL_PRIME_HANDLE_TO_FD withouth drm magic authentication/root. So our issues with using card0 on both gbm_gralloc and drm_hwcomposer were because gbm_gralloc started first in aosp and open() to card means you get automatically DRM master priveleges... So what we need to do is just keep the gbm_gralloc service disabled until drm_hwcomposer is started.
18:45 Putti: Now I think we need to spread this info to everybody since people have been doing kernel hacks to bypass this when there was no need in the first place (well the need was there until last november).
18:47 Putti: I still have to research if kernel has option to not grant DRM master on open(), that would be nice so extra logic would not be needed in userspace
18:50 bnieuwenhuizen: Putti: wouldn't it be better to use renderD128 if you don't need master?
18:50 Putti: bnieuwenhuizen, render node cannot allocate SCANOUT buffers
18:51 Putti: on this platform (exynos4412) at least
18:52 Putti: and what we learned it would be best to allocate the buffers that will be displayed on with the driver that handles the display, since then the alignment and everything will be correct.
18:53 Putti: bnieuwenhuizen, kmsro driver in mesa actually handles the allocation in the render node if it is not needed to be done in the master node