Hi Tobias, On 22/03/15 16:29, Tobias Jakobi wrote:
Hello Emil, Emil Velikov wrote:
I fear we are not (yet) allowed to do either of these changes.
The exynos/exynos_drm.h header is (supposed to) be in sync/come from the kernel. And changes here are to be reflected only when the corresponding patch lands in drm-next (as per RELEASING).
the point here is, that the current header in libdrm in _not_ in sync with the one in the kernel. It's hopelessly outdated, but mainly because exynos/libdrm doesn't use any new functionality provided by some update.
Here's the current kernel header: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/in...
The event stuff has been there since 2012: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/...
The only reason why I haven't added the IPP things, is because I don't intend to work on this for the moment.
Hmmm good point. Seems like the changes went in before I started following exynos development. If it's in an upstream kernel, then it's save to land in libdrm. Objection withdrawn.
I have an idea how we can get things back into shape (wrt headers being out if sync) - I will propose/post a solution shortly.
Wrt extending the current drmEventContext, I'm not sure that adding device specific changes to it are allowed.
Why shouldn't it? Isn't drmHandleEvent supposed to handle all kinds of DRM events that the kernel produces?
Bth I'm not familiar with the code in question, although a quick grep indicates that libdrm does not contain any driver specific information. That is aside from the include/drm headers, although they are not part of the library or its interface.
Maybe some of the more experienced devs can share some light ?
Thanks Emil