On Thu, 7 Oct 1999, Marcus Sundberg wrote:
> Ok, stop right here!
>
> We don't need more ioctl() callable accel commands, and if it isn't
> immediately obvious how to generalize an interface it should not be
> generalized at the KGI level.
>
> Once you got the mode-setting working and implemented a few of the
> existing ioctl()s to get a feel for the accelerator you can forget
> about the ioctl() toy. Drivers communicate with LibGGI either through
> direct mapped accel registers, ping-pong buffers, or some other
> optimized method.
1) Last thing I heard on the PP buffers with KGI is that they don't work
(and they still don't work) Segment violations are all I get here.
2) The current IOCTL interface is perfectly mappable to some PP
interface, so why not define one. I bet you can map some PP definitions back
to the IOCTL stuff if you want to, so I don't see what is wrong with it.
3) Many cards are unsafe on the mmapped accelleration registers. I think
that developping a real safe implementation this way can only exist in
your dreams for now. Even the Matrox Milennium (that was said to be able
to do this) has some troubles here.
Jos
