RFC: xfree: dri2: libdrm as optional

RFC: xfree: dri2: libdrm as optional

[Tiago Vignatti]

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?

So what you guys think about this all?


Thanks,

            Tiago

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

Re: RFC: xfree: dri2: libdrm as optional

[Oliver McFadden]

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

Re: RFC: xfree: dri2: libdrm as optional

[Kristian Høgsberg]

On Tue, Jan 19, 2010 at 2:18 PM, Tiago Vignatti
<tiago.vignatti@nokia.com> wrote:
> Some drivers use DRI2 protocol but implement their own kernel rendering
> mananger. For these drivers, libdrm becomes useless.

Yeah, I think this could be ok.  The drm usage in DRI2 does stick out
a bit, and should probably be pushed to the driver.  I'm just really
curious what memory manager you're using :)

> 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;
>    }

It would have to be this alternative, except it break backwards
compatibility, since if a drivers doesn't implement the new AuthMagic
hook, the clients wont be authenticated.  Maybe we could add a
./configure option to disable drm usage in DRI2, but default it to
enabled.  Then DRI2 should fail to initialize if it doesn't have
either the current drm call or the hook and if it has both prefer the
new hook.

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

We can use either CARD32 or uint32_t, but probably uint32_t.

cheers,
Kristian

------------------------------------------------------------------------------
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
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel