Framebuffer access follows the rules; kernel calls are used to map it into user space. The major violations in X are in PCI bus and graphics chip probing.
If mmapping is okay, then we're still able to touch hardware from user space drivers. I'm fine with that.
I don't see any problem with requiring probing to be handled by a kernel space driver, especially since this isn't done a performance critical times.
BTW, the mesa-solo radeon driver does not map the framebuffer from the driver or user space.
The original radeon Mesa Subset driver that Keith W. wrote didn't have any software fallbacks. If you re-enable a full Mesa driver, I think you'll find it very challenging to support all the necessary software fallbacks without a memory map of the framebuffer...but luckly it doesn't sound like memory mapping the device is a problem.
--
/\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
