dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Emil Velikov <emil.l.velikov@gmail.com>
To: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>,
	Rob Clark <robdclark@gmail.com>
Cc: emil.l.velikov@gmail.com,
	"moderated list:ARM/S5P EXYNOS AR..."
	<linux-samsung-soc@vger.kernel.org>,
	dri-devel@lists.freedesktop.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
Date: Tue, 21 Apr 2015 18:14:35 +0000	[thread overview]
Message-ID: <5536938B.8060605@gmail.com> (raw)
In-Reply-To: <9f0f7af7b53d22b2be2dd1b25ebbad56@math.uni-bielefeld.de>

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

  reply	other threads:[~2015-04-21 18:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20 22:25 drm/exynos: add async G2D execution to libdrm Tobias Jakobi
2015-03-20 22:25 ` [PATCH 1/5] tests/exynos: add fimg2d performance analysis Tobias Jakobi
2015-03-22 15:36   ` Emil Velikov
2015-03-22 16:35     ` Tobias Jakobi
2015-03-25 18:27       ` Tobias Jakobi
2015-03-26 15:16         ` Emil Velikov
2015-03-20 22:25 ` [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent Tobias Jakobi
2015-03-22 15:41   ` Emil Velikov
2015-03-22 16:29     ` Tobias Jakobi
2015-03-23 11:03       ` Emil Velikov
2015-03-30  0:02   ` Rob Clark
2015-03-30 11:37     ` Tobias Jakobi
2015-03-30 13:04     ` Tobias Jakobi
2015-04-21 18:14       ` Emil Velikov [this message]
2015-04-23 12:04         ` Tobias Jakobi
2015-03-20 22:25 ` [PATCH 3/5] exynos/fimg2d: add g2d_config_event Tobias Jakobi
2015-03-21 14:03 ` drm/exynos: add async G2D execution to libdrm Tobias Jakobi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5536938B.8060605@gmail.com \
    --to=emil.l.velikov@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=robdclark@gmail.com \
    --cc=thellstrom@vmware.com \
    --cc=tjakobi@math.uni-bielefeld.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox