Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Wed, 2003-03-05 at 22:06, Thomas Winischhofer wrote:

> >>However, I could not manage to gain a graphical console if sisfb is a
> >>module, but fbcon is in the kernel. Is this combination supposed to
> >>work? If so, how?
> > 
> > No, fbcon will not load unless there's at least one registered fbdev.
> > So, you must compile sisfb statically too.
> 
> Then this should definitely go into the kernel config rules, I guess :)
> 

I think so, except that fbcon will depend on so many drivers that no one
has the patience to add that to Kconfig yet :-)

> >>a) Calculating the desired mode resolution my simply multiplying the
> >>rows/cols by the font size very often results in odd modes like 800x592.
> >>This even when using a standard 8x16 font, not thinking of situations
> >>where for instance 12x22 fonts are used. How is the low level driver
> >>supposed to handle this?
> > 
> > Ideally, the driver should round up to the nearest mode it's capable
> > of.  The "fraction of a character dimensions" will be automatically
> > cleared by the "clear_margins" hook.
> 
> OK, that's exactly what I do now. I currently tend to the assumption 
> that this mode should be larger than the requested one...?

Yes. If it's smaller, it unconditionally calls fb_set_var(), I think.

> 
> >>To temporarily overcome this, I implemented a somewhat fuzzy mode
> >>identification routine, searching for modes with resolutions within a
> >>range of [desired res] - [desired res + 16]. But I can't imagine this
> >>being the Real Thing.
> > 
> > Yes, that's the Real Thing :-)  fbcon_resize has a "fuzzy mode" too --
> > it won't do an fb_set_var() if the change in dimensions is only a
> > fraction of a character's dimension.
> 
> Ack. Is 16 fuzzy enough, what do you think?

I think you should only accept modes where the difference is a fraction
of a character width or height.  A difference more than that and
clear_margins() will not work correctly.  

> 
> > Right, using stty to change the window size assumes that the fbdev
> > driver has an algorithm to calculate modelines based on xres and yres
> > independently.  This is probably a bit of work for most driver authors.
> 
> Well, not as much work as more a lack of definition. If the user 
> specified a default of 800x600-75 I can't simply assume he also wants 
> 1024x768-75.
> 
> > There's new code in fbmon.c (fb_find_mode and fb_validate_mode) that
> > should ease code writing if you have a VESA GTF compliant monitor.  You
> > can use that if you want as long as the display's operating limits are
> > known (info->monspecs).
> 
> Well, this assumes that the user always want the best refresh rate, 
> which is not desired in all cases.
> 

fb_get_mode() accepts 4 flags.  Maximum refresh rate, hscan-driven,
vrefresh-driven and dotclock-driven calculations.  It's flexible enough,
but of course not as flexible as specifying your own modeline.
  
> > Another solution is to reimplement resizing by fbset.  The code is not
> > very difficult and can be added if most people want it.
> 
> Awaiting public demand :)
> 

> > Yes, this is a limitation of stty.  It calls con_resize twice (one for
> > row and another for cols, depending on the order of the options) so it
> > will not work if the driver only supports a fixed set of modes.  Another
> > reason to bring back fbset resizing.
> 
> Think so, too. That's a really stupid behavior otherwise, since it 
> involves two mode changes, with one really undesired mode on the way.
> 
> > Scrolling mode is now determined by fbcon.  If var->accel_flag is
> > nonzero, scrolling is ypan, otherwise, it's yredraw.  It's because ypan
> > requres a lot of block copy which is slow when done by software.
> > 
> > I still believe though that scrolling should be determined by the
> > driver, not fbcon.
> 
> Well, what should I do now?
> 
> The rivafb only forces y panning (ie sets yres_virtual to maximum) if 
> yres_virtual is -1. This is never the case, as default var is constantly 
> reused and I nowhere saw that any of the res_virtuals was set to -1.
> 

For now, maximize yres_virtual, then set info->var.accel_flag to 1.  It
wouldn't work until fbset support is reimplemented again, unless you
boot directly to that configuration.

I'll wait a few more days in hope of hearing from more people before
submitting a patch.

Tony