Hi,
the following patch (against 2.6.5-rc2) teaches fb to use class_simple.
With this patch udev will automagically create device nodes for each
framebuffer registered. Once all drivers are converted to
framebuffer_{alloc,release} we can switch to our own class.
This is what sysfs dir looks like:
notebook:~# tree /sys/class/graphics/
/sys/class/graphics/
`-- fb0
`-- dev
1 directory, 1 file
--- a/drivers/video/fbmem.c 2004-03-20 15:57:53.000000000 +0100
+++ b/drivers/video/fbmem.c 2004-03-20 16:17:26.000000000 +0100
@@ -32,6 +32,9 @@
#include <linux/kmod.h>
#endif
#include <linux/devfs_fs_kernel.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
#if defined(__mc68000__) || defined(CONFIG_APUS)
#include <asm/setup.h>
@@ -1251,6 +1254,8 @@
#endif
};
+static struct class_simple *fb_class;
+
/**
* register_framebuffer - registers a frame buffer device
* @fb_info: frame buffer info structure
@@ -1265,6 +1270,7 @@
register_framebuffer(struct fb_info *fb_info)
{
int i;
+ struct class_device *c;
if (num_registered_fb == FB_MAX)
return -ENXIO;
@@ -1273,6 +1279,12 @@
if (!registered_fb[i])
break;
fb_info->node = i;
+
+ c = class_simple_device_add(fb_class, MKDEV(FB_MAJOR, i), NULL, "fb%d", i);
+ if (IS_ERR(c)) {
+ /* Not fatal */
+ printk(KERN_WARNING "Unable to create class_device for framebuffer %d; errno = %ld\n", i, PTR_ERR(c));
+ }
if (fb_info->pixmap.addr == NULL) {
fb_info->pixmap.addr = kmalloc(FBPIXMAPSIZE, GFP_KERNEL);
@@ -1338,6 +1350,7 @@
kfree(fb_info->sprite.addr);
registered_fb[i]=NULL;
num_registered_fb--;
+ class_simple_device_remove(MKDEV(FB_MAJOR, i));
return 0;
}
@@ -1399,6 +1412,12 @@
if (register_chrdev(FB_MAJOR,"fb",&fb_fops))
printk("unable to get major %d for fb devs\n", FB_MAJOR);
+ fb_class = class_simple_create(THIS_MODULE, "graphics");
+ if (IS_ERR(fb_class)) {
+ printk(KERN_WARNING "Unable to create fb class; errno = %ld\n", PTR_ERR(fb_class));
+ fb_class = NULL;
+ }
+
#ifdef CONFIG_FB_OF
if (ofonly) {
offb_init();
Luca
--
Home: http://kronoz.cjb.net
La differenza fra l'intelligenza e la stupidita`?
All'intelligenza c'e` un limite.
On Sat, Mar 20, 2004 at 06:49:56PM +0100, Kronos wrote:
> Hi,
> the following patch (against 2.6.5-rc2) teaches fb to use class_simple.
> With this patch udev will automagically create device nodes for each
> framebuffer registered. Once all drivers are converted to
> framebuffer_{alloc,release} we can switch to our own class.
yeah, it's about time! Didn't I post this patch a few months ago... :)
Anyway, it looks good, I only have one comment:
> notebook:~# tree /sys/class/graphics/
> /sys/class/graphics/
"graphics"? Why that? Why not "fb"?
It doesn't really matter to me, just curious.
thanks,
greg k-h
Il Sat, Mar 20, 2004 at 01:30:30PM -0800, Greg KH ha scritto:
> On Sat, Mar 20, 2004 at 06:49:56PM +0100, Kronos wrote:
> > Hi,
> > the following patch (against 2.6.5-rc2) teaches fb to use class_simple.
> > With this patch udev will automagically create device nodes for each
> > framebuffer registered. Once all drivers are converted to
> > framebuffer_{alloc,release} we can switch to our own class.
>
> yeah, it's about time! Didn't I post this patch a few months ago... :)
Hum, I remeber your patch that did the same thing, but it didn't use
class_simple, did it?
> Anyway, it looks good, I only have one comment:
>
> > notebook:~# tree /sys/class/graphics/
> > /sys/class/graphics/
>
> "graphics"? Why that? Why not "fb"?
>
> It doesn't really matter to me, just curious.
It was discussed a while ago (this is James):
<quote>
On Tue, 9 Sep 2003, Benjamin Herrenschmidt wrote:
> > On Tue, 2003-09-09 at 21:24, Kronos wrote:
> > > +static struct class fb_class = {
> > > + .name = "video",
> >
> > I'd rather use "display" here. "video" is too broad and will cause
> > confusion with multimedia stuff.
>
> Exactly my comment. I was thinking about `graphics' instead of
> `video', but indeed `display' sounds better. Gr{oetje,eeting}s,
I prefere graphics myself. Display sounds to generic. That is what video
and graphics output is piped to. Since fbdev doesn't handle video ouput
normally this is kind of fuzzy sounding.
</quote>
Luca
--
Home: http://kronoz.cjb.net
"Di tutte le perversioni sessuali, la castita` e` la piu` strana".
Anatole France
On Sat, Mar 20, 2004 at 10:52:19PM +0100, Kronos wrote:
> Il Sat, Mar 20, 2004 at 01:30:30PM -0800, Greg KH ha scritto:
> > On Sat, Mar 20, 2004 at 06:49:56PM +0100, Kronos wrote:
> > > Hi,
> > > the following patch (against 2.6.5-rc2) teaches fb to use class_simple.
> > > With this patch udev will automagically create device nodes for each
> > > framebuffer registered. Once all drivers are converted to
> > > framebuffer_{alloc,release} we can switch to our own class.
> >
> > yeah, it's about time! Didn't I post this patch a few months ago... :)
>
> Hum, I remeber your patch that did the same thing, but it didn't use
> class_simple, did it?
I think I had one version that did, but who cares, it doesn't really
matter :)
> > > notebook:~# tree /sys/class/graphics/
> > > /sys/class/graphics/
> >
> > "graphics"? Why that? Why not "fb"?
> >
> > It doesn't really matter to me, just curious.
>
> It was discussed a while ago (this is James):
>
> <quote>
> On Tue, 9 Sep 2003, Benjamin Herrenschmidt wrote:
> > > On Tue, 2003-09-09 at 21:24, Kronos wrote:
> > > > +static struct class fb_class = {
> > > > + .name = "video",
> > >
> > > I'd rather use "display" here. "video" is too broad and will cause
> > > confusion with multimedia stuff.
> >
> > Exactly my comment. I was thinking about `graphics' instead of
> > `video', but indeed `display' sounds better. Gr{oetje,eeting}s,
>
> I prefere graphics myself. Display sounds to generic. That is what video
> and graphics output is piped to. Since fbdev doesn't handle video ouput
> normally this is kind of fuzzy sounding.
> </quote>
Well, /sys/class/video is already taken by the V4L core code, so if
"graphics" doesn't confuse people, it's ok with me.
thanks,
greg k-h
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 20 March 2004 22:59, Greg KH wrote:
> Well, /sys/class/video is already taken by the V4L core code, so if
> "graphics" doesn't confuse people, it's ok with me.
I think it DOES confuse people. If they see that, they think the kernel
has (got) a graphics subsystem (now). That is simply not true, since it
is not even the lowest layer of the graphics subsystem in Linux, except
on a few special cases. It is just an basic accelerated 2D framebuffer.
No more, no less.
When we have all devices in that class, that are needed to run fully
accelerated 3D graphics, without any direct hardware access, then we
could call it "graphics class" without any confusion.
So PLEASE consider this confusion or people will start argueing with me
whether Linux has an in kernel graphics subsystem (like KGI once) and
not all people can be convinced by code, because not all are coders
anymore ;-)
Thanks & regards
Ingo Oeser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAXUwZU56oYWuOrkARAi2SAKCWOIOvQp5PtVbfZuudMoiXauX1OACg0Ji4
s0R/gqsMRXLbsm5iU2c4MDg=
=K/NA
-----END PGP SIGNATURE-----
> I prefere graphics myself. Display sounds to generic. That is what video
> and graphics output is piped to. Since fbdev doesn't handle video ouput
> normally this is kind of fuzzy sounding.
I still prefer display...
Ben.
On Mon, Mar 22, 2004 at 09:50:46AM +1100, Benjamin Herrenschmidt wrote:
>
> > I prefere graphics myself. Display sounds to generic. That is what video
> > and graphics output is piped to. Since fbdev doesn't handle video ouput
> > normally this is kind of fuzzy sounding.
>
> I still prefer display...
Bah, I don't want to argue here. I've applied Kronos's patch as is to
my device-2.6 tree which will end up in the next -mm release.
I'll hold off forwarding this patch to Linus until after 2.6.5 is out,
so that gives everyone a few days in which to argue the name a bunch and
then send me a patch that changes it to the decided apon name (if it is
to be changed.)
thanks,
greg k-h
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 22 March 2004 20:57, Greg KH wrote:
> On Mon, Mar 22, 2004 at 09:50:46AM +1100, Benjamin Herrenschmidt wrote:
> > > I prefere graphics myself. Display sounds to generic. That is what
> > > video and graphics output is piped to. Since fbdev doesn't handle video
> > > ouput normally this is kind of fuzzy sounding.
> >
> > I still prefer display...
>
> Bah, I don't want to argue here. I've applied Kronos's patch as is to
> my device-2.6 tree which will end up in the next -mm release.
>
> I'll hold off forwarding this patch to Linus until after 2.6.5 is out,
> so that gives everyone a few days in which to argue the name a bunch and
> then send me a patch that changes it to the decided apon name (if it is
> to be changed.)
- From a users point of view: if there are only to be framebuffer devices listed
in this class, why not call it just what it is: "Framebuffer" ? Naming it
after something it is only in a broad sense makes no sense to me. I'd be
looking in /sys/.../framebuffer instead of /sys/.../graphics or /display.
Display would be the EDID info of my screen (physical), and graphics...
well... I'd half expect something like capture cards to be there...
Just my 0.02EUR.
Jan
- --
patent:
A method of publicizing inventions so others can copy them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAYBtMUQQOfidJUwQRAugBAJ4jSuhjpzr2jySPGmc6yk4lYflILgCfTB0M
nA8OHiWcRfjRllgoxC/KJBY=
=I8ag
-----END PGP SIGNATURE-----
On Tue, Mar 23, 2004 at 12:11:00PM +0100, Jan De Luyck wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 22 March 2004 20:57, Greg KH wrote:
> > On Mon, Mar 22, 2004 at 09:50:46AM +1100, Benjamin Herrenschmidt wrote:
> > > > I prefere graphics myself. Display sounds to generic. That is what
> > > > video and graphics output is piped to. Since fbdev doesn't handle video
> > > > ouput normally this is kind of fuzzy sounding.
> > >
> > > I still prefer display...
> >
> > Bah, I don't want to argue here. I've applied Kronos's patch as is to
> > my device-2.6 tree which will end up in the next -mm release.
> >
> > I'll hold off forwarding this patch to Linus until after 2.6.5 is out,
> > so that gives everyone a few days in which to argue the name a bunch and
> > then send me a patch that changes it to the decided apon name (if it is
> > to be changed.)
>
> - From a users point of view: if there are only to be framebuffer devices listed
> in this class, why not call it just what it is: "Framebuffer" ? Naming it
> after something it is only in a broad sense makes no sense to me. I'd be
> looking in /sys/.../framebuffer instead of /sys/.../graphics or /display.
Notice that /display is what is used by most OF implementations, so this
kinda makes sense. I would vote like BenH on this if i was consulted.
> Display would be the EDID info of my screen (physical), and graphics...
> well... I'd half expect something like capture cards to be there...
But this also makes sense, still, i guess we are concerned with more
info than just the framebuffer, right ?
Friendly,
Sven Luther
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 23 March 2004 13:26, Sven Luther wrote:
> > - From a users point of view: if there are only to be framebuffer devices
> > listed in this class, why not call it just what it is: "Framebuffer" ?
> > Naming it after something it is only in a broad sense makes no sense to
> > me. I'd be looking in /sys/.../framebuffer instead of /sys/.../graphics
> > or /display.
>
> Notice that /display is what is used by most OF implementations, so this
> kinda makes sense. I would vote like BenH on this if i was consulted.
OF implementations?
>
> > Display would be the EDID info of my screen (physical), and graphics...
> > well... I'd half expect something like capture cards to be there...
>
> But this also makes sense, still, i guess we are concerned with more
> info than just the framebuffer, right ?
Yup. What's in a name indeed. But one might try to make it as non-confusing as
possible.
Kind regards,
Jan De Luyck
- --
Anything is possible on paper.
-- Ron McAfee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAYF9OUQQOfidJUwQRAlUCAJ9gevHf51xYtw7Zu4PAAI3Lq+VvJgCbByUB
c2zgx+ZzG9zKZo/9Lslr76s=
=zzhB
-----END PGP SIGNATURE-----
On Tue, 23 Mar 2004, Jan De Luyck wrote:
> On Tuesday 23 March 2004 13:26, Sven Luther wrote:
> > > - From a users point of view: if there are only to be framebuffer devices
> > > listed in this class, why not call it just what it is: "Framebuffer" ?
> > > Naming it after something it is only in a broad sense makes no sense to
> > > me. I'd be looking in /sys/.../framebuffer instead of /sys/.../graphics
> > > or /display.
> >
> > Notice that /display is what is used by most OF implementations, so this
> > kinda makes sense. I would vote like BenH on this if i was consulted.
>
> OF implementations?
Open Firmware
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
> > I'll hold off forwarding this patch to Linus until after 2.6.5 is out,
> > so that gives everyone a few days in which to argue the name a bunch and
> > then send me a patch that changes it to the decided apon name (if it is
> > to be changed.)
>
> - From a users point of view: if there are only to be framebuffer devices listed
> in this class, why not call it just what it is: "Framebuffer" ? Naming it
> after something it is only in a broad sense makes no sense to me. I'd be
> looking in /sys/.../framebuffer instead of /sys/.../graphics or /display.
>
> Display would be the EDID info of my screen (physical), and graphics...
> well... I'd half expect something like capture cards to be there...
>
> Just my 0.02EUR.
Ug!!!! This is insane. Okay there is a few reason for why I called it
graphics. The number one thing to straighten out is video vs graphics.
There is a big difference between the two. Video cards are meant to
decode or/and encode program or transport streams. Usually that is
mpeg streams. This is what I do for a living. Graphics cards are meant
to display raster or vector graphics objects. It just today alot of
hardware are both so the terms have become mixed up. On the hardware
boards we have at work the video and graphics chip are physically
seperate chips.
Now for the issue of display, framebuffer, or graphics. A framebuffer
is a chunk of memory that is used to create what is displayed. Now that
the fbdev layer has moved to a accelerated framework it is possible to use
non framebuffer devices for fbcon. So it doesn't make sense to call it
that. The name graphics covers the idea best. Especially since fbcon is
meant for "graphical" consoles. As for display. That is just apart of
that. I plan to create a display directory in /sys/graphics so we can
get monitor data.
So lets leave the patch with name graphics alone.