So why give userspace a framebuffer device at all? The X server will
need to bang the raw hardware anyway. You could have the kernel code
just do the /dev/tty* and /dev/vcs* devices, without the useless
framebuffer ones. Since X needs privilege to access the accelerator
anyway, it might as well just open /dev/mem.
That would be less kernel bloat, even for 680x0 systems with a console!
Really, the framebuffer devices don't give us anything useful.
> When you want to have accel control in user space, you tell fbdev
> and it wont use acceleration for the console until the user space
> program finishes with it.
That isn't safe. You can't expect to access video memory at all
while the X server is running the accelerator. You may crash the card.
You also need to get into a simple video mode before X starts, so
that the X server knows the video mode. You can't do that with VESA.
This system just isn't going to cover all PC hardware with full
acceleration support in userspace. I'm sure it works just great
on your 680x0 machine, but Linux runs on PC hardware too.
> We did not do that on purpose, ioctl == context switch and we
> don't want that.
You don't want it, but I do. Access to the X server is alreay
worse than a context switch -- if you are serious, get rid of that.
The context switches are cheap if you queue a large number of requests.
(and cheap if you don't have large numbers) It is a very small price
to pay for a reliable system with decent performance.
-
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