Menu
▾
▴
linux-fbdev-devel
|
From: Chris W. <cw...@so...> - 2001-10-04 19:35:24
|
This is somewhat ironic, but a friend of mine and myself have been
recently pondering vast extentions into the /dev/fb device.
Basically, we see it as a great device already. (a simple pointer to
screen memory is all a graphics programmer ever wants). however, most new
hardware usually supports some form of 2d and 3d acceleration.
unfortunately, these are seldom/never used in linux unless you have a card
that is supported, and then, only if you use X, which defeats the purpose
of /dev/fb. we are proposing that a standard suite of ioctl's get added
to aid in acceleration. of course, the basic driver would be a simple
vesafb driver plus software accelerations. as cards are added, and
drivers are ported, they could be used in the software's place. This
would make the hardware usable by anything, not just stuff in X, which
seems like a Good Thing to me :^)
so, is it a completly idiotic idea, or is there some potential here?
Computers are useless. They can only give you answers.
-- Pablo Picasso
|
|
From: M. R. B. <mr...@0x...> - 2001-10-04 21:13:02
|
* Chris Wright <cw...@so...> on Thu, Oct 04, 2001: > This is somewhat ironic, but a friend of mine and myself have been > recently pondering vast extentions into the /dev/fb device. > Basically, we see it as a great device already. (a simple pointer to > screen memory is all a graphics programmer ever wants). however, most new > hardware usually supports some form of 2d and 3d acceleration. > unfortunately, these are seldom/never used in linux unless you have a card > that is supported, and then, only if you use X, which defeats the purpose > of /dev/fb. we are proposing that a standard suite of ioctl's get added > to aid in acceleration. of course, the basic driver would be a simple > vesafb driver plus software accelerations. as cards are added, and > drivers are ported, they could be used in the software's place. This > would make the hardware usable by anything, not just stuff in X, which > seems like a Good Thing to me :^) > > so, is it a completly idiotic idea, or is there some potential here? > IMO, DRM is best suited for this, except that DRM is currently only used by the DRI in X. I would think this would be the way to go (instead of a new, clunky, IOCTL interface), but then the question becomes, do you want to duplicate all of the DRI work (since DRM is only concerned with the "basics", as it should be) for a fb interface? Or would a fb-only interface independent of DRI (but still a Mesa backend) be better? M. R. |
|
From: James S. <jsi...@tr...> - 2001-10-04 22:27:39
|
> IMO, DRM is best suited for this, except that DRM is currently only used by > the DRI in X. I would think this would be the way to go (instead of a new, > clunky, IOCTL interface), but then the question becomes, do you want to > duplicate all of the DRI work (since DRM is only concerned with the > "basics", as it should be) for a fb interface? Or would a fb-only > interface independent of DRI (but still a Mesa backend) be better? I have spoken about this before. I like to see both interfaces merge in the future. Especially with the desire to move from traditional device files to device filesystems. In the future their will be a graphics frilesystem to replace the two. Well that is my dream. Of course their are a few issues on design with DRI which I will not go into here. |
|
From: Paul M. <le...@Ch...> - 2001-10-04 23:30:34
|
On Thu, Oct 04, 2001 at 03:26:26PM -0700, James Simmons wrote: > I have spoken about this before. I like to see both interfaces merge in > the future. Especially with the desire to move from traditional device > files to device filesystems. In the future their will be a graphics > frilesystem to replace the two. Well that is my dream. Of course their are > a few issues on design with DRI which I will not go into here. > This sounds like a potential Ruby issue to me (well, the FS part anyways).. how about starting a module for it (or hacking it into the existing tree)? Regards, -- Paul Mundt <le...@ch...> |
|
From: James S. <jsi...@tr...> - 2001-10-04 23:59:09
|
On Thu, 4 Oct 2001, Paul Mundt wrote: > On Thu, Oct 04, 2001 at 03:26:26PM -0700, James Simmons wrote: > > I have spoken about this before. I like to see both interfaces merge in > > the future. Especially with the desire to move from traditional device > > files to device filesystems. In the future their will be a graphics > > frilesystem to replace the two. Well that is my dream. Of course their are > > a few issues on design with DRI which I will not go into here. > > > This sounds like a potential Ruby issue to me (well, the FS part anyways).. > how about starting a module for it (or hacking it into the existing tree)? We could but it would be a huge job. Alot of devfs tinkering. |
|
From: Paul M. <pm...@mv...> - 2001-10-05 00:32:28
|
On Thu, Oct 04, 2001 at 04:58:53PM -0700, James Simmons wrote:
> > > I have spoken about this before. I like to see both interfaces merge =
in
> > > the future. Especially with the desire to move from traditional device
> > > files to device filesystems. In the future their will be a graphics
> > > frilesystem to replace the two. Well that is my dream. Of course thei=
r are
> > > a few issues on design with DRI which I will not go into here. =20
> > >=20
> > This sounds like a potential Ruby issue to me (well, the FS part anyway=
s)..
> > how about starting a module for it (or hacking it into the existing tre=
e)?
>=20
> We could but it would be a huge job. Alot of devfs tinkering.=20
>=20
Why deal with devfs tinkering? It would make more sense to implement it as =
its
own native virtual fs. As an example.. could have something like /dev/gfx a=
s a
top level mountpoint for the fs, and then just mount on that (wouldn't matt=
er
if it were devfs or not).
As far as general interfaces go.. a drop-in replacement for the ioctl()'s
really wouldn't be that big of a deal.
For each device that registered with the system, things could be done like:
/dev/gfx/
0/
fb
cmap
...
mode
1/
fb
cmap
...
mode
and so on, and so forth..
/dev/fb{,/}0 would simply be a symlink to /dev/gfx/0/fb.
FBIOGETCMAP/FBIOPUTCMAP can be done away with by doing reads and writes to =
the
/dev/gfx/0/cmap dentry. Just as all other GET/PUT routines can be done away
with.
Instead of trying to do "special" dentry manipulation in the fs itself, I
think it'd make more sense to just provide a few common interfaces.. Devices
only really need to register themselves with the system.. it's up to the
fb layer to deal with creation of the dentrys and dealing with any kind of
special requests. (Just as it would the requirement for any other subsystem
(DRM anyone?) to deal with special files and registering callbacks with
the fs for them).
The fs itself only needs to do a few things.. provide a few routines for
device registration, and for registering callbacks. In the event that no
callback is provided (or no flags like read-only are set on the created
file), generic dcache routines can be utilized instead..
This could all be done with just having a small structure that contained
a pointer to the dentry struct and a pointer to a set of routines that
callbacks can be assigned to. (Then just check for the existance of a provi=
ded
callback registered with the dentry when things were allocated, and either
use those, or fallback on defaults).
Another advantage of this system is that people who have special needs with
the system can simply write a module that sets up the files it wants, and
registers some callbacks and have it either globally applied or limit it
specifically to a specific card.. Reducing the need for adding ioctl()'s.
All in all, this really shouldn't be that big of a deal.. I don't think an
initial implementation should be difficult at all.. laying out the API
would really be the biggest trick.
Comments?
Regards,
--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.
|
|
From: James S. <jsi...@tr...> - 2001-10-05 18:30:20
|
> Why deal with devfs tinkering?
I'm thinking devfs was designed with the one file decriptor to hardware
model. As you know I plan to expand this.
> It would make more sense to implement it as its
> own native virtual fs. As an example.. could have something like /dev/gfx as a
> top level mountpoint for the fs, and then just mount on that (wouldn't matter
> if it were devfs or not).
True. Perhaps we should start off this way with a few device filesystems
and see the commonality in them to figure out a common backbone. I just
don't want to end up duplicating alot of what devfs has done.
[snip..
> /dev/fb{,/}0 would simply be a symlink to /dev/gfx/0/fb.
Yeap.
[snip]...
Wow!! I see you have put serious thought into this. More than I have.
> laying out the API would really be the biggest trick.
Oh yeah. Tonight we can discuss some issues then.
|
|
From: Paul M. <pm...@mv...> - 2001-10-05 19:16:48
|
On Fri, Oct 05, 2001 at 11:30:12AM -0700, James Simmons wrote: > I'm thinking devfs was designed with the one file decriptor to hardware > model. As you know I plan to expand this. >=20 devfs works fine with the one file descriptor per registered device model, as that's what it was designed for. For any kind of specialized requirements such as multiple file descriptors per registered device component, you are no longer under the scope of what devfs was designed for, thus a new virtual fs makes sense. > > It would make more sense to implement it as its > > own native virtual fs. As an example.. could have something like /dev/g= fx > > as a top level mountpoint for the fs, and then just mount on that (woul= dn't > > matter if it were devfs or not). >=20 > True. Perhaps we should start off this way with a few device filesystems > and see the commonality in them to figure out a common backbone. I just > don't want to end up duplicating alot of what devfs has done. >=20 There really shouldn't be too much duplication of devfs at all. I think the only thing we really need to deal with devfs for would be for /dev/fb/0 registration.. at which point we can just register with devfs and have it generate a symlink to the appropriate dentry under the gfxfs.. in this case /dev/gfx/0/fb. Other than that, devfs has no reason to care about anything else. > > laying out the API would really be the biggest trick. >=20 > Oh yeah. Tonight we can discuss some issues then. Sounds good. Regards, --=20 Paul Mundt <pm...@mv...> MontaVista Software, Inc. |
|
From: James S. <jsi...@tr...> - 2001-10-05 22:04:36
|
> you are > no longer under the scope of what devfs was designed for, thus a new virtual > fs makes sense. I thought so. > > Oh yeah. Tonight we can discuss some issues then. > > Sounds good. Okay. I will be online around 7:30 tonight. |
|
From: Sven <lu...@dp...> - 2001-10-05 08:39:47
|
On Thu, Oct 04, 2001 at 04:12:52PM -0500, M. R. Brown wrote: > * Chris Wright <cw...@so...> on Thu, Oct 04, 2001: > > > This is somewhat ironic, but a friend of mine and myself have been > > recently pondering vast extentions into the /dev/fb device. > > Basically, we see it as a great device already. (a simple pointer to > > screen memory is all a graphics programmer ever wants). however, most new > > hardware usually supports some form of 2d and 3d acceleration. > > unfortunately, these are seldom/never used in linux unless you have a card > > that is supported, and then, only if you use X, which defeats the purpose > > of /dev/fb. we are proposing that a standard suite of ioctl's get added > > to aid in acceleration. of course, the basic driver would be a simple > > vesafb driver plus software accelerations. as cards are added, and > > drivers are ported, they could be used in the software's place. This > > would make the hardware usable by anything, not just stuff in X, which > > seems like a Good Thing to me :^) > > > > so, is it a completly idiotic idea, or is there some potential here? > > > > IMO, DRM is best suited for this, except that DRM is currently only used by > the DRI in X. I would think this would be the way to go (instead of a new, > clunky, IOCTL interface), but then the question becomes, do you want to > duplicate all of the DRI work (since DRM is only concerned with the > "basics", as it should be) for a fb interface? Or would a fb-only > interface independent of DRI (but still a Mesa backend) be better? There is no reason we couldn't use the DRM. I think James was speaking some time ago about integrating DRM and fbdev, but i don't know if it is realistic, or if this idea has progressed since. Basically, from my experimentation with it while working on the X glint driver, the DRI stuff is composed of 3 parts : o the DRM kernel driver, which contains interrupt handling, as well as the dma buffers support, with some additional control mechanism, allowing only root to access some part of the dma registers. This could and can be used for other purposes. o the XFree86 DRI driver, which does the intialization and the ressource management. It also handles some part of the context switching and register saving/setting. This we will need to dupilcate, and i don't really think that it is the right place for it. The X folk don't thnk so though. o and finally, the openGL/Mesa drivers. This is a clientside thing, which provide all the stuff needed for acccel, and there is nothing stopping us from using it from the console. What would be needed for fbdev to support DRI/OpenGL accels, would be for the fbdev to provide the ressource management and initialisation done by the XFree86 DRI driver, and most of the other stuff could be used as is. Anyway, the fbdev driver mostly already has part of the info already needed (the cards io and mem base and other such stuff), but i don't really know if there is much more generic DRI stuff done. I think yes, but i have not looked. Most of this could be handled by a userland small server app controlling the DRI usage, or whatever. It may not even contain device specific stuff, not sure though about it. That said, the main problem is with the coordination of the 3D accel usage between X and fbdev, especially if both use separate dma buffers. It would also add lot of unused context switching. Friendly, Sven Luther Now, |
|
From: Paul M. <le...@Ch...> - 2001-10-04 23:24:41
|
On Thu, Oct 04, 2001 at 03:33:18PM -0400, Chris Wright wrote: > This is somewhat ironic, but a friend of mine and myself have been > recently pondering vast extentions into the /dev/fb device. > Basically, we see it as a great device already. (a simple pointer to > screen memory is all a graphics programmer ever wants). however, most new > hardware usually supports some form of 2d and 3d acceleration. > unfortunately, these are seldom/never used in linux unless you have a card > that is supported, and then, only if you use X, which defeats the purpose > of /dev/fb. we are proposing that a standard suite of ioctl's get added > to aid in acceleration. of course, the basic driver would be a simple > vesafb driver plus software accelerations. as cards are added, and > drivers are ported, they could be used in the software's place. This > would make the hardware usable by anything, not just stuff in X, which > seems like a Good Thing to me :^) > Ick. Adding ioctl()'s shouldn't even be considered. Instead of _adding_ more, it really would be a lot cleaner to just gut them entirely and move to a real namespace system (gfxfs anyone?).. then you can have your direct pointer to video memory, colormap, and so on, and so forth.. Getting fb to interoperate with the DRM code (and vice versa *cough* MTRR handling *end cough*) would clean a lot of that sort of stuff.. especially with things like DMA resource management. Would certainly make X happier. Regards, -- Paul Mundt <le...@ch...> |
|
From: James S. <jsi...@tr...> - 2001-10-04 23:58:11
|
> Ick. Adding ioctl()'s shouldn't even be considered. Instead of _adding_ more, > it really would be a lot cleaner to just gut them entirely and move to a > real namespace system (gfxfs anyone?).. then you can have your direct pointer > to video memory, colormap, and so on, and so forth.. Yes. This is what I have been advocating. You have to move away from the one file descriptor to device ideal. We can have several files, each representing a functionality of device. Plus this allows for network transprancy and we can use scripts to do things like set a video mode. This would be really nice. > Getting fb to interoperate with the DRM code (and vice versa *cough* MTRR > handling *end cough*) would clean a lot of that sort of stuff.. especially > with things like DMA resource management. Would certainly make X happier. Agree. |
×
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