Re: Accelerated frame buffer functions
Haakon Riiser wrote: [Geert Uytterhoeven] mmap() the MMIO registers to userspace, and program the acceleration engine from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and Mach64) does. Right, this was how I originally intended to do it. The reason why I started to obsess about the accelerated fb_ops functions was that I hoped that, by creating a driver that registered accelerated versions of these functions, other frame buffer-using applications would instantly take advantage of it, requiring no changes in those applications. The only framebuffer interface I know of is the framebuffer console. It uses the fbdev acceleration when writing character strings and scrolling. So if your app writes data on the console and/or scroll regions, then it certainly uses framebuffer acceleration. I thought the frame buffer device was supposed to serve as an an abstraction layer between the graphics card and the application, allowing for 2D acceleration without having to know anything about the underlying hardware. But if no one uses the frame buffer device in this way, I might as well do as you suggest and mmap() the registers to userspace. I believe you also can write a small driver that connects to the framebuffer the same way the fbconsole does. It could then export all the operations so userspace actually can call them. This have the advantage that your app can work on more than just one kind of framebuffer. Perhaps you run on one kind of hardware only today, but who knows what hardware the future will bring? Nice not having to rewrite it all. . . Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
Haakon Riiser wrote: [Geert Uytterhoeven] mmap() the MMIO registers to userspace, and program the acceleration engine from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and Mach64) does. Right, this was how I originally intended to do it. The reason why I started to obsess about the accelerated fb_ops functions was that I hoped that, by creating a driver that registered accelerated versions of these functions, other frame buffer-using applications would instantly take advantage of it, requiring no changes in those applications. The only framebuffer interface I know of is the framebuffer console. It uses the fbdev acceleration when writing character strings and scrolling. So if your app writes data on the console and/or scroll regions, then it certainly uses framebuffer acceleration. I thought the frame buffer device was supposed to serve as an an abstraction layer between the graphics card and the application, allowing for 2D acceleration without having to know anything about the underlying hardware. But if no one uses the frame buffer device in this way, I might as well do as you suggest and mmap() the registers to userspace. I believe you also can write a small driver that connects to the framebuffer the same way the fbconsole does. It could then export all the operations so userspace actually can call them. This have the advantage that your app can work on more than just one kind of framebuffer. Perhaps you run on one kind of hardware only today, but who knows what hardware the future will bring? Nice not having to rewrite it all. . . Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Geert Uytterhoeven] > mmap() the MMIO registers to userspace, and program the > acceleration engine from userspace, like DirectFB (and XF*_FBDev > 3.x for Matrox and Mach64) does. Right, this was how I originally intended to do it. The reason why I started to obsess about the accelerated fb_ops functions was that I hoped that, by creating a driver that registered accelerated versions of these functions, other frame buffer-using applications would instantly take advantage of it, requiring no changes in those applications. I thought the frame buffer device was supposed to serve as an an abstraction layer between the graphics card and the application, allowing for 2D acceleration without having to know anything about the underlying hardware. But if no one uses the frame buffer device in this way, I might as well do as you suggest and mmap() the registers to userspace. Anyway, thanks to everyone who participated in this thread. Even if I didn't get the answers I was hoping for, at least now I can put the matter to rest. -- Haakon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, 2 Feb 2005, Haakon Riiser wrote:
> > On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser
> > <[EMAIL PROTECTED]> wrote:
> >> Thanks for the tip, I hadn't heard about it. I will take a look,
> >> but only to see if it can show me the user space API of /dev/fb.
> >> I don't need a general library that supports a bunch of different
> >> graphics cards. I'm writing my own frame buffer driver for the
> >> GX2 CPU, and I just want to know how to call the various functions
> >> registered in struct fb_ops, so that I can test my code. I mean,
> >> all those functions registered in fb_ops must be accessible
> >> somehow; if they weren't, what purpose would they serve?
> >
> > You should look at writing a DRM driver. DRM implements the kernel
> > interface to get 3D hardware running. It is a fully accelerated driver
> > interface. They are located in drivers/char/drm
>
> Have the standard frame buffer drivers been abandoned, even
> for devices that have no 3D acceleration (like the Geode GX2)?
No.
> GX2 is an integrated CPU/graphics chip for embedded systems.
> We have third party applications that use the framebuffer device,
> and I was hoping to make things faster by writing an accelerated
> driver. The only thing I need answered is how to access fb_ops
> from userspace. If that is impossible because all the framebuffer
> code is leftover junk that no one uses anymore, or even /can/
> use anymore because the userspace interface is gone, please let
> me know now so I don't have to waste any more time.
mmap() the MMIO registers to userspace, and program the acceleration engine
from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and Mach64) does.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
> > You should look at writing a DRM driver. DRM implements the kernel > > interface to get 3D hardware running. It is a fully accelerated driver > > interface. They are located in drivers/char/drm > > Have the standard frame buffer drivers been abandoned, even > for devices that have no 3D acceleration (like the Geode GX2)? No. It is still around. > I took a quick look at the DRM stuff, and it looked like extreme > overkill for what I need, if it even can be used for what I want > to do. At first glance it looked like this is only relevant for > OpenGL/X11 3D-stuff, which I have absolutely no use for. This is usually the case for embedded chips. This is the reason the fbdev userland interface is still around. > GX2 is an integrated CPU/graphics chip for embedded systems. > We have third party applications that use the framebuffer device, > and I was hoping to make things faster by writing an accelerated > driver. The only thing I need answered is how to access fb_ops > from userspace. You can mmap the mmio address space and program the registers yourself. A bonus is the example code is in the driver :-) > If that is impossible because all the framebuffer > code is leftover junk that no one uses anymore, or even /can/ > use anymore because the userspace interface is gone, please let > me know now so I don't have to waste any more time. The userspace interface is still there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
> > Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a > > écrit : > > >> How can I use a frame buffer driver's optimized copyarea, > >> fillrect, blit, etc. from userspace? The only way I've ever > >> seen anyone use the frame buffer device is by mmap()ing it > >> and doing everything manually in the mapped memory. I assume > >> there must be ioctls for accessing the accelerated functions, > >> but after several hours of grepping and googling, I give up. :-( > > > Did you try DirectFB ? > > Thanks for the tip, I hadn't heard about it. I will take a look, > but only to see if it can show me the user space API of /dev/fb. > I don't need a general library that supports a bunch of different > graphics cards. I'm writing my own frame buffer driver for the > GX2 CPU, and I just want to know how to call the various functions > registered in struct fb_ops, so that I can test my code. I mean, > all those functions registered in fb_ops must be accessible > somehow; if they weren't, what purpose would they serve? The reason for the accelerated functions is for the framebuffer console. Drawing pixel by pixel is to slow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Jon Smirl] > On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser > <[EMAIL PROTECTED]> wrote: >> Thanks for the tip, I hadn't heard about it. I will take a look, >> but only to see if it can show me the user space API of /dev/fb. >> I don't need a general library that supports a bunch of different >> graphics cards. I'm writing my own frame buffer driver for the >> GX2 CPU, and I just want to know how to call the various functions >> registered in struct fb_ops, so that I can test my code. I mean, >> all those functions registered in fb_ops must be accessible >> somehow; if they weren't, what purpose would they serve? > > You should look at writing a DRM driver. DRM implements the kernel > interface to get 3D hardware running. It is a fully accelerated driver > interface. They are located in drivers/char/drm Have the standard frame buffer drivers been abandoned, even for devices that have no 3D acceleration (like the Geode GX2)? I took a quick look at the DRM stuff, and it looked like extreme overkill for what I need, if it even can be used for what I want to do. At first glance it looked like this is only relevant for OpenGL/X11 3D-stuff, which I have absolutely no use for. GX2 is an integrated CPU/graphics chip for embedded systems. We have third party applications that use the framebuffer device, and I was hoping to make things faster by writing an accelerated driver. The only thing I need answered is how to access fb_ops from userspace. If that is impossible because all the framebuffer code is leftover junk that no one uses anymore, or even /can/ use anymore because the userspace interface is gone, please let me know now so I don't have to waste any more time. -- Haakon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser <[EMAIL PROTECTED]> wrote: > Thanks for the tip, I hadn't heard about it. I will take a look, > but only to see if it can show me the user space API of /dev/fb. > I don't need a general library that supports a bunch of different > graphics cards. I'm writing my own frame buffer driver for the > GX2 CPU, and I just want to know how to call the various functions > registered in struct fb_ops, so that I can test my code. I mean, > all those functions registered in fb_ops must be accessible > somehow; if they weren't, what purpose would they serve? You should look at writing a DRM driver. DRM implements the kernel interface to get 3D hardware running. It is a fully accelerated driver interface. They are located in drivers/char/drm -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, Feb 02, 2005 at 03:21:55PM +0100, Haakon Riiser wrote: > > X-Windows already does this. > > Yeah, I thought the X11 fbdev driver supported acceleration, but not > according to its manpage: > > fbdev is an Xorg driver for framebuffer devices. This is a > non-accelerated driver [...] Yepp, it would be cool, to move every low level graphical operation to the framebuffer devices ... So no more 'I would like to use framebuffer console _AND_ X at the same time without disturbing each other' problem, and also if X segfaults or such, consolse will not remain in unusable state. Also a solid low level graphical operation layer should provide even 3D acceleration for fbdev capable (but not X!) apps and of course for the X server ... without conflicting each other :) DirectFB seems to be a good idea anyway ... - Gábor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Xavier Bestel] > Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a > écrit : >> How can I use a frame buffer driver's optimized copyarea, >> fillrect, blit, etc. from userspace? The only way I've ever >> seen anyone use the frame buffer device is by mmap()ing it >> and doing everything manually in the mapped memory. I assume >> there must be ioctls for accessing the accelerated functions, >> but after several hours of grepping and googling, I give up. :-( > Did you try DirectFB ? Thanks for the tip, I hadn't heard about it. I will take a look, but only to see if it can show me the user space API of /dev/fb. I don't need a general library that supports a bunch of different graphics cards. I'm writing my own frame buffer driver for the GX2 CPU, and I just want to know how to call the various functions registered in struct fb_ops, so that I can test my code. I mean, all those functions registered in fb_ops must be accessible somehow; if they weren't, what purpose would they serve? -- Haakon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
Le mercredi 02 fÃvrier 2005 Ã 15:21 +0100, Haakon Riiser a Ãcrit : > How can I use a frame buffer driver's optimized copyarea, fillrect, > blit, etc. from userspace? The only way I've ever seen anyone use > the frame buffer device is by mmap()ing it and doing everything > manually in the mapped memory. I assume there must be ioctls for > accessing the accelerated functions, but after several hours of > grepping and googling, I give up. :-( Did you try DirectFB ? Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Dick Johnson] > On Wed, 2 Feb 2005, Haakon Riiser wrote: > >> How can I use a frame buffer driver's optimized copyarea, fillrect, >> blit, etc. from userspace? The only way I've ever seen anyone use >> the frame buffer device is by mmap()ing it and doing everything >> manually in the mapped memory. I assume there must be ioctls for >> accessing the accelerated functions, but after several hours of >> grepping and googling, I give up. :-( > > X-Windows already does this. Yeah, I thought the X11 fbdev driver supported acceleration, but not according to its manpage: fbdev is an Xorg driver for framebuffer devices. This is a non-accelerated driver [...] -- Haakon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, 2 Feb 2005, Haakon Riiser wrote: How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Any help is greatly appreciated! X-Windows already does this. Execute `/usr/bin/X11/x11perf -all` to watch. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, 2 Feb 2005, Haakon Riiser wrote: How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Any help is greatly appreciated! X-Windows already does this. Execute `/usr/bin/X11/x11perf -all` to watch. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Dick Johnson] On Wed, 2 Feb 2005, Haakon Riiser wrote: How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( X-Windows already does this. Yeah, I thought the X11 fbdev driver supported acceleration, but not according to its manpage: fbdev is an Xorg driver for framebuffer devices. This is a non-accelerated driver [...] -- Haakon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
Le mercredi 02 fvrier 2005 15:21 +0100, Haakon Riiser a crit : How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Did you try DirectFB ? Xav - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Xavier Bestel] Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a écrit : How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Did you try DirectFB ? Thanks for the tip, I hadn't heard about it. I will take a look, but only to see if it can show me the user space API of /dev/fb. I don't need a general library that supports a bunch of different graphics cards. I'm writing my own frame buffer driver for the GX2 CPU, and I just want to know how to call the various functions registered in struct fb_ops, so that I can test my code. I mean, all those functions registered in fb_ops must be accessible somehow; if they weren't, what purpose would they serve? -- Haakon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, Feb 02, 2005 at 03:21:55PM +0100, Haakon Riiser wrote: X-Windows already does this. Yeah, I thought the X11 fbdev driver supported acceleration, but not according to its manpage: fbdev is an Xorg driver for framebuffer devices. This is a non-accelerated driver [...] Yepp, it would be cool, to move every low level graphical operation to the framebuffer devices ... So no more 'I would like to use framebuffer console _AND_ X at the same time without disturbing each other' problem, and also if X segfaults or such, consolse will not remain in unusable state. Also a solid low level graphical operation layer should provide even 3D acceleration for fbdev capable (but not X!) apps and of course for the X server ... without conflicting each other :) DirectFB seems to be a good idea anyway ... - Gbor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser [EMAIL PROTECTED] wrote: Thanks for the tip, I hadn't heard about it. I will take a look, but only to see if it can show me the user space API of /dev/fb. I don't need a general library that supports a bunch of different graphics cards. I'm writing my own frame buffer driver for the GX2 CPU, and I just want to know how to call the various functions registered in struct fb_ops, so that I can test my code. I mean, all those functions registered in fb_ops must be accessible somehow; if they weren't, what purpose would they serve? You should look at writing a DRM driver. DRM implements the kernel interface to get 3D hardware running. It is a fully accelerated driver interface. They are located in drivers/char/drm -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Jon Smirl] On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser [EMAIL PROTECTED] wrote: Thanks for the tip, I hadn't heard about it. I will take a look, but only to see if it can show me the user space API of /dev/fb. I don't need a general library that supports a bunch of different graphics cards. I'm writing my own frame buffer driver for the GX2 CPU, and I just want to know how to call the various functions registered in struct fb_ops, so that I can test my code. I mean, all those functions registered in fb_ops must be accessible somehow; if they weren't, what purpose would they serve? You should look at writing a DRM driver. DRM implements the kernel interface to get 3D hardware running. It is a fully accelerated driver interface. They are located in drivers/char/drm Have the standard frame buffer drivers been abandoned, even for devices that have no 3D acceleration (like the Geode GX2)? I took a quick look at the DRM stuff, and it looked like extreme overkill for what I need, if it even can be used for what I want to do. At first glance it looked like this is only relevant for OpenGL/X11 3D-stuff, which I have absolutely no use for. GX2 is an integrated CPU/graphics chip for embedded systems. We have third party applications that use the framebuffer device, and I was hoping to make things faster by writing an accelerated driver. The only thing I need answered is how to access fb_ops from userspace. If that is impossible because all the framebuffer code is leftover junk that no one uses anymore, or even /can/ use anymore because the userspace interface is gone, please let me know now so I don't have to waste any more time. -- Haakon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a écrit : How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Did you try DirectFB ? Thanks for the tip, I hadn't heard about it. I will take a look, but only to see if it can show me the user space API of /dev/fb. I don't need a general library that supports a bunch of different graphics cards. I'm writing my own frame buffer driver for the GX2 CPU, and I just want to know how to call the various functions registered in struct fb_ops, so that I can test my code. I mean, all those functions registered in fb_ops must be accessible somehow; if they weren't, what purpose would they serve? The reason for the accelerated functions is for the framebuffer console. Drawing pixel by pixel is to slow. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
You should look at writing a DRM driver. DRM implements the kernel interface to get 3D hardware running. It is a fully accelerated driver interface. They are located in drivers/char/drm Have the standard frame buffer drivers been abandoned, even for devices that have no 3D acceleration (like the Geode GX2)? No. It is still around. I took a quick look at the DRM stuff, and it looked like extreme overkill for what I need, if it even can be used for what I want to do. At first glance it looked like this is only relevant for OpenGL/X11 3D-stuff, which I have absolutely no use for. This is usually the case for embedded chips. This is the reason the fbdev userland interface is still around. GX2 is an integrated CPU/graphics chip for embedded systems. We have third party applications that use the framebuffer device, and I was hoping to make things faster by writing an accelerated driver. The only thing I need answered is how to access fb_ops from userspace. You can mmap the mmio address space and program the registers yourself. A bonus is the example code is in the driver :-) If that is impossible because all the framebuffer code is leftover junk that no one uses anymore, or even /can/ use anymore because the userspace interface is gone, please let me know now so I don't have to waste any more time. The userspace interface is still there. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, 2 Feb 2005, Haakon Riiser wrote:
On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser
[EMAIL PROTECTED] wrote:
Thanks for the tip, I hadn't heard about it. I will take a look,
but only to see if it can show me the user space API of /dev/fb.
I don't need a general library that supports a bunch of different
graphics cards. I'm writing my own frame buffer driver for the
GX2 CPU, and I just want to know how to call the various functions
registered in struct fb_ops, so that I can test my code. I mean,
all those functions registered in fb_ops must be accessible
somehow; if they weren't, what purpose would they serve?
You should look at writing a DRM driver. DRM implements the kernel
interface to get 3D hardware running. It is a fully accelerated driver
interface. They are located in drivers/char/drm
Have the standard frame buffer drivers been abandoned, even
for devices that have no 3D acceleration (like the Geode GX2)?
No.
GX2 is an integrated CPU/graphics chip for embedded systems.
We have third party applications that use the framebuffer device,
and I was hoping to make things faster by writing an accelerated
driver. The only thing I need answered is how to access fb_ops
from userspace. If that is impossible because all the framebuffer
code is leftover junk that no one uses anymore, or even /can/
use anymore because the userspace interface is gone, please let
me know now so I don't have to waste any more time.
mmap() the MMIO registers to userspace, and program the acceleration engine
from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and Mach64) does.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Geert Uytterhoeven] mmap() the MMIO registers to userspace, and program the acceleration engine from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and Mach64) does. Right, this was how I originally intended to do it. The reason why I started to obsess about the accelerated fb_ops functions was that I hoped that, by creating a driver that registered accelerated versions of these functions, other frame buffer-using applications would instantly take advantage of it, requiring no changes in those applications. I thought the frame buffer device was supposed to serve as an an abstraction layer between the graphics card and the application, allowing for 2D acceleration without having to know anything about the underlying hardware. But if no one uses the frame buffer device in this way, I might as well do as you suggest and mmap() the registers to userspace. Anyway, thanks to everyone who participated in this thread. Even if I didn't get the answers I was hoping for, at least now I can put the matter to rest. -- Haakon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
