Sorry for the top reply, but I couldn't get the formatting right.
Anyway, perhaps we could use the 3d driver name to differenciate
between the drivers: via_dri.so - closed source; unichrome_dri.so -
open source. we could then have the DDX probe for one first then the
other or we could add an option to choose which. That way the DDX
would stay in sync as it gets updated since there'd only be one.
Alex
----- Original Message -----
From: Thomas Hellstrom <[EMAIL PROTECTED]>
Date: Sat, 12 Jun 2004 08:46:53 +0200
Subject: Re: [Unichrome-devel] Re: Via DDX for DRI?
To: Ian Romanick <[EMAIL PROTECTED]>
Cc: DRI developer's list <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Hi!
Ian Romanick wrote:
Thomas
Hellstrom wrote:
Ian Romanick wrote:
Where can I get / how can I build a DDX
driver for the Unichrome chipset that will work with the DRI drivers?
I tried just pulling the code from unichorme.sf.net's xfree86 module
into xc/programs/Xserver/hw/xfree86/drivers/via in my DRI tree. I
couldn't get that to build even after fixing the types that we've
removed (i.e., drmHandle, drmContext, etc.).
Is there any chance the folks behind unichrome.sf.net could put
something in the DRI tree? :) I want to do some work on the
client-side 3D driver, but I need a DRI enabled DDX driver to do it.
I'd *much* prefer buildable source over a binary because I think I may
have to change some stuff in it. For example, the code that creates
GLXvisuals in via_dri.c looks wrong.
Not long ago I made a small patch to the dri (xc) tree that made the
via client side driver in Mesa build as via_dri.so, and it sort of
worked. Glxgears and chromium ran fine, but more complicated things
did not; Tuxracer resulted in a blank white screen; in the end, VIA's
binary driver worked much better.
I eventually used an Xorg build with the 3D driver from the Mesa tree.
I saw most of what you're talking about. :)
I think I would actually prefer it if the 3D were named
unichrome_dri.so and the DDX were changed. The reason being that there
will likely be future "via" chipsets that may share the 2D driver but
not the 3D. The current situation of ati_drv.o and mach64_dri.so,
r128_dri.so, radeon_dri.so, and r200_dri.so shows what I'm talking
about. It would have been really confusing if r128_dri.so had
originally been named ati_dri.so.
Ok. In my pre-sleep hurry last night I checked in a "via" 3d client
subdir that builds in the xc tree, but I could change it to "unichrome"?
Still, presently we cannot easily change that in the _mainstream_
Unichrome (the project) 2d driver since nearly all of our 3D users are
using the binary via_dri.so from VIA (the company). Anyway, I've made a
"devel-dri-branch" of the Unichrome 2d driver, that would compile in
the current dri xc tree, and that would expect a "unichrome_dri.so" 3d
driver.
Is there still ( I discussed this with Alex Deucher a while ago ) an
interest of having a via 2d driver in the dri xc tree?
If so, I could check in the "devel-dri-branch" of the Unichrome (the
project) 2d driver and possibly also the XvMC client lib and have it
synced with the Unichrome project on a (sort-of) regular basis.
Regards
/Thomas
P.S. the lists.sf.net mail servers are presently giving me "connection
refused" so mails will probably get very delayed. D.S.
Now, apparently some type names have changed,
like drmcontext, which probably in the end also affects unichrome's
XvMC dri driver, and the via dri client in Mesa no longer builds in the
xc tree.
Is there a thread that describes the recent changes?
I could try to patch up the unichrome 2d client driver to compile in
the dri xc tree.
There is, but you're best bet is to just look at the diffs between 1.33
and 1.36 of
xc/xc/programs/Xserver/programs/xfree86/os-support/xf86drm.h in the DRI
tree. I used a shell script (which is attached) to do most of the
grunt work. To replace 'drmContextPtr' with 'drm_context_t *' you
would do:
sh ./replace_source_text 'drmContextPtr' 'drm_context_t \*'
It is *VERY* important to do the Ptr version before the non-pointer
version. If you do drmContextPtr first, you'll end up with a bunch of
'drm_context_tPtr' through your source.
Basically, you'll want to do this with the Ptr and non-Ptr versions of
drmHandle, drmContext, drmDrawable, drmMagic, drmContextFlags, and
drmClipRect. There *will* be others in the future, but those are the
only ones for now. We're basically trying to get all the types out of
xf86drm.h (just leaving prototypes).
________________________________
#!/bin/sh
old=$1
new=$2
if [ "$old" = "" -o "$new" = "" ]; then
echo Silly rabbit!
exit 1
fi
grep -lr $old . | while read i
do
expr='s/'$old'/'$new'/g'
sed "$expr" < $i > x
mv x $i
done
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
