diff mbox

[2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent

Message ID 1426890348-12807-3-git-send-email-tjakobi@math.uni-bielefeld.de (mailing list archive)
State New, archived
Headers show

Commit Message

Tobias Jakobi March 20, 2015, 10:25 p.m. UTC
This event is specific to Exynos G2D DRM driver. Only
process it when Exynos support is enabled.

Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
---
 exynos/exynos_drm.h | 12 ++++++++++++
 xf86drm.h           |  7 ++++++-
 xf86drmMode.c       | 18 ++++++++++++++++++
 3 files changed, 36 insertions(+), 1 deletion(-)

Comments

Emil Velikov March 22, 2015, 3:41 p.m. UTC | #1
On 20/03/15 22:25, Tobias Jakobi wrote:
> This event is specific to Exynos G2D DRM driver. Only
> process it when Exynos support is enabled.
> 
> Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> ---
>  exynos/exynos_drm.h | 12 ++++++++++++
>  xf86drm.h           |  7 ++++++-
>  xf86drmMode.c       | 18 ++++++++++++++++++
>  3 files changed, 36 insertions(+), 1 deletion(-)
> 
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).

Wrt extending the current drmEventContext, I'm not sure that adding
device specific changes to it are allowed.

Wish I would give you some better news but... I cannot sorry :-\

-Emil

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tobias Jakobi March 22, 2015, 4:29 p.m. UTC | #2
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/include/uapi/drm/exynos_drm.h

The event stuff has been there since 2012:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/drm/exynos_drm.h?id=d7f1642c90ab5eb2d7c48af0581c993094f97e1a

The only reason why I haven't added the IPP things, is because I don't
intend to work on this for the moment.



> 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?


With best wishes,
Tobias

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Emil Velikov March 23, 2015, 11:03 a.m. UTC | #3
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/include/uapi/drm/exynos_drm.h
> 
> The event stuff has been there since 2012:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/drm/exynos_drm.h?id=d7f1642c90ab5eb2d7c48af0581c993094f97e1a
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Clark March 30, 2015, 12:02 a.m. UTC | #4
so, iirc, vmwgfx also has some custom events..  not really sure if
they have their own hand-rolled drmHandleEvent() or if they have
another way of catching those.

Maybe we need some more flexible way to register handlers for driver
custom events?  But everyone adding their own thing to
drmHandleEvent() doesn't really seem so nice..  that said, I'm not
sure how much to care.  If it is just exynos and vmwgfx, then telling
them to use there own version of of drmHandleEvent() might be ok.  But
if driver custom events somehow become more popular, maybe we want a
better solution..

BR,
-R

