DRI extension of xserver

[Rahaman]

Posting it again as the prev post has some problem...

Regs,
Rahaman.


----------------------------------------------------------------------------------------------------------------

Hi,

After getting short reply from one of the developer & after going
through the following link
http://dri.sourceforge.net/doc/drm_low_level.html , i understood that
the XF86 calls are only being made to ensure security. But is it the
only reason OR , there are other reasons too which i am not able to
understand.

Because from whatever code analysis i have done till now, i think if i
exclude the security policy, then i can still call drmCreateContext from
the DRI driver side.I need the fd for the drm device to call
drmCreateContext() and i already have that fd when i opened the drm
device using the Bus id which i got after XF86DRIOpenConnection (refer
to mesa/src/glx/x11/glxext.c : function =>CallCreateNewScreen). Is this
analysis correct?

Can any one please throw some light here?

Regs,
Rahaman.



-----Original Message-----
From: Mustafizur <mustafizur.rahaman at azingo.com>
Reply-To: mustafizur.rahaman at azingo.com
To: mesa3d-dev <mesa3d-dev at lists.sourceforge.net>, xorg at freedesktop.org
Subject: DRI extension of xserver
Date: Tue, 23 Sep 2008 12:36:51 +0530

Hi,

I was investigating the DRI extension API of the xserver & i was
particularly looking into the XF86DRICreateContext API.

As i see when client sends this request to xserver, in response to this
Xserver creates a drm context & pass it to the client.Client then sends
this drm context to the 3D driver which uses this drm context to talk to
the graphics h/w via drm kernel module.

Now, my question is why do i need to create the drm context through
xserver.As my 3D driver also links to libdrm, why can't i create the drm
context from the 3D driver itself?

Regs,
Rahaman. 

_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20080923/c71efb4d/attachment.html>