From: Oliver McFadden <oliver.mcfadden@nokia.com>
To: "Vignatti Tiago (Nokia-D/Helsinki)" <tiago.vignatti@nokia.com>
Cc: "X.OrgD" <"evel List xorg-devel"@lists.freedesktop.org>,
"dri-devel@lists.sf.net" <dri-devel@lists.sf.net>
Subject: Re: RFC: xfree: dri2: libdrm as optional
Date: Tue, 19 Jan 2010 21:24:27 +0200 [thread overview]
Message-ID: <1263929067.29138.29.camel@debian> (raw)
In-Reply-To: <20100119191811.GA10253@cachaca>
On Tue, 2010-01-19 at 20:18 +0100, Vignatti Tiago (Nokia-D/Helsinki)
wrote:
> Some drivers use DRI2 protocol but implement their own kernel rendering
> mananger. For these drivers, libdrm becomes useless.
>
> The only inconvenient right now to put libdrm optional to X server is
> concerning DRI2Authenticate. Such function uses drm_magic_t and drmAuthMagic
> symbols from libdrm. So I thought two alternatives.
>
> 1. wrap with some macros and set at compilation time:
>
> #ifndef WITH_DRM
> typedef unsigned int drm_magic_t;
> #endif
>
> Bool
> DRI2Authenticate(ScreenPtr pScreen, drm_magic_t magic)
> {
> #ifdef WITH_DRM
> DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
>
> if (ds == NULL || drmAuthMagic(ds->fd, magic))
> return FALSE;
>
> return TRUE;
> #else
> return FALSE;
> #endif
> }
>
>
> 2. hide all trickery inside xorg driver, adding a new field to DRI2InfoRec:
>
> Bool
> DRI2Authenticate(ScreenPtr pScreen, unsigned int magic)
> {
> DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
> if (ds == NULL || (*ds->AuthMagic)(ds->fd, magic))
> return FALSE;
>
> return TRUE;
> }
>
>
> In the first alternative the implementation is straightforward but should be
> adjusted at build time. It's ugly. Also, one would want to implement his own
> way of clients authentication, or not (sigh) - note though dri2proto states
> that this is not mandatory:
>
> "A kernel rendering manager can choose not to implement any
> authentication and just allow access to all buffers."
>
> Alternative 2. seems more complete but requires code changes all over the
> drivers. I'm more inclined for this alternative... Moreover, for both
> alternatives we need to do something with drm_magic_t type - can we just use
> unsigned int instead declare such new type?
Does it really matter that we would leave the drm_magic_t typedef
defined? In this case, we would just have one ifdef inside
DRI2Authenticate().
But I agree, moving the auth checking into a function in DRI2InfoRec
might be the nicest solution but harder to get in considering it touches
all the drivers.
> So what you guys think about this all?
>
>
> Thanks,
>
> Tiago
> _______________________________________________
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
next parent reply other threads:[~2010-01-19 19:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100119191811.GA10253@cachaca>
2010-01-19 19:24 ` Oliver McFadden [this message]
2010-01-19 20:44 ` RFC: xfree: dri2: libdrm as optional Kristian Høgsberg
2010-01-19 19:18 Tiago Vignatti
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=1263929067.29138.29.camel@debian \
--to=oliver.mcfadden@nokia.com \
--cc="evel List xorg-devel"@lists.freedesktop.org \
--cc=dri-devel@lists.sf.net \
--cc=tiago.vignatti@nokia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.