sysfs support for fbdev

Not finished yet but here's an update.

Merges Antonio's fbcon support
Creates monitor device inside of fbdev
Creates two fbdev devices for radeonfb

The changes in class.c are temporary GregKH promises a real fix soon. Patch is 1000+ lines so I made it an attachment.

Making the monitor device inside of the fbdev allows hotplug to work for monitors. Now all I need to do is hook up the radeon interrupt. When finished, unplug the monitor, get interrupt, build monitor device, get hotplug event, helper builds modelist, set modelist to fbdev, this causes sysfs attribute change event, hal then dbus hears this, X rebuilds the display. Still a few weeks of work to go.

If anyone wants to help implement some of the other attributes, send me a patch and I will incorporate it.

Jon Smirl
[email protected]

diff -Nru a/drivers/base/class.c b/drivers/base/class.c
@@ -417,8 +417,9 @@
 
 	/* first, register with generic layer. */
 	kobject_set_name(&class_dev->kobj, "%s", class_dev->class_id);
-	if (parent)
+	if (parent && !class_dev->kobj.parent)
 		class_dev->kobj.parent = &parent->subsys.kset.kobj;
+	class_dev->kobj.parent = kobject_get(class_dev->kobj.parent);
 
 	if ((error = kobject_add(&class_dev->kobj)))
 		goto register_done;

@@ -467,6 +468,7 @@
 	class_device_driver_unlink(class_dev);
 	class_device_remove_attrs(class_dev);
 
+	kobject_put(class_dev->kobj.parent);
 	kobject_del(&class_dev->kobj);
 
 	if (parent)

