Menu
▾
▴
linux-fbdev-devel
|
From: Chris W. <cw...@so...> - 2001-10-01 18:48:24
|
Hello!
is there a standard way to access hardware acceleration without needing
root privs or X? (sort of like accessing framebuffer before /dev/fb, you
needed svgalib (root), or some X based library).
if there isn't a way (dri is X only afaik), hows the forecast for creating
a kernel level hardware acceleration overlay, with software fallbacks?
(i am guessing this really wont put much code into the kernel, but will
have lots of modules etc).
thanks for your time =)
chris
Computers are useless. They can only give you answers.
-- Pablo Picasso
|
|
From: Romain D. <do...@ir...> - 2001-10-02 08:51:24
|
Chris Wright wrote:
> is there a standard way to access hardware acceleration without needing
> root privs or X? (sort of like accessing framebuffer before /dev/fb, you
> needed svgalib (root), or some X based library).
Not yet, I believe.
> if there isn't a way (dri is X only afaik), hows the forecast for creating
> a kernel level hardware acceleration overlay, with software fallbacks?
> (i am guessing this really wont put much code into the kernel, but will
> have lots of modules etc).
DRI is a 3D-on-XFree86 thing.
It could be done to add ioctl to allow app access to fb_fillrect
and fb_copyarea, and maybe fb_imageblit. But I'm not sure it could
make it to the Linux tree...
Yet it might worth talking about it. Stuff like microwindows
could probably use it.
It would be a simple ioctl wrapper around the fb_* stuff,
as those are mandatory (either HW-accel or using the supplied
generic functions).
--
DOLBEAU Romain | l'histoire est entierement vraie, puisque
| je l'ai imaginee d'un bout a l'autre
do...@ir... | -- Boris Vian
|
|
From: <dol...@cl...> - 2001-10-02 15:54:55
|
Chris Wright wrote: > is there a standard way to access hardware acceleration without needing > root privs or X? (sort of like accessing framebuffer before /dev/fb, you > needed svgalib (root), or some X based library). Romain Dolbeau answered: > It could be done to add ioctl to allow app access to fb_fillrect and > fb_copyarea, and maybe fb_imageblit. But I'm not sure it could make it to > the Linux tree... Oups, I forgot to check the header, and thought the original message was on linux-console, not linux-fbdev. My comments apply to the new "Ruby" framework, not to the current 2.2/2.4 stuff. Those use cell-based copy and erase (a cell contain one character), where Ruby use pixel-based copy and fill, much more flexible. I've hacked a patch to add the two IOCTLS (for fillrect and copyarea), it's less than 90 lines. Maybe it's worth adding to Ruby ? -- DOLBEAU Romain | The Gods made Heavy Metal ENS Cachan / Ker Lann | and it's never gonna die Thesard IRISA / CAPS | -- Manowar, dol...@cl... | 'The Gods made Heavy Metal' |
|
From: James S. <jsi...@tr...> - 2001-10-02 19:16:39
|
> My comments apply to the new "Ruby" framework, not to the current > 2.2/2.4 stuff. Those use cell-based copy and erase (a cell contain one > character), where Ruby use pixel-based copy and fill, much more > flexible. > > I've hacked a patch to add the two IOCTLS (for fillrect and copyarea), > it's less than 90 lines. Maybe it's worth adding to Ruby ? I don't know about it being added into the linus tree but it would be really helpful for debugging. Add it anyways. I kind of provided the structs for it anyways. |
|
From: <dol...@cl...> - 2001-10-02 19:48:23
|
> I don't know about it being added into the linus tree but it would be > really helpful for debugging. Add it anyways. I kind of provided the > structs for it anyways. Commited. It uses a couple custom struct, I didn't see anything reasonably similar in fb.h ? Note: it compiles, but hasn't been tested. Should work with any driver, it's just 2 wrappers around fb_ops->fb_fillrect and fb_ops->fb_copyarea. --=20 Romain DOLBEAU | Ce que l'on con=E7oit bien s'=E9nonce ENS Cachan / Ker Lann | clairement, et les mots pour le dire Thesard IRISA / CAPS | arrivent ais=E9ment. dol...@cl... | -- Nicolas Boileau |
|
From: James S. <jsi...@tr...> - 2001-10-02 20:36:26
|
> Commited. It uses a couple custom struct, I didn't see anything > reasonably similar in fb.h ? Nope. Only thing I have is fb_image. I moved the stuff together for userland to use. I have ROP_X in the kernel section. Now it is useable to userland. We could extend it to support image drawing as well. Draw writers can see if they get the penguin when insmoding. |
|
From: Romain D. <do...@ir...> - 2001-10-03 08:50:41
|
James Simmons wrote:
> Nope. Only thing I have is fb_image. I moved the stuff together for
> userland to use. I have ROP_X in the kernel section. Now it is useable to
> userland. We could extend it to support image drawing as well. Draw
> writers can see if they get the penguin when insmoding.
I've added a small 'acceltest' app in ruby/utils, it's supposed
to move a coloured rectangle to the bottom right corner of the
screen. Not tested...
--
DOLBEAU Romain | l'histoire est entierement vraie, puisque
| je l'ai imaginee d'un bout a l'autre
do...@ir... | -- Boris Vian
|
|
From: Geert U. <ge...@li...> - 2001-10-03 11:17:01
|
On Wed, 3 Oct 2001, Romain Dolbeau wrote:
> James Simmons wrote:
> > Nope. Only thing I have is fb_image. I moved the stuff together for
> > userland to use. I have ROP_X in the kernel section. Now it is useable to
> > userland. We could extend it to support image drawing as well. Draw
> > writers can see if they get the penguin when insmoding.
>
> I've added a small 'acceltest' app in ruby/utils, it's supposed
> to move a coloured rectangle to the bottom right corner of the
> screen. Not tested...
You can also extend fbtest to use the ioctl()s when they are available (how to
find out?).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Romain D. <do...@ir...> - 2001-10-03 11:37:13
|
Geert Uytterhoeven wrote:
> You can also extend fbtest to use the ioctl()s when they are available (how to
> find out?).
Well, if you use the latest Ruby they are available :-)
It's just a standard wrapper around mandatory functions, in fbmem.c
If the #define exist in the header fb.h, they are there...
They can't be added to 2.2/2.4, because they need the pixel-based
functions, 2.2/2.4 accel is cell-based only.
--
DOLBEAU Romain | l'histoire est entierement vraie, puisque
| je l'ai imaginee d'un bout a l'autre
do...@ir... | -- Boris Vian
|
|
From: Geert U. <ge...@li...> - 2001-10-03 11:47:13
|
On Wed, 3 Oct 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > You can also extend fbtest to use the ioctl()s when they are available (how to
> > find out?).
>
> Well, if you use the latest Ruby they are available :-)
>
> It's just a standard wrapper around mandatory functions, in fbmem.c
> If the #define exist in the header fb.h, they are there...
>
> They can't be added to 2.2/2.4, because they need the pixel-based
> functions, 2.2/2.4 accel is cell-based only.
Do you really have to implement the pixel-based functions for all possible
values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
doesn't really need it. That's why we have the support for width field for the
cell-based operations.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Romain D. <do...@ir...> - 2001-10-03 11:57:45
|
Geert Uytterhoeven wrote:
> Do you really have to implement the pixel-based functions for all possible
> values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
> doesn't really need it. That's why we have the support for width field for the
> cell-based operations.
None of those driver exist in Ruby ;-)
The idea is, the pixel-based functions are _required_ in Ruby. Either
the driver supply them, or there's some generic functions for
the most common pixel type.
The ioctls simply give access to these functions to userland apps. They
don't have to worry on specific hardware, they just say 'copy
area "width*height+sourceX+sourceY" to "destX,destY"', or
'fill area "w*h+x+y" with color C'.
If there's driver where pixel-based stuff is problematic, tell
James or Vojtech, as it might cause worse problems than userland
accelerated drawing...
--
DOLBEAU Romain | l'histoire est entierement vraie, puisque
| je l'ai imaginee d'un bout a l'autre
do...@ir... | -- Boris Vian
|
|
From: James S. <jsi...@tr...> - 2001-10-03 16:41:17
|
> > They can't be added to 2.2/2.4, because they need the pixel-based
> > functions, 2.2/2.4 accel is cell-based only.
>
> Do you really have to implement the pixel-based functions for all possible
> values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
> doesn't really need it. That's why we have the support for width field for the
> cell-based operations.
Well no. I like to think of the accel functions as being more
functionality oriented. When using the accel engine you are not thinking
draw these pixel. You are thinking fill in or copy this area. Their exist
hardware which is not pixel based so I hope the api is flexiable enough to
handle this.
The above examples you gave are such a example of not the usually
pixel. mfb easily fits into the cfb. The code I have written supports it.
I thought about ilbm. Since it is a bunch of bitmaps (1 to N) being one
after another and each bitmap is a collect of a bit value at position X in
the pixel where X is bitmap N. We could easily write soft accel functions.
For a rectfill it is a matter of taking a color to fill in with and
reading one bit at a time and filling in a are in the bitmap with a group
of 1's or a whole group of 0's. As you can see this could be really fast.
As for drawing a image that has to be units of 8 fbcon handles that by
ensuring only fonts of size of units of 8 are allowed to be used. It
still has the test to prevent something naugthy from happening. As for
userland doing stuff. The drawimage function really not avaliable for
userland. Sure we can have ioctl to test the draw functions for a driver
but we should leave it at that. Only for debugging purposes.
|
|
From: James S. <jsi...@tr...> - 2001-10-03 16:25:25
|
> Well, if you use the latest Ruby they are available :-) > > It's just a standard wrapper around mandatory functions, in fbmem.c > If the #define exist in the header fb.h, they are there... > > They can't be added to 2.2/2.4, because they need the pixel-based > functions, 2.2/2.4 accel is cell-based only. Actaully I have written a wrapper to be used with 2.4.X. I don't like to think of it as pixel based but more functionality based. You can use other things to preform something like a triangle fill. Say a texture map of one color. |
|
From: James S. <jsi...@tr...> - 2001-10-03 16:23:05
|
> You can also extend fbtest to use the ioctl()s when they are available (how to > find out?). I added a api_version feild into fb_fix_screeninfo. For the current api we have this as reserved[3] which means it should have a value of zero (not implemented). For newer drivers they shoudl set that feild to one. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X