Re: Patch to add mode setting to sysfs

["Antonino A. Daplas" <adaplas@hotpop.com>]

On Friday 18 February 2005 10:59, Jon Smirl wrote:
> On Fri, 18 Feb 2005 08:04:46 +0800, Antonino A. Daplas
>
> <adaplas@hotpop.com> 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.
>

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