From: Jon Smirl <hidden> Date: 2005-02-16 22:31:09
This is a first pass at adding two new sysfs attributes to
/sys/class/graphics/fb0 for setting modes. There are two attributes:
modes which contains a list of valid modes, and mode which is the
current mode. To switch modes echo one of the entries from the modes
list to the mode attribute.
The D,V,S on the modes represents Detailed, Vesa, Standard from the DDC info.
modes is root writable. It can also be used to set the list of modes.
For example a /etc file could add modes that are not in the monitor's
DDC.
mode is user writable. PAM would set ownership of mode at user login
time. This provides a safe way for a user to set the mode without
being root. You can only set the mode to one of the modes on the list.
If this code looks good I'll do another pass that adds some more
features and makes it more robust.
--
Jon Smirl
jonsmirl@gmail.com
diff -Nru a/drivers/video/fbmem.c b/drivers/video/fbmem.c
@@ -1069,13 +1068,15 @@break;fb_info->node=i;-c=class_simple_device_add(fb_class,MKDEV(FB_MAJOR,i),+fb_info->class_device=class_simple_device_add(fb_class,MKDEV(FB_MAJOR,i),fb_info->device,"fb%d",i);-if(IS_ERR(c)){+if(IS_ERR(fb_info->class_device)){/* Not fatal */-printk(KERN_WARNING"Unable to create class_device for framebuffer
%d; errno = %ld\n", i, PTR_ERR(c));
- }
-
+ printk(KERN_WARNING "Unable to create class_device for framebuffer
%d; errno = %ld\n", i, PTR_ERR(fb_info->class_device));
+ fb_info->class_device = NULL;
+ } else
+ fb_init_class_device(fb_info);
+
if (fb_info->pixmap.addr == NULL) {
fb_info->pixmap.addr = kmalloc(FBPIXMAPSIZE, GFP_KERNEL);
if (fb_info->pixmap.addr) {
diff -Nru a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
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
From: James Simmons <hidden> Date: 2005-02-16 22:48:05
Great work!!!! I have been also working on a sysfs patch. We can merge are
work. I have a few more features I want to add to my sysfs patch. Like
allowing a driver to pass in special feature to be exported via sysfs.
Here is what I have currently. Eventually [un]register_framebuffer_sysfs
would become apart of framebuffer_alloc. Well I work one some more stuff.
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/fbmem.c fbdev-2.6/drivers/video/fbmem.c
@@ -1197,11 +1189,7 @@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;-}+fb_sysfs_init();return0;}subsys_initcall(fbmem_init);
@@ -704,6 +704,7 @@structfb_info{intnode;intflags;+structclass_deviceclass_dev;/* Sysfs support */structfb_var_screeninfovar;/* Current var */structfb_fix_screeninfofix;/* Current fix */structfb_monspecsmonspecs;/* Current Monitor specs */
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
From: Jon Smirl <hidden> Date: 2005-02-17 01:28:21
I applied your patch, it makes a new directory,
sys/class/graphics/fb0/modes with two entries dev and name. What is
your mechanism for displaying the list of modes and setting a new one?
Note that you can continue to use class_simple as
class_simple_device_add returns the class_device for the new device.
Give my patch a try, cat 'modes' and you you can see the list of
modes. Echo one to 'mode' and it will set the new mode. The mode set
works without being root.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
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
From: Antonino A. Daplas <hidden> Date: 2005-02-17 13:50:33
On Thursday 17 February 2005 06:30, Jon Smirl wrote:
This is a first pass at adding two new sysfs attributes to
/sys/class/graphics/fb0 for setting modes. There are two attributes:
modes which contains a list of valid modes, and mode which is the
current mode. To switch modes echo one of the entries from the modes
list to the mode attribute.
The D,V,S on the modes represents Detailed, Vesa, Standard from the DDC
info.
modes is root writable. It can also be used to set the list of modes.
For example a /etc file could add modes that are not in the monitor's
DDC.
mode is user writable. PAM would set ownership of mode at user login
time. This provides a safe way for a user to set the mode without
being root. You can only set the mode to one of the modes on the list.
If this code looks good I'll do another pass that adds some more
features and makes it more robust.
Looks very interesting, and I will try it soon. A few comments:
+ fb_videomode_to_var(&var, mode);
+ var.activate |= FB_ACTIVATE_FORCE;
+ var.bits_per_pixel = 32;
Instead of hardcoding some of the fields in var, why not
copy it from the current var? Ie:
var = info->var;
fb_videomode_to_var(&var, mode);
Tony
-------------------------------------------------------
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
From: Jon Smirl <hidden> Date: 2005-02-17 20:49:35
On Thu, 17 Feb 2005 21:50:16 +0800, Antonino A. Daplas
[off-list ref] wrote:
Instead of hardcoding some of the fields in var, why not
copy it from the current var? Ie:
var = info->var;
fb_videomode_to_var(&var, mode);
I added this change, plus more robust error handing. Add attributes
for virtual resolution and bpp.
I also fixed fb so that it works as module.
--
Jon Smirl
jonsmirl@gmail.com
diff -Nru a/drivers/video/Kconfig b/drivers/video/Kconfig
fbsysfs.o modedb.o softcursor.o
+obj-$(CONFIG_FB) += fb.o
+fb-y := fbmem.o fbmon.o fbcmap.o
fbsysfs.o modedb.o softcursor.o
# Only include macmodes.o if we have FB support and are PPC
-ifeq ($(CONFIG_FB),y)
-obj-$(CONFIG_PPC) += macmodes.o
+ifneq ($(CONFIG_FB),n)
+fb-$(CONFIG_PPC) += macmodes.o
endif
+fb-objs := $(fb-y)
# Hardware specific drivers go first
obj-$(CONFIG_FB_RETINAZ3) += retz3fb.o
diff -Nru a/drivers/video/fbmem.c b/drivers/video/fbmem.c
@@ -1069,13 +1068,15 @@break;fb_info->node=i;-c=class_simple_device_add(fb_class,MKDEV(FB_MAJOR,i),+fb_info->class_device=class_simple_device_add(fb_class,MKDEV(FB_MAJOR,i),fb_info->device,"fb%d",i);-if(IS_ERR(c)){+if(IS_ERR(fb_info->class_device)){/* Not fatal */-printk(KERN_WARNING"Unable to create class_device for framebuffer
%d; errno = %ld\n", i, PTR_ERR(c));
- }
-
+ printk(KERN_WARNING "Unable to create class_device for framebuffer
%d; errno = %ld\n", i, PTR_ERR(fb_info->class_device));
+ fb_info->class_device = NULL;
+ } else
+ fb_init_class_device(fb_info);
+
if (fb_info->pixmap.addr == NULL) {
fb_info->pixmap.addr = kmalloc(FBPIXMAPSIZE, GFP_KERNEL);
if (fb_info->pixmap.addr) {
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
From: James Simmons <hidden> Date: 2005-02-17 22:13:43
On Thu, 17 Feb 2005 21:50:16 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
Instead of hardcoding some of the fields in var, why not
copy it from the current var? Ie:
var = info->var;
fb_videomode_to_var(&var, mode);
I added this change, plus more robust error handing. Add attributes
for virtual resolution and bpp.
I also fixed fb so that it works as module.
Seperate the make fbdev modular into another patch. Also I have a feeling
that will open a whole new can of worms. Also please create something
like
static struct attribute *frame_attrs[] = {
&class_device_attr_dev.attr,
&class_device_attr_name.attr,
NULL
};
and do
for (i = 0; i < ARRAY_SIZE(frame_class_device_attributes); i++) {
rc = class_device_create_file(&info->class_dev, frame_class_device_attributes[i]);
if (unlikely(rc)) {
/* Not fatal */
printk(KERN_WARNING "Unable to create device file for framebuffer %d\n", info->node);
}
}
Did you see me email with my ideas about the sysfs structure?
-------------------------------------------------------
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
From: Antonino A. Daplas <hidden> Date: 2005-02-18 00:05:01
On Friday 18 February 2005 04:49, Jon Smirl wrote:
On Thu, 17 Feb 2005 21:50:16 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
Instead of hardcoding some of the fields in var, why not
copy it from the current var? Ie:
var = info->var;
fb_videomode_to_var(&var, mode);
I added this change, plus more robust error handing. Add attributes
for virtual resolution and bpp.
I also fixed fb so that it works as module.
If possible, separate the sysfs patch from making fbcore as module.
+static ssize_t store_modes(struct class_device *class_device, const
char * buf, size_t count)
+{
+ struct fb_info *fb_info = (struct fb_info *)class_get_devdata(class_device);
+ int i = count / sizeof(struct fb_videomode);
+ if (i * sizeof(struct fb_videomode) != count)
+ return -EINVAL;
+
+ fb_destroy_modelist(&fb_info->modelist);
This is dangerous. For one, if the mode in info->var does not match any of
the entries in the modelist, you can get a screwed up display. Secondly,
fbcon refers to info->modelist to store settings for each console. Thus
it is better to check first if the mode in the modelist is currently in use.
A safer way is to loop through each entries of the old modelist, call
fb_set_var() with the FB_ACTIVATE_INV_MODE set in var->activate. This
process will safely remove each mode from the modelist. Not all entries
will be deleted of course. After that, loop through each entries of the new
modedb array, and use fb_add_videomode() to add each entry to the modelist.
Tony
-------------------------------------------------------
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
fbsysfs.o modedb.o softcursor.o
+obj-$(CONFIG_FB) += fb.o
+fb-y := fbmem.o fbmon.o fbcmap.o
fbsysfs.o modedb.o softcursor.o
# Only include macmodes.o if we have FB support and are PPC
-ifeq ($(CONFIG_FB),y)
-obj-$(CONFIG_PPC) += macmodes.o
+ifneq ($(CONFIG_FB),n)
+fb-$(CONFIG_PPC) += macmodes.o
endif
+fb-objs := $(fb-y)
# Hardware specific drivers go first
obj-$(CONFIG_FB_RETINAZ3) += retz3fb.o
diff -Nru a/drivers/video/fbmem.c b/drivers/video/fbmem.c
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
From: Jon Smirl <hidden> Date: 2005-02-18 02:59:36
On Fri, 18 Feb 2005 08:04:46 +0800, Antonino A. Daplas
[off-list ref] wrote:
This is dangerous. For one, if the mode in info->var does not match any of
the entries in the modelist, you can get a screwed up display. Secondly,
fbcon refers to info->modelist to store settings for each console. Thus
it is better to check first if the mode in the modelist is currently in use.
A safer way is to loop through each entries of the old modelist, call
fb_set_var() with the FB_ACTIVATE_INV_MODE set in var->activate. This
process will safely remove each mode from the modelist. Not all entries
will be deleted of course. After that, loop through each entries of the new
modedb array, and use fb_add_videomode() to add each entry to the modelist.
Radeon hardware has an interrupt that is not hooked up in radeonfb
that can tell if the monitor has been switched. Hook a radeon to a KVM
switch and flip the switch. We should get an interrupt. Use the
interrupt to trigger a hotplug event. Hotplug event will set a new
list of modes into radeonfb. All of the old modes have to be deleted,
they probably don't exist in the new monitor.
At this point fbcon needs to get a modelist change event. It can then
find_mode() to find a new mode that is close to what it was using. So
the problem seems to be that disp->mode holds a pointer to the mode
instead of a copy of the mode. I'll try changing this to a copy. Does
fbcon really need to know the entire mode structure or could it work
with just the resolution?
I'd feel more comfortable if fbcon used a well defined interface to
fbdev instead of having access to all of fbdev's internal structures.
I tried modifying fbcon to use DRM but it is completely tied to fbdev.
Anyway, the current code is much better than it was in 2.4.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
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
From: Jon Smirl <hidden> Date: 2005-02-18 07:27:44
Next version of sysfs patch. Fills out more attributes. Feel free to
add code for missing implementations. Modifies fbcon to copy mode
structure instead of taking a reference to it. Modular fbdev is
separate patch. Ultimately we should be able to eliminate the IOCTL
code from fb_core and move it to a compatibility module.
--
Jon Smirl
jonsmirl@gmail.com
diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
@@ -693,17 +695,18 @@disp->green=var->green;disp->blue=var->blue;disp->transp=var->transp;-disp->mode=fb_match_mode(var,&info->modelist);-if(disp->mode==NULL)+mode=fb_match_mode(var,&info->modelist);+if(mode==NULL)/* This should not happen */return-EINVAL;+disp->mode=*mode;return0;}staticvoiddisplay_to_var(structfb_var_screeninfo*var,structdisplay*disp){-fb_videomode_to_var(var,disp->mode);+fb_videomode_to_var(var,&disp->mode);var->xres_virtual=disp->xres_virtual;var->yres_virtual=disp->yres_virtual;var->bits_per_pixel=disp->bits_per_pixel;
@@ -1069,13 +1068,15 @@break;fb_info->node=i;-c=class_simple_device_add(fb_class,MKDEV(FB_MAJOR,i),+fb_info->class_device=class_simple_device_add(fb_class,MKDEV(FB_MAJOR,i),fb_info->device,"fb%d",i);-if(IS_ERR(c)){+if(IS_ERR(fb_info->class_device)){/* Not fatal */-printk(KERN_WARNING"Unable to create class_device for framebuffer
%d; errno = %ld\n", i, PTR_ERR(c));
- }
-
+ printk(KERN_WARNING "Unable to create class_device for framebuffer
%d; errno = %ld\n", i, PTR_ERR(fb_info->class_device));
+ fb_info->class_device = NULL;
+ } else
+ fb_init_class_device(fb_info);
+
if (fb_info->pixmap.addr == NULL) {
fb_info->pixmap.addr = kmalloc(FBPIXMAPSIZE, GFP_KERNEL);
if (fb_info->pixmap.addr) {
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
From: Antonino A. Daplas <hidden> Date: 2005-02-18 07:31:24
On Friday 18 February 2005 10:59, Jon Smirl wrote:
On Fri, 18 Feb 2005 08:04:46 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
This is dangerous. For one, if the mode in info->var does not match any
of the entries in the modelist, you can get a screwed up display.
Secondly, fbcon refers to info->modelist to store settings for each
console. Thus it is better to check first if the mode in the modelist is
currently in use.
A safer way is to loop through each entries of the old modelist, call
fb_set_var() with the FB_ACTIVATE_INV_MODE set in var->activate. This
process will safely remove each mode from the modelist. Not all entries
will be deleted of course. After that, loop through each entries of the
new modedb array, and use fb_add_videomode() to add each entry to the
modelist.
Radeon hardware has an interrupt that is not hooked up in radeonfb
that can tell if the monitor has been switched. Hook a radeon to a KVM
switch and flip the switch. We should get an interrupt. Use the
interrupt to trigger a hotplug event. Hotplug event will set a new
list of modes into radeonfb. All of the old modes have to be deleted,
they probably don't exist in the new monitor.
Just trying to point out that destroying the modelist is not entirely safe.
At this point fbcon needs to get a modelist change event. It can then
find_mode() to find a new mode that is close to what it was using. So
the problem seems to be that disp->mode holds a pointer to the mode
instead of a copy of the mode. I'll try changing this to a copy. Does
Whether it's a copy or a pointer does not matter anyway, because fbcon
still need to resize each console using the new modelist.
fbcon really need to know the entire mode structure or could it work
with just the resolution?
fbcon only needs xres, yres, vxres and vyres. But in order to preserve
the graphics state per console, everything in var is required.
I'd feel more comfortable if fbcon used a well defined interface to
fbdev instead of having access to all of fbdev's internal structures.
The 2.6 code is already a big step compared to 2.4, and most of the bugs
plaguing fbcon/fbcore has been ironed out. I don't want a new interface
again until after things settle down a bit more and drivers get updated to
the new core.
Anyway, you can code the part where a new modelist is to be created. Then
send an event that the entire modelist is to be changed, passing the fb_info
structure and the new modelist. fbcon captures the event (and I'll code
this part where fbcon starts using the new modelist and resizes each
console). After which, the old modelist can be destroyed.
Sample code:
struct fb_event event;
/* create new_modelist */
event.info = info;
event.data = new_modelist;
notifier_call_chain(&fb_notifier_list, FB_EVENT_NEW_MODELIST, &event);
/*destroy old_modelist */
Tony
-------------------------------------------------------
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
From: Antonino A. Daplas <hidden> Date: 2005-02-18 07:43:05
On Friday 18 February 2005 15:27, Jon Smirl wrote:
Next version of sysfs patch. Fills out more attributes. Feel free to
add code for missing implementations. Modifies fbcon to copy mode
structure instead of taking a reference to it. Modular fbdev is
separate patch. Ultimately we should be able to eliminate the IOCTL
code from fb_core and move it to a compatibility module.
Okay, I think I can start coding starting from this patch.
Thanks for the work Jon.
Tony
-------------------------------------------------------
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
From: Antonino A. Daplas <hidden> Date: 2005-02-18 08:27:54
On Friday 18 February 2005 15:27, Jon Smirl wrote:
Next version of sysfs patch. Fills out more attributes. Feel free to
add code for missing implementations. Modifies fbcon to copy mode
structure instead of taking a reference to it. Modular fbdev is
Modifying fbcon to get a copy of the mode still won't work. What if
the consoles are at 1600x1200, and then you plug in a new monitor
capable only of 1024x768 max? So you still need to send an
event, and fbcon needs to capture this event so it can resize the
consoles to fit the new monitor.
Tony
-------------------------------------------------------
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
On Friday 18 February 2005 10:59, Jon Smirl wrote:
quoted
fbcon really need to know the entire mode structure or could it work
with just the resolution?
fbcon only needs xres, yres, vxres and vyres. But in order to preserve
the graphics state per console, everything in var is required.
And visual/color depth (for modes `less' than 16 colors).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
-------------------------------------------------------
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
From: Jon Smirl <hidden> Date: 2005-02-18 16:46:26
On Fri, 18 Feb 2005 15:42:50 +0800, Antonino A. Daplas
[off-list ref] wrote:
On Friday 18 February 2005 15:27, Jon Smirl wrote:
quoted
Next version of sysfs patch. Fills out more attributes. Feel free to
add code for missing implementations. Modifies fbcon to copy mode
structure instead of taking a reference to it. Modular fbdev is
separate patch. Ultimately we should be able to eliminate the IOCTL
code from fb_core and move it to a compatibility module.
Okay, I think I can start coding starting from this patch.
Do you want to take over the sysfs support? If so, I will make some
changes to the radeonfb driver that I need. That will keep up from
conflicting.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
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
From: Antonino A. Daplas <hidden> Date: 2005-02-18 22:00:15
On Saturday 19 February 2005 00:46, Jon Smirl wrote:
On Fri, 18 Feb 2005 15:42:50 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
On Friday 18 February 2005 15:27, Jon Smirl wrote:
quoted
Next version of sysfs patch. Fills out more attributes. Feel free to
add code for missing implementations. Modifies fbcon to copy mode
structure instead of taking a reference to it. Modular fbdev is
separate patch. Ultimately we should be able to eliminate the IOCTL
code from fb_core and move it to a compatibility module.
Okay, I think I can start coding starting from this patch.
Do you want to take over the sysfs support? If so, I will make some
changes to the radeonfb driver that I need. That will keep up from
conflicting.
Actually, I plan to do the fbcon part only, capturing the event. I'll use
yours as the test bed, but you and James will have to agree on the best way
to add sysfs support to the fb core.
Tony
-------------------------------------------------------
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
From: James Simmons <hidden> Date: 2005-02-21 18:37:56
Here is a question. What about if the drivers are built and fbdev is
modular? I will have to try it to see the results.
On Thu, 17 Feb 2005, Jon Smirl wrote:
quoted hunk
On Fri, 18 Feb 2005 08:04:46 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
If possible, separate the sysfs patch from making fbcore as module.
Split for making fbcore into a module. It's pretty minor.
--
Jon Smirl
jonsmirl@gmail.com
diff -Nru a/drivers/video/Kconfig b/drivers/video/Kconfig
fbsysfs.o modedb.o softcursor.o
+obj-$(CONFIG_FB) += fb.o
+fb-y := fbmem.o fbmon.o fbcmap.o
fbsysfs.o modedb.o softcursor.o
# Only include macmodes.o if we have FB support and are PPC
-ifeq ($(CONFIG_FB),y)
-obj-$(CONFIG_PPC) += macmodes.o
+ifneq ($(CONFIG_FB),n)
+fb-$(CONFIG_PPC) += macmodes.o
endif
+fb-objs := $(fb-y)
# Hardware specific drivers go first
obj-$(CONFIG_FB_RETINAZ3) += retz3fb.o
diff -Nru a/drivers/video/fbmem.c b/drivers/video/fbmem.c
-------------------------------------------------------
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
From: James Simmons <hidden> Date: 2005-02-21 18:55:28
quoted
Do you want to take over the sysfs support? If so, I will make some
changes to the radeonfb driver that I need. That will keep up from
conflicting.
Actually, I plan to do the fbcon part only, capturing the event. I'll use
yours as the test bed, but you and James will have to agree on the best way
to add sysfs support to the fb core.
We are attempting to work that out. Right now also I'm working on resource
management for fbdev. I have a patch coming but it needs work. I consider
it more important that sysfs right now. I will be sending the first run at
that resource management today.
-------------------------------------------------------
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
From: Jon Smirl <hidden> Date: 2005-02-21 19:11:19
On Mon, 21 Feb 2005 18:37:45 +0000 (GMT), James Simmons
[off-list ref] wrote:
Here is a question. What about if the drivers are built and fbdev is
modular? I will have to try it to see the results.
If a driver is built in you can't use fb as a module. Kernel kconfig
controls this automatically for you. If you pick fb as a module you
will only get modules as a choice on the drivers. If you pick built in
you can build the drivers either way. You can't compile fb as a module
and have built in drivers, the kernel will refuse to build.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
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
From: Jon Smirl <hidden> Date: 2005-02-21 19:13:12
On Mon, 21 Feb 2005 18:55:23 +0000 (GMT), James Simmons
[off-list ref] wrote:
We are attempting to work that out. Right now also I'm working on resource
management for fbdev. I have a patch coming but it needs work. I consider
it more important that sysfs right now. I will be sending the first run at
that resource management today.
The work on framebuffer is being driven by our goal of demoing
XGL/mesa-solo/DRM&fbdev at OLS this summer. The sysfs code is a key
part of being able to set modes without being root.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
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
From: James Simmons <hidden> Date: 2005-02-21 21:17:07
[off-list ref] wrote:
quoted
Here is a question. What about if the drivers are built and fbdev is
modular? I will have to try it to see the results.
If a driver is built in you can't use fb as a module. Kernel kconfig
controls this automatically for you. If you pick fb as a module you
will only get modules as a choice on the drivers. If you pick built in
you can build the drivers either way. You can't compile fb as a module
and have built in drivers, the kernel will refuse to build.
So kbuild is smart enough to handle this. In the old days you could break
the build.
-------------------------------------------------------
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
From: Antonino A. Daplas <hidden> Date: 2005-02-21 23:13:36
On Saturday 19 February 2005 05:59, Antonino A. Daplas wrote:
On Saturday 19 February 2005 00:46, Jon Smirl wrote:
quoted
On Fri, 18 Feb 2005 15:42:50 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
On Friday 18 February 2005 15:27, Jon Smirl wrote:
quoted
Next version of sysfs patch. Fills out more attributes. Feel free to
add code for missing implementations. Modifies fbcon to copy mode
structure instead of taking a reference to it. Modular fbdev is
separate patch. Ultimately we should be able to eliminate the IOCTL
code from fb_core and move it to a compatibility module.
Okay, I think I can start coding starting from this patch.
Do you want to take over the sysfs support? If so, I will make some
changes to the radeonfb driver that I need. That will keep up from
conflicting.
Actually, I plan to do the fbcon part only, capturing the event. I'll use
yours as the test bed, but you and James will have to agree on the best way
to add sysfs support to the fb core.
Attached are 2 test patches. The first (fbsysfs.diff) is Jon's practically
unmodified code, but with cosmetic changes and the mode copy reverted back
to mode pointer (I prefer the pointer since it will crash rather than
silently fail if there's a bug, besides consuming less memory).
The second patch (fbcon-new-modelist.diff) adds a new event,
FB_EVENT_NEW_MODELIST. This is sent by store_modes() via fb_new_modelist().
The event is captured by fbcon and resizes all consoles based on the new
modelist.
Tony
From: Antonino A. Daplas <hidden> Date: 2005-02-21 23:15:31
On Tuesday 22 February 2005 07:13, Antonino A. Daplas wrote:
On Saturday 19 February 2005 05:59, Antonino A. Daplas wrote:
quoted
On Saturday 19 February 2005 00:46, Jon Smirl wrote:
quoted
On Fri, 18 Feb 2005 15:42:50 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
On Friday 18 February 2005 15:27, Jon Smirl wrote:
quoted
Next version of sysfs patch. Fills out more attributes. Feel free
to add code for missing implementations. Modifies fbcon to copy
mode structure instead of taking a reference to it. Modular fbdev
is separate patch. Ultimately we should be able to eliminate the
IOCTL code from fb_core and move it to a compatibility module.
Okay, I think I can start coding starting from this patch.
Do you want to take over the sysfs support? If so, I will make some
changes to the radeonfb driver that I need. That will keep up from
conflicting.
Actually, I plan to do the fbcon part only, capturing the event. I'll use
yours as the test bed, but you and James will have to agree on the best
way to add sysfs support to the fb core.
Attached are 2 test patches. The first (fbsysfs.diff) is Jon's practically
unmodified code, but with cosmetic changes and the mode copy reverted back
to mode pointer (I prefer the pointer since it will crash rather than
silently fail if there's a bug, besides consuming less memory).
The second patch (fbcon-new-modelist.diff) adds a new event,
FB_EVENT_NEW_MODELIST. This is sent by store_modes() via
fb_new_modelist(). The event is captured by fbcon and resizes all consoles
based on the new modelist.
Grr, fbcon-new-modelist.diff contains the diffstat only. Here's the new patch.
Tony
diff -Nru a/drivers/video/console/bitblit.c b/drivers/video/console/bitblit.c
@@ -493,6 +493,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 0x09structfb_event{structfb_info*info;
-------------------------------------------------------
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
From: Jon Smirl <hidden> Date: 2005-02-25 00:05:07
On Tue, 22 Feb 2005 07:15:13 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
Attached are 2 test patches. The first (fbsysfs.diff) is Jon's practically
unmodified code, but with cosmetic changes and the mode copy reverted back
to mode pointer (I prefer the pointer since it will crash rather than
silently fail if there's a bug, besides consuming less memory).
The second patch (fbcon-new-modelist.diff) adds a new event,
FB_EVENT_NEW_MODELIST. This is sent by store_modes() via
fb_new_modelist(). The event is captured by fbcon and resizes all consoles
based on the new modelist.
What are you diffing this against? I don't have an nvidia fbdev driver
in my Linus bk tree.
Can you regenerate against Linus bk plus my sysfs.patch?
--
Jon Smirl
jonsmirl@gmail.com