Menu
▾
▴
RE: [Linux-fbdev-devel] Making drawing functions available to use rland
|
From: Sottek, M. J <mat...@in...> - 2002-05-30 21:34:55
|
If you expose the basic blit acceleration functions then there shouldn't be any reason not to have the device independent fbdev X driver use them. However, I would stop there. Any function that is not very easily supported by nearly all fb drivers (Basically anything that isn't a blit) should not be used in the fbdev driver. If you want to have a full featured X driver (with Xv etc. ) then you need a device dependent X driver just as you have now. Instead of the device dependent driver touching the hardware directly it would just go through a very thin ioctl (a device dependent one). This is very similar to how the DRI/DRM work. There should not be concern for "locking the kernel" If you can't make the ioctl safe for application use then you shouldn't make it available. Basically there is no good reason you can't make very thin device dependent ioctls that can't be abused. The DRM's do this quite well. During development is the only time when you have a greater risk of hanging the kernel... and that is only slightly more catastrophic than wedging the graphics engine from user-space anyway. -Matt -----Original Message----- From: Antonino Daplas [mailto:ad...@po...] Sent: Friday, May 31, 2002 8:08 PM To: fbdev Subject: [Linux-fbdev-devel] Making drawing functions available to userland Hi again, In my other e-mail, I touched on the possibility of exporting the drawing functions to userspace. Actually, I was delving a little on that. I added 3 IOCTLS (FBIO_DOACCEL, FBIO_GETCAPABILITIES, and FBIOSYNC) to the fb API (2.5.19) whose main functions are to describe the drawing capability of the driver and making them accessible to userland. To test that, I added XAA and DGA to XFree86 fbdev and fbdevhw driver. Here's a part of the XFree86 log: <<< cut >>> (**) FBDEV(0): Enabling Acceleration (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor="The XFree86 Project" compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (II) FBDEV(0): Using fillrect for SolidFill. (II) FBDEV(0): Using copyarea for ScreenToScreenCopy. (II) FBDEV(0): Using imageblit for Mono8x8PatternFill. (II) FBDEV(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Solid Horizontal and Vertical Lines <<< cut >>> I'm not really going to push for this since I already recognize a few difficulties. Firstly, making the drawing functions accessible will increase the likelihood of crashing the kernel. Secondly, people might not remain contented and add more functionality increasing kernel bloat. Anyways, any thoughts on this? Tony --------------------------------------------------------------------- PS: A few benchmarks... XFBDev - no accel ================= 36000 reps @ 0.1407 msec ( 7110.0/sec): 100x100 rectangle 18000 reps @ 0.3206 msec ( 3120.0/sec): 100x100 opaque stippled rectangle (8x8 stipple) 32000 reps @ 0.1713 msec ( 5840.0/sec): Copy 100x100 from window to window XFBDev - accel ============== 144000 reps @ 0.0422 msec ( 23700.0/sec): 100x100 rectangle 18000 reps @ 0.3010 msec ( 3320.0/sec): 100x100 opaque stippled rectangle (8x8 stipple) 80000 reps @ 0.1026 msec ( 9750.0/sec): Copy 100x100 from window to window native i810_drv =============== 144000 reps @ 0.0428 msec ( 23300.0/sec): 100x100 rectangle 144000 reps @ 0.0429 msec ( 23300.0/sec): 100x100 opaque stippled rectangle (8x8 stipple) 80000 reps @ 0.1060 msec ( 9430.0/sec): Copy 100x100 from window to window _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Linux-fbdev-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
