On Tue, Jan 19, 2010 at 2:18 PM, Tiago Vignatti
<tiago.vigna...@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
_______________________________________________
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to