On Fri, Mar 20, 2015 at 6:25 PM, Tobias Jakobi
<tjakobi@math.uni-bielefeld.de> wrote:
> This event is specific to Exynos G2D DRM driver. Only
> process it when Exynos support is enabled.
>
> Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> ---
>  exynos/exynos_drm.h | 12 ++++++++++++
>  xf86drm.h           |  7 ++++++-
>  xf86drmMode.c       | 18 ++++++++++++++++++
>  3 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
> index 256c02f..c3af0ac 100644
> --- a/exynos/exynos_drm.h
> +++ b/exynos/exynos_drm.h
> @@ -157,4 +157,16 @@ struct drm_exynos_g2d_exec {
>  #define DRM_IOCTL_EXYNOS_G2D_EXEC              DRM_IOWR(DRM_COMMAND_BASE + \
>                 DRM_EXYNOS_G2D_EXEC, struct drm_exynos_g2d_exec)
>
> +/* EXYNOS specific events */
> +#define DRM_EXYNOS_G2D_EVENT           0x80000000
> +
> +struct drm_exynos_g2d_event {
> +       struct drm_event        base;
> +       __u64                           user_data;
> +       __u32                           tv_sec;
> +       __u32                           tv_usec;
> +       __u32                           cmdlist_no;
> +       __u32                           reserved;
> +};
> +
>  #endif
> diff --git a/xf86drm.h b/xf86drm.h
> index 40c55c9..6b1c9b4 100644
> --- a/xf86drm.h
> +++ b/xf86drm.h
> @@ -719,7 +719,7 @@ extern void drmMsg(const char *format, ...) DRM_PRINTFLIKE(1, 2);
>  extern int drmSetMaster(int fd);
>  extern int drmDropMaster(int fd);
>
> -#define DRM_EVENT_CONTEXT_VERSION 2
> +#define DRM_EVENT_CONTEXT_VERSION 3
>
>  typedef struct _drmEventContext {
>
> @@ -739,6 +739,11 @@ typedef struct _drmEventContext {
>                                   unsigned int tv_usec,
>                                   void *user_data);
>
> +       void (*g2d_event_handler)(int fd,
> +                                 unsigned int cmdlist_no,
> +                                 unsigned int tv_sec,
> +                                 unsigned int tv_usec,
> +                                 void *user_data);
>  } drmEventContext, *drmEventContextPtr;
>
>  extern int drmHandleEvent(int fd, drmEventContextPtr evctx);
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 61d5e01..d9f2898 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -53,6 +53,10 @@
>  #include <unistd.h>
>  #include <errno.h>
>
> +#ifdef HAVE_EXYNOS
> +#include <exynos/exynos_drm.h>
> +#endif
> +
>  #ifdef HAVE_VALGRIND
>  #include <valgrind.h>
>  #include <memcheck.h>
> @@ -846,6 +850,7 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
>         int len, i;
>         struct drm_event *e;
>         struct drm_event_vblank *vblank;
> +       struct drm_exynos_g2d_event *g2d;
>
>         /* The DRM read semantics guarantees that we always get only
>          * complete events. */
> @@ -882,6 +887,19 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
>                                                  vblank->tv_usec,
>                                                  U642VOID (vblank->user_data));
>                         break;
> +#ifdef HAVE_EXYNOS
> +               case DRM_EXYNOS_G2D_EVENT:
> +                       if (evctx->version < 3 ||
> +                           evctx->g2d_event_handler == NULL)
> +                               break;
> +                       g2d = (struct drm_exynos_g2d_event *) e;
> +                       evctx->g2d_event_handler(fd,
> +                                                g2d->cmdlist_no,
> +                                                g2d->tv_sec,
> +                                                g2d->tv_usec,
> +                                                U642VOID (g2d->user_data));
> +                       break;
> +#endif
>                 default:
>                         break;
>                 }
> --
> 2.0.5
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tobias Jakobi March 30, 2015, 11:37 a.m. UTC | #5
Hello,


On 2015-03-30 02:02, Rob Clark wrote:
> Maybe we need some more flexible way to register handlers for driver
> custom events?  But everyone adding their own thing to
> drmHandleEvent() doesn't really seem so nice..  that said, I'm not
> sure how much to care.  If it is just exynos and vmwgfx, then telling
> them to use there own version of of drmHandleEvent() might be ok.  But
> if driver custom events somehow become more popular, maybe we want a
> better solution..
I don't like the idea of just copying the current drmHandleEvent() code
and putting it into the exynos code together with the additional switch
cases. It just screams "HACK!" to me.

I'm going to try to come up with a solution where we can at least share
some of the code.

With best wishes,
Tobias