diff -Nru a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
@@ -270,7 +270,11 @@
 };
 
 struct radeonfb_info {
+	struct fb_info		info2;
 	struct fb_info		*info;
+	
+	struct class_device 	*monitor1;
+	struct class_device 	*monitor2;
 
 	struct radeon_regs 	state;
 	struct radeon_regs	init_state;

diff -Nru a/drivers/video/console/bitblit.c b/drivers/video/console/bitblit.c
@@ -39,7 +39,7 @@
 {
 	int attribute = 0;
 
-	if (fb_get_color_depth(info) == 1) {
+	if (fb_get_color_depth(&info->var) == 1) {
 		if (attr_underline(c))
 			attribute |= FBCON_ATTRIBUTE_UNDERLINE;
 		if (attr_reverse(c))

diff -Nru a/include/linux/fb.h b/include/linux/fb.h
@@ -490,6 +490,8 @@
 #define FB_EVENT_SET_CONSOLE_MAP        0x07
 /*      A display blank is requested       */
 #define FB_EVENT_BLANK                  0x08
+/*      Private modelist is to be replaced */
+#define FB_EVENT_NEW_MODELIST           0x09
 
 struct fb_event {
 	struct fb_info *info;

@@ -712,8 +714,10 @@
 	struct fb_pixmap sprite;	/* Cursor hardware mapper */
 	struct fb_cmap cmap;		/* Current cmap */
 	struct list_head modelist;      /* mode list */
+	struct fb_videomode *mode;	/* current mode */
 	struct fb_ops *fbops;
 	struct device *device;
+	struct class_device *class_device; /* sysfs per device attrs */
 #ifdef CONFIG_FB_TILEBLITTING
 	struct fb_tile_ops *tileops;    /* Tile Blitting */
 #endif

@@ -821,8 +825,9 @@
 				u8 *dst, u32 d_pitch, u8 *src, u32 s_pitch,
 				u32 height);
 extern void fb_set_suspend(struct fb_info *info, int state);
-extern int fb_get_color_depth(struct fb_info *info);
+extern int fb_get_color_depth(struct fb_var_screeninfo *var);
 extern int fb_get_options(char *name, char **option);
+extern int fb_new_modelist(struct fb_info *info);
 
 extern struct fb_info *registered_fb[FB_MAX];
 extern int num_registered_fb;

@@ -830,6 +835,10 @@
 /* drivers/video/fbsysfs.c */
 extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
 extern void framebuffer_release(struct fb_info *info);
+extern void fb_cleanup_class_device(struct fb_info *head);
+extern struct class *fb_create_class(struct module *owner, char *name);
+extern struct class_device *fb_device_add(struct class *cs, struct fb_info *fb_info);
+extern struct class_device *fb_add_child(struct class_device *class_device, struct fb_info *fb_info, const char *fmt, ...);
 
 /* drivers/video/fbmon.c */
 #define FB_MAXTIMINGS		0

@@ -875,6 +884,8 @@
 					  struct list_head *head);
 extern struct fb_videomode *fb_find_best_mode(struct fb_var_screeninfo *var,
 					      struct list_head *head);
+extern struct fb_videomode *fb_find_nearest_mode(struct fb_var_screeninfo *var,
+						 struct list_head *head);
 extern void fb_destroy_modelist(struct list_head *head);
 extern void fb_videomode_to_modelist(struct fb_videomode *modedb, int num,
 				     struct list_head *head);

Barf!!!! This patch is just nasty hack. Okay a run down on the fbdev api. First struct xxx_par is your data structure representing your device. There is one per video card. That is that hook in struct fb_info called par. The idea was xxx_par could be independent of the fbdev layer and could be used DRI. Now for the case of video cards with more than one framebuffer then you have bothe struct fb_info's par point to the same data structure. The verse works as well. Some systems allow multiple video cards hooked up to one montior. Two framebuffers, one display. The structure to deal with that is monspecs in struct fb_info. Now the problem is it is not a pointer :-( I have to fix that with a patch in the near future. If you are going to be messing with montiors work off of struct fb_monspecs.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Have you considered moving all of the monitor support out into a hotplug helper app? This will even work at boot time since early user space is there when fbdev initializes. The helper app would be on initrd just like the boot disk drivers.

Jon Smirl
[email protected]


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Consider the following case. I have high end server with fbcon running as the console. One VC is at a different resolution than another. Now say the system is under really heavy load. When I VC switch I would have to wait until userland sets up the proper mode for me to VC switch. Consider also if userland apps start getting killed. I'm limited to only VCs of the same resolution if that helper app dies :-(

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

It is a helper app, not a daemon, it does not stay running. It also only runs when the monitor is changed - not mode change, monitor changed. On monitor change (loading fbdev counts as a monitor change) the helper is called. The helper reads the DDC, parses it, merges in any updates from /etc/fb.modes (or builds a modelist from fb.modes if no DDC), and then sets this list of legal modes into the driver. After the list is set a hal/dbus event is generated. Doing this is a root only operation.

It can also happen in early user space when the kernel is first booting. Early user space starts before fbcon currently starts. The helper app would be loaded on to initrd or initramfs.

To change a mode, pick one of the mode names from the mode_list and cat it to /sys/graphics/fbX/mode. This will cause the mode to be set and a hal/dbus event to be generated. If you are just running console the mode change event goes into fbcon. Any user can now safely set a mode.

Changing modes does not require a user space helper, only changing monitors (flipping a KVM switch for example).

I have working code for generating the interrupt on monitor change but it isn't ready yet to send out.

This is the complete event sequence....

modprobe card driver
card driver checks if post needed, if so uses a new version of request_firmware() to post
sys/graphics/fbX is added for each head
udev builds /dev/fbX for each head
1) driver locates monitors
creates sys/graphics/fbX/monitor(edid)
creating this causes a hotplug event
root priv hotplug event parses edid merges etc/mode file sets legal modes back into sys/graphics/fbX(mode-list) altering the modelist causes an event hal/dbus can see user space mesa/X reads the mode-list, strings like 1024x768-60 set the one you want back into sys/graphics/fbX(mode) this causes another hal/dbus event

If the card supports an interrupt on monitor change, flipping a KVM switch will restart the process at #1.

Mode lists are generated at root priv.
Pam assigns ownership of mode variable to user This allows a non-root user to safely set the mode

Jon Smirl
[email protected]


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

The question is will work on systems that have no space to write data. Alot of embedded devices can store anything. The fb.modes is very limiting in this case. Having a permanent RAM filesystem is expensive.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

I doubt if a system that constrained needs to change modes at all. In that case just build the mode into the driver and forget everything else.

Jon Smirl
[email protected]


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Doesn't the i830/i915/etc require a user space helper to change modes since that part of the chip spec hasn't been released? The user space helper would use Int10 VBIOS calls to list and set the modes. I haven't worked with these chips, so this is just based off from what has been posted to dri-devel. Is this why we don't have fbdev drivers for these chips?

Jon Smirl
[email protected]


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

drivers/intel/*.[ch]

No user space helper there.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

What about the i915? We don't seem to have a fbdev driver for it yet.

Jon Smirl
[email protected]


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Axel Buttchereit did a patch to implement it. It should be in the
latest mm tree.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

It is (intelfb-...). Including Tony's corresponding "modehelper" kernel-config patch and -- since 2.6.11-rc5-mm1 -- with an additional patch from Andrew that fixes some compiler warnings (missing type casts).

The driver is still not complete (no hardware cursor, ...) but it does its job pretty good (at least on my machine).

Only a few changes are required to add support for i915 and they can all easily be derived from the xorg/xfree-driver that already (fully) supports the chipset.

Obviously there is someone at xfree/xorg that is either a "hell of a hacker" or in the position to access the required documentation from intel. Or both.

:-) Axel

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

There is an intelfb fbdev driver. Not very actively maintained,
sorry for that, but i did a port to kernel 2.6 and try to get some spare time to update it. The driver can change modes and i also did a driver for TV-Out, not yet DFP/LFP (not in the kernel for now).

Sylvain

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

Has Intel released documentation for mode setting on these chips or did you reverse engineer it?

Jon Smirl
[email protected]


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

David Dawes did the original driver. I don't know if he had access
to the datasheet but Intel released documentation for i810/i815 and the chips aren't very different.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

I can already get some of the radeonfb bits in for 2.6.12, that will make things easier. I'll let you know.

Ben.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

More testing first. Plus it should go into Andrews tree first.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click