Re: sbusfb changes are wrong

From: James Simmons (
Date: Mon May 08 2000 - 10:03:28 EST

> I'm aware of the hardware context these cards possess:) Fork is the
> problem :( Think about the race conditions on SMP machines.
> What race condition? If the processes use the DRM/DRI locking as it's
> supposed to be used to interlock rendering pipeline access, there is
> no problem.

DRI is design for low end hardware. Using DRI with high end graphics cards
is like putting training wheels on a porche. Why dumb down good hardware?
Doing so will ensure you will not get maximum performace.

> For DGA, the X server begins using unaccelerated direct framebuffer
> rendering while DGA tasks exist, and the framebuffer is "thread safe"
> insofar as having multiple processes read/write the framebuffer in
> parallel. It is the framebuffer, _not_ the rendering pipeline
> registers that are given to tasks using DGA.

Its not the framebuffer memory itself. Can I not write a userland app that
opens /dev/fb and set the video mode to somthing else. Most low end pci
cards have two apertures. One for big endian and another for little endian.
In 8 bit mode the card will most like use the little endian aperture. So
if you have the X server open /dev/fb and sets the mode via
data to mmap the framebuffer. Then I use my own fbdev program. It calls
FBIOPUT_VSCREENINFO to set it to a 16 bpp mode. This means the aperture
has changed its address this fix->smem_start is invalid. Thus the X
server will be writing to the wrong memory region.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons [] ____/|
fbdev/gfx developer \ o.O| =(_)= U

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:11 EST