> 
> BR,
> -R
> 
> On Fri, Mar 20, 2015 at 6:25 PM, Tobias Jakobi
> <tjakobi@math.uni-bielefeld.de> wrote:
>> This event is specific to Exynos G2D DRM driver. Only
>> process it when Exynos support is enabled.
>> 
>> Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
>> ---
>>  exynos/exynos_drm.h | 12 ++++++++++++
>>  xf86drm.h           |  7 ++++++-
>>  xf86drmMode.c       | 18 ++++++++++++++++++
>>  3 files changed, 36 insertions(+), 1 deletion(-)
>> 
>> diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
>> index 256c02f..c3af0ac 100644
>> --- a/exynos/exynos_drm.h
>> +++ b/exynos/exynos_drm.h
>> @@ -157,4 +157,16 @@ struct drm_exynos_g2d_exec {
>>  #define DRM_IOCTL_EXYNOS_G2D_EXEC              
>> DRM_IOWR(DRM_COMMAND_BASE + \
>>                 DRM_EXYNOS_G2D_EXEC, struct drm_exynos_g2d_exec)
>> 
>> +/* EXYNOS specific events */
>> +#define DRM_EXYNOS_G2D_EVENT           0x80000000
>> +
>> +struct drm_exynos_g2d_event {
>> +       struct drm_event        base;
>> +       __u64                           user_data;
>> +       __u32                           tv_sec;
>> +       __u32                           tv_usec;
>> +       __u32                           cmdlist_no;
>> +       __u32                           reserved;
>> +};
>> +
>>  #endif
>> diff --git a/xf86drm.h b/xf86drm.h
>> index 40c55c9..6b1c9b4 100644
>> --- a/xf86drm.h
>> +++ b/xf86drm.h
>> @@ -719,7 +719,7 @@ extern void drmMsg(const char *format, ...) 
>> DRM_PRINTFLIKE(1, 2);
>>  extern int drmSetMaster(int fd);
>>  extern int drmDropMaster(int fd);
>> 
>> -#define DRM_EVENT_CONTEXT_VERSION 2
>> +#define DRM_EVENT_CONTEXT_VERSION 3
>> 
>>  typedef struct _drmEventContext {
>> 
>> @@ -739,6 +739,11 @@ typedef struct _drmEventContext {
>>                                   unsigned int tv_usec,
>>                                   void *user_data);
>> 
>> +       void (*g2d_event_handler)(int fd,
>> +                                 unsigned int cmdlist_no,
>> +                                 unsigned int tv_sec,
>> +                                 unsigned int tv_usec,
>> +                                 void *user_data);
>>  } drmEventContext, *drmEventContextPtr;
>> 
>>  extern int drmHandleEvent(int fd, drmEventContextPtr evctx);
>> diff --git a/xf86drmMode.c b/xf86drmMode.c
>> index 61d5e01..d9f2898 100644
>> --- a/xf86drmMode.c
>> +++ b/xf86drmMode.c
>> @@ -53,6 +53,10 @@
>>  #include <unistd.h>
>>  #include <errno.h>
>> 
>> +#ifdef HAVE_EXYNOS
>> +#include <exynos/exynos_drm.h>
>> +#endif
>> +
>>  #ifdef HAVE_VALGRIND
>>  #include <valgrind.h>
>>  #include <memcheck.h>
>> @@ -846,6 +850,7 @@ int drmHandleEvent(int fd, drmEventContextPtr 
>> evctx)
>>         int len, i;
>>         struct drm_event *e;
>>         struct drm_event_vblank *vblank;
>> +       struct drm_exynos_g2d_event *g2d;
>> 
>>         /* The DRM read semantics guarantees that we always get only
>>          * complete events. */
>> @@ -882,6 +887,19 @@ int drmHandleEvent(int fd, drmEventContextPtr 
>> evctx)
>>                                                  vblank->tv_usec,
>>                                                  U642VOID 
>> (vblank->user_data));
>>                         break;
>> +#ifdef HAVE_EXYNOS
>> +               case DRM_EXYNOS_G2D_EVENT:
>> +                       if (evctx->version < 3 ||
>> +                           evctx->g2d_event_handler == NULL)
>> +                               break;
>> +                       g2d = (struct drm_exynos_g2d_event *) e;
>> +                       evctx->g2d_event_handler(fd,
>> +                                                g2d->cmdlist_no,
>> +                                                g2d->tv_sec,
>> +                                                g2d->tv_usec,
>> +                                                U642VOID 
>> (g2d->user_data));
>> +                       break;
>> +#endif
>>                 default:
>>                         break;
>>                 }
>> --
>> 2.0.5
>> 
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tobias Jakobi March 30, 2015, 1:04 p.m. UTC | #6
Hello,

On 2015-03-30 02:02, Rob Clark wrote:
> so, iirc, vmwgfx also has some custom events..  not really sure if
> they have their own hand-rolled drmHandleEvent() or if they have
> another way of catching those.
> 
> Maybe we need some more flexible way to register handlers for driver
> custom events?  But everyone adding their own thing to
> drmHandleEvent() doesn't really seem so nice..  that said, I'm not
> sure how much to care.  If it is just exynos and vmwgfx, then telling
> them to use there own version of of drmHandleEvent() might be ok.  But
> if driver custom events somehow become more popular, maybe we want a
> better solution..

