On Tue, 22 Jan 2002, Markus Schaber wrote:
> Hi,
>
> Thomas Steffen wrote:
>
> > > Thank you for this information, so it seems we can't go this way. (I
> > > currently consider it impossible to port the whole XFree86 to our
> > > operating system, as we don't have anything in common with unix like
> > > OSes (and one can consider e. G. OS/2 unix like compared to plurix).
> >
> > You might want to have a look at the Linux kernel framebuffer support.
> > AFAIK the drivers are rather simple, and "down there" it is not very
> > UNIX like either. If you use vesafb, for example, you should be able
> > to use nearly every graphics card with only one driver (assuming you
> > have a PC style BIOS).
>
> We already have working native drivers for VGA, some S3 chips, Vesa
> 1.2/2.0 linear framebuffer and some Radeon chips.
>
> As we have a rather slim API, it is not much work to develop a basic
> driver.
>
> Our problem is that we would like to make use of the acceleration and of
> some 3D functions (using a subset of opengl), and for this we need
> documentation. And as you know, the chipset vendors (especially NVidia
> and ATI) don't like to give any useful documentation to others.
>
> One of our programmers got some Radeon docs by signing about a dozen
> NDAs, but the doc and the example code differed in what they did (and
> both methods failed to initialize the chip), and the precompiled
> examples just didn't work (sudden reboots, freezing the machine,
> displaying crap etc.). He managed to get 2D and 3D acceleration
> nevertheless, but he failed to initialize the T&L engine. And his code
> magically fails on newer revisions of the same Radeon chips. ATI didn't
> even bother to deny his questions, they just moved them to /dev/null...
Same here - with video input as well. After a while I got persuaded they
aren't doing it on purpose it is simply their Windows drivers get the
priority but the chipset is not as well documented as it could be (or
should be).
Despite what Mark says they might be a way out.. I agree that emulating
the entire ABI is not feasible. Furthermore, it might change on
you.. However what you could do is just take chunks of the drivers and
adapt them to your code. This is certainly much easier than writing
one from scratch - and they don't require that much of X
functionality.
Vladimir Dergachev
>
> So this kind of "support" made us thinking about including drivers of
> other operating systems using some glue code.
>
> Markus
>
> --
> "GPL software is not free - the cost is cooperation"
> _______________________________________________
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
>
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
