>>> Huh. OK, so all accels now are to be done with driver-specific
>>> ioctls?
>> No in user space
Albert> So why give userspace a framebuffer device at all? The X
Albert> server will need to bang the raw hardware anyway. You could
Albert> have the kernel code just do the /dev/tty* and /dev/vcs*
Albert> devices, without the useless framebuffer ones. Since X needs
Albert> privilege to access the accelerator anyway, it might as well
Albert> just open /dev/mem.
Because you can do other things than running X-servers on a frame
buffer device and because it allows you to use the frame buffer device
to handle things like mode switching.
Albert> That would be less kernel bloat, even for 680x0 systems with a
Albert> console! Really, the framebuffer devices don't give us
Albert> anything useful.
You are obviously missing the whole point of this, or would you mind
sending me a patch which will allow me to run the console on a Sparc,
most m68k boxes & many MIPS, ARM & PPC boxes without setting up the
video resources in the kernel? /dev/fb gives us a standard way of
accessing video cards' memory from user space so we don't need to
reinvent the wheel.
>> 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.
Albert> That isn't safe. You can't expect to access video memory at
Albert> all while the X server is running the accelerator. You may
Albert> crash the card.
fbdev deals with this, and its only a certain number of cards that are
broken..
Albert> You also need to get into a simple video mode before X starts,
Albert> so that the X server knows the video mode. You can't do that
Albert> with VESA.
Or let the X server use the mode information from /dev/fb and use
/dev/fb to set the video modes for it.
Albert> This system just isn't going to cover all PC hardware with
Albert> full acceleration support in userspace. I'm sure it works just
Albert> great on your 680x0 machine, but Linux runs on PC hardware
Albert> too.
Look at the code and features before commenting please.
>> We did not do that on purpose, ioctl == context switch and we don't
>> want that.
Albert> You don't want it, but I do. Access to the X server is alreay
Albert> worse than a context switch -- if you are serious, get rid of
Albert> that.
Oh, you didn't follow the long thread we had about this on
linux-kernel some month ago either?
Albert> The context switches are cheap if you queue a large number of
Albert> requests. (and cheap if you don't have large numbers) It is a
Albert> very small price to pay for a reliable system with decent
Albert> performance.
No its not - and most of the time you can only queue a very low number
of requests because you want to sync the blitter before starting new
requests.
Jes
-
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