would something like this work for you guys:
https://www.math.uni-bielefeld.de/~tjakobi/archive/0001-custom-events.patch

(this is not compile tested or anything, just a draft)

Basically this introduces drmHandleEvent2, which is drmHandleEvent with 
two additional arguments. The first one being a function pointer through 
which the 'remaining' events (which are not handled by the common code) 
are handled, and some (opaque) pointer to data that the handler might 
need.

In the vendor specific code I then introcuded exynos_handle_event which 
calls dramHandleEvent2 with a properly setup handler. vmwgfx could do 
the same here I guess.

With best wishes,
Tobias

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Emil Velikov April 21, 2015, 6:14 p.m. UTC | #7
Hi Tobias,

On 30/03/15 13:04, Tobias Jakobi wrote:
> Hello,
> 
> On 2015-03-30 02:02, Rob Clark wrote:
>> so, iirc, vmwgfx also has some custom events..  not really sure if
>> they have their own hand-rolled drmHandleEvent() or if they have
>> another way of catching those.
>>
>> Maybe we need some more flexible way to register handlers for driver
>> custom events?  But everyone adding their own thing to
>> drmHandleEvent() doesn't really seem so nice..  that said, I'm not
>> sure how much to care.  If it is just exynos and vmwgfx, then telling
>> them to use there own version of of drmHandleEvent() might be ok.  But
>> if driver custom events somehow become more popular, maybe we want a
>> better solution..
> 
> would something like this work for you guys:
> https://www.math.uni-bielefeld.de/~tjakobi/archive/0001-custom-events.patch
> 
> (this is not compile tested or anything, just a draft)
> 
> Basically this introduces drmHandleEvent2, which is drmHandleEvent with
> two additional arguments. The first one being a function pointer through
> which the 'remaining' events (which are not handled by the common code)
> are handled, and some (opaque) pointer to data that the handler might need.
> 
> In the vendor specific code I then introcuded exynos_handle_event which
> calls dramHandleEvent2 with a properly setup handler. vmwgfx could do
> the same here I guess.
> 
I'm assuming that one of the concerns here is about adding API for a
single (and not so common) user to the core library.

From a quick look at the mesa and xf86-video-vmware I cannot see the
vmwgfx driver using events. It has some definitions in vmwgfx_drm.h but
that's about it.

That aside - the drmHandleEvent2 approach looks like a massive
improvement over the original patch. Personally I do not see any
problems with it and think that it's a good way forward.

Perhaps you can come over to #dri-devel and ping the devs to get some
more feedback. As the topic is not a priority for most of them your
suggestions has mostly gone unnoticed.

Cheers,
Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tobias Jakobi April 23, 2015, 12:04 p.m. UTC | #8
Hello Emil,

On 2015-04-21 20:14, Emil Velikov wrote:
> Hi Tobias,
> 
> On 30/03/15 13:04, Tobias Jakobi wrote:
>> Hello,
>> 
>> On 2015-03-30 02:02, Rob Clark wrote:
>>> so, iirc, vmwgfx also has some custom events..  not really sure if
>>> they have their own hand-rolled drmHandleEvent() or if they have
>>> another way of catching those.
>>> 
>>> Maybe we need some more flexible way to register handlers for driver
>>> custom events?  But everyone adding their own thing to
>>> drmHandleEvent() doesn't really seem so nice..  that said, I'm not
>>> sure how much to care.  If it is just exynos and vmwgfx, then telling
>>> them to use there own version of of drmHandleEvent() might be ok.  
>>> But
>>> if driver custom events somehow become more popular, maybe we want a
>>> better solution..
>> 
>> would something like this work for you guys:
>> https://www.math.uni-bielefeld.de/~tjakobi/archive/0001-custom-events.patch
>> 
>> (this is not compile tested or anything, just a draft)
>> 
>> Basically this introduces drmHandleEvent2, which is drmHandleEvent 
>> with
>> two additional arguments. The first one being a function pointer 
>> through
>> which the 'remaining' events (which are not handled by the common 
>> code)
>> are handled, and some (opaque) pointer to data that the handler might 
>> need.
>> 
>> In the vendor specific code I then introcuded exynos_handle_event 
>> which
>> calls dramHandleEvent2 with a properly setup handler. vmwgfx could do
>> the same here I guess.
>> 
> I'm assuming that one of the concerns here is about adding API for a
> single (and not so common) user to the core library.
> 
> From a quick look at the mesa and xf86-video-vmware I cannot see the
> vmwgfx driver using events. It has some definitions in vmwgfx_drm.h but
> that's about it.
> 
> That aside - the drmHandleEvent2 approach looks like a massive
> improvement over the original patch. Personally I do not see any
> problems with it and think that it's a good way forward.
> 
> Perhaps you can come over to #dri-devel and ping the devs to get some
> more feedback. As the topic is not a priority for most of them your
> suggestions has mostly gone unnoticed.
I'm going to flesh out the non-exynos patches some more before sending 
them to the ML for discussion.


