> On Thu, 13 Aug 1998, Ian Collier wrote:
>
> > So you end up with a module that creates a /dev/Xgraphics device
> > [using the gift of dev_fs (-: ] which does all your mode switches.
> > The X server opens this device and instructs it to change modes,
> > do some acceleration, whatever.
>
> Yes, that's stable[1] and secure, but the overhead of a kernel trap for
> each acceleration command would make it very slow compared with the
> current XFrees.
If you want to fix this, you need to start looking at ways to
queue up the accel commands and drain the whole queue with one context
switch. You could drain the queue every vblank. This is yet another item
on the GGI to-do list....
> And allowing userspace access to mmio registers is not an option, because
> for many, if not most, PC (and - thanks to the wonders of PCI - Alpha,
> PPC, etc) video cards, unless the kernel traps and emulates all of these
> accesses (even worse), there is no way that it can restore a sane state.
Correct.
> Only on low-end (dumb framebuffer) or high-end (context-enabled card)
> hardware is this an option, and those cases are the ones which the
> current situation works well for...
Direct userspace access to MMIO registers *is* the best thing to
do, but only if it is safe. On most PC video cards it is not. If you
haven't already, check out http://www.linas.org/linux/graphics.html for s
discussion on how to properly design video hardware. If all video
hardware was designed like this, KGI would be a nonissue.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html