[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
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
[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
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
[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
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
[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
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
> wrote:
>> This event is specific to Exynos G2D DRM driver. Only
>> process it when Exynos support is enabled.
>>
>> Signed-off-by: Tobias Jakobi
>> ---
>> 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 0x8000
>> +
>> +struct drm_exynos_g2d_event {
>> + struct drm_eventbase;
>> + __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
>> #include
>>
>> +#ifdef HAVE_EXYNOS
>> +#include
>> +#endif
>> +
>> #ifdef HAVE_VALGRIND
>> #include
>> #include
>> @@ -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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
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
wrote:
> This event is specific to Exynos G2D DRM driver. Only
> process it when Exynos support is enabled.
>
> Signed-off-by: Tobias Jakobi
> ---
> 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 0x8000
> +
> +struct drm_exynos_g2d_event {
> + struct drm_eventbase;
> + __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
> #include
>
> +#ifdef HAVE_EXYNOS
> +#include
> +#endif
> +
> #ifdef HAVE_VALGRIND
> #include
> #include
> @@ -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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
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
[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
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
[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
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 > --- > 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
[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
This event is specific to Exynos G2D DRM driver. Only
process it when Exynos support is enabled.
Signed-off-by: Tobias Jakobi
---
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 0x8000
+
+struct drm_exynos_g2d_event {
+ struct drm_eventbase;
+ __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
#include
+#ifdef HAVE_EXYNOS
+#include
+#endif
+
#ifdef HAVE_VALGRIND
#include
#include
@@ -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