With best wishes,
Tobias

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
index 256c02f..c3af0ac 100644
--- a/exynos/exynos_drm.h
+++ b/exynos/exynos_drm.h
@@ -157,4 +157,16 @@  struct drm_exynos_g2d_exec {
 #define DRM_IOCTL_EXYNOS_G2D_EXEC		DRM_IOWR(DRM_COMMAND_BASE + \
 		DRM_EXYNOS_G2D_EXEC, struct drm_exynos_g2d_exec)
 
+/* EXYNOS specific events */
+#define DRM_EXYNOS_G2D_EVENT		0x80000000
+
+struct drm_exynos_g2d_event {
+	struct drm_event	base;
+	__u64				user_data;
+	__u32				tv_sec;
+	__u32				tv_usec;
+	__u32				cmdlist_no;
+	__u32				reserved;
+};
+
 #endif
diff --git a/xf86drm.h b/xf86drm.h
index 40c55c9..6b1c9b4 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -719,7 +719,7 @@  extern void drmMsg(const char *format, ...) DRM_PRINTFLIKE(1, 2);
 extern int drmSetMaster(int fd);
 extern int drmDropMaster(int fd);
 
-#define DRM_EVENT_CONTEXT_VERSION 2
+#define DRM_EVENT_CONTEXT_VERSION 3
 
 typedef struct _drmEventContext {
 
@@ -739,6 +739,11 @@  typedef struct _drmEventContext {
 				  unsigned int tv_usec,
 				  void *user_data);
 
+	void (*g2d_event_handler)(int fd,
+				  unsigned int cmdlist_no,
+				  unsigned int tv_sec,
+				  unsigned int tv_usec,
+				  void *user_data);
 } drmEventContext, *drmEventContextPtr;
 
 extern int drmHandleEvent(int fd, drmEventContextPtr evctx);
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 61d5e01..d9f2898 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -53,6 +53,10 @@ 
 #include <unistd.h>
 #include <errno.h>
 
+#ifdef HAVE_EXYNOS
+#include <exynos/exynos_drm.h>
+#endif
+
 #ifdef HAVE_VALGRIND
 #include <valgrind.h>
 #include <memcheck.h>
@@ -846,6 +850,7 @@  int drmHandleEvent(int fd, drmEventContextPtr evctx)
 	int len, i;
 	struct drm_event *e;
 	struct drm_event_vblank *vblank;
+	struct drm_exynos_g2d_event *g2d;
 	
 	/* The DRM read semantics guarantees that we always get only
 	 * complete events. */
@@ -882,6 +887,19 @@  int drmHandleEvent(int fd, drmEventContextPtr evctx)
 						 vblank->tv_usec,
 						 U642VOID (vblank->user_data));
 			break;
+#ifdef HAVE_EXYNOS
+		case DRM_EXYNOS_G2D_EVENT:
+			if (evctx->version < 3 ||
+			    evctx->g2d_event_handler == NULL)
+				break;
+			g2d = (struct drm_exynos_g2d_event *) e;
+			evctx->g2d_event_handler(fd,
+						 g2d->cmdlist_no,
+						 g2d->tv_sec,
+						 g2d->tv_usec,
+						 U642VOID (g2d->user_data));
+			break;
+#endif
 		default:
 			break;
 		}