Some questions

Some questions

[Thomas Winischhofer]

I am currently porting the SiS framebuffer driver to the - more or less
- new API. Better late than never :)

Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for
development, no fbdev patches)

1) Sisfb currently does not work if compiled statically into the kernel.
(It works as a module if fbcon is a module, too). If sisfb and fbcon are
the kernel, the mode switch occures but the only thing I see is a white
rectangle at the left egde of the screen, vertically centered, with some
flashing grey dots. I almost looks like text mode output while in
graphics mode, or - better - if fbcon assumes a font size of 1 pixel.
Finally, it seems to oops, but I can't say that for sure because I don't
see anything (and I unfortunately don't have a serial console available).

Can anybody confirm that this (ie both low level driver and fbcon in
kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
implementation)? Did I perhaps miss anything, like a kernel parameter to
activate fbcon or similar?

2) If both sisfb and fbcon are modules, everything works s supposed when
first modprobing sisfb and then fbcon. Upon modprobing fbcon, the mode
switch occures and I see a graphical console (with a white rectangle of
the size of the previous console size which vanishes upon pressing enter).

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?

3) The resizing using stty is - how do I put this - slightly imperfect.
I don't know how you fbdev folks do it, but I am not used to think in
row/col categories, but *resolutions* instead. Apart from this - IMHO a
bit annoying - inconvenience, this method has further issues:

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?

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.

b) The call to fb_set_var() inside fbcon_resize() is checked for errors,
but not the call to fbcon_resize() from within fbcon_switch(). This
leads to catastrophic drawing errors if the requested mode is not
supported by the low level driver.

c) fbcon_resize() only changes var.xres and var.yres, leaving everything
else - var.pixclock, for instance - alone. fb_set_var() just calles the
driver's check_var() routine and then set_par(). How is the low level
driver supposed to behave in this situation, especially considering the
unchanged pixclock?

d) Starting with a mode of 1024x768 and resizing to 800x600 using stty
works after all (see a)), but only if I execute stty twice. The desired
mode the low level driver receives at the first attempt is 800x768.
Could this be related to an outdated or buggy stty, calling the console
code twice if rows and cols are specified at the same time...?

3) About y panning: In the 2.4 version of sisfb, I simply forced the
console to do y panning (unless positively disabled by the user) by
"patching" yres_virtual to the maximum, depending on the available video
memory. I am allowed to do that with the 2.5 API? (The rivafb code makes
be believe so...)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 20:18, Thomas Winischhofer wrote:
> I am currently porting the SiS framebuffer driver to the - more or less
> - new API. Better late than never :)
> 
> Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for
> development, no fbdev patches)
> 
> 1) Sisfb currently does not work if compiled statically into the kernel.
> (It works as a module if fbcon is a module, too). If sisfb and fbcon are
> the kernel, the mode switch occures but the only thing I see is a white
> rectangle at the left egde of the screen, vertically centered, with some
> flashing grey dots. I almost looks like text mode output while in
> graphics mode, or - better - if fbcon assumes a font size of 1 pixel.
> Finally, it seems to oops, but I can't say that for sure because I don't
> see anything (and I unfortunately don't have a serial console available).
> 
> Can anybody confirm that this (ie both low level driver and fbcon in
> kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
> implementation)? Did I perhaps miss anything, like a kernel parameter to
> activate fbcon or similar?

Yes, it it does work.

> 
> 2) If both sisfb and fbcon are modules, everything works s supposed when
> first modprobing sisfb and then fbcon. Upon modprobing fbcon, the mode
> switch occures and I see a graphical console (with a white rectangle of
> the size of the previous console size which vanishes upon pressing enter).

Ideally, fbdev should only change the video mode on the first fb_open()
or fb_set_par() and restore the state on the last fb_close().  This is
so you can load fbdev without having a framebuffer console.  If memory
serves me correctly, that's how sisfb in 2.4 works?.

> 
> 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.

> 
> 3) The resizing using stty is - how do I put this - slightly imperfect.
> I don't know how you fbdev folks do it, but I am not used to think in
> row/col categories, but *resolutions* instead. Apart from this - IMHO a
> bit annoying - inconvenience, this method has further issues:
> 
> 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.

> 
> 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.

> 
> b) The call to fb_set_var() inside fbcon_resize() is checked for errors,
> but not the call to fbcon_resize() from within fbcon_switch(). This
> leads to catastrophic drawing errors if the requested mode is not
> supported by the low level driver.

Yes, it's a bug.  I think I submitted a patch to fix that, but I'm not
sure if James applied it to his tree.

> 
> c) fbcon_resize() only changes var.xres and var.yres, leaving everything
> else - var.pixclock, for instance - alone. fb_set_var() just calles the
> driver's check_var() routine and then set_par(). How is the low level
> driver supposed to behave in this situation, especially considering the
> unchanged pixclock?
> 

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. 
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).

Another solution is to reimplement resizing by fbset.  The code is not
very difficult and can be added if most people want it.

> d) Starting with a mode of 1024x768 and resizing to 800x600 using stty
> works after all (see a)), but only if I execute stty twice. The desired
> mode the low level driver receives at the first attempt is 800x768.
> Could this be related to an outdated or buggy stty, calling the console
> code twice if rows and cols are specified at the same time...?

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.

> 
> 3) About y panning: In the 2.4 version of sisfb, I simply forced the
> console to do y panning (unless positively disabled by the user) by
> "patching" yres_virtual to the maximum, depending on the available video
> memory. I am allowed to do that with the 2.5 API? (The rivafb code makes
> be believe so...)

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.

Tony 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>>Can anybody confirm that this (ie both low level driver and fbcon in
>>kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
>>implementation)? Did I perhaps miss anything, like a kernel parameter to
>>activate fbcon or similar?
> 
> Yes, it it does work.

OK, now it works here, too. Seems my debug-printks during initialisation 
made the kernel go bananas. As soon as I removed them, it walks along...

But I noticed another issue here:

When switching to gfx mode during boot (ie as soon as the penguin 
appears), the text console is aligned correctly at all edges, with all 
lines visible.

But when "initial console" starts, the mode is again changed, and now 
the last line of text is nearly invisible, its upper half appears at the 
lower screen edge, the lower half is below the screen's edge. The space 
between the penguin and the text is notably thicker.

This can be recovered by switching to another VT and back. This makes 
the penguin disappear, and restores the console dimensions/edges to normal.

Interestingly, this only happens with 800x600; this mode is chosen upon 
requesting 800x592 (because of the font size). At 1024x768, everything 
is as it should.

>>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 :)

>>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...?

>>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?

> 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.

> 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.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Antonino Daplas]

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




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>>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.  

How do I - from a low level fb driver - determine the character size?

>>>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.

That's what I do.

(shifted boot screen)
 >>I am almost sure that this has to do with the fact that I adapt var in
 >>my check_var from 800x592 to 800x600. Console (or whoever) seems to
 >>attempt to change the mode to its initially desired dimension on many
 >>occasions.
 >
 > Strange.  If you boot at 800x600, the console will compute that as
 > 100x37.  On fbcon_resize, it will request 800x592 but because the
 > difference is only 8, fb_set_var should be skipped, so no mode change
 > should happen throughout.

But it definitely does. I can see this on my LCD (which goes dark during 
mode changes) and, of course, the log.

 > I have no idea.  I booted with other drivers at 800x600 and get no ill
 > effects.  I get a margin at the bottom of 8 pixels.
 >
 > How about checking what the offsets are during fb_pan_display()?

Done that. Nothing special; The penguin is where it should be, but the 
text below starts 8 lines too low.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> >>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.  
> 
> How do I - from a low level fb driver - determine the character size?

You cannot. That's called fbcon-fbdev separation.

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> 
>>Antonino Daplas wrote:
>>
>>>>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.  
>>
>>How do I - from a low level fb driver - determine the character size?
> 
> 
> You cannot. That's called fbcon-fbdev separation.

My question was, basically, meant ironic.

But this is funny: You tell me that the difference should not exceed the 
fraction of a character, but it is impossible to find out how wide/tall 
characters are.

Guys, that won't work. I have to deal with LCD displays and TV output as 
well (not to say "mainly") and I can't just set up odd modes like 
800x592, or mode resolutions based on calculations with any possible odd 
font dimension.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> >>Antonino Daplas wrote:
> >>>>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.  
> >>
> >>How do I - from a low level fb driver - determine the character size?
> > 
> > 
> > You cannot. That's called fbcon-fbdev separation.
> 
> My question was, basically, meant ironic.
> 
> But this is funny: You tell me that the difference should not exceed the 
> fraction of a character, but it is impossible to find out how wide/tall 
> characters are.
> 
> Guys, that won't work. I have to deal with LCD displays and TV output as 
> well (not to say "mainly") and I can't just set up odd modes like 
> 800x592, or mode resolutions based on calculations with any possible odd 
> font dimension.

Indeed. That's why fbcon should adapt to fbdev, and not vice versa (IMHO).

I've always been a bit skeptical about the fbcon-driven fbdev-resizing...
I don't mind that you change the resolution or fontsize, but it should not
influence the fbdev too much.

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 23:59, Thomas Winischhofer wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> > 
> >>Antonino Daplas wrote:
> >>
> >>>>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.  
> >>
> >>How do I - from a low level fb driver - determine the character size?
> > 
> > 
> > You cannot. That's called fbcon-fbdev separation.
> 
> My question was, basically, meant ironic.
> 
> But this is funny: You tell me that the difference should not exceed the 
> fraction of a character, but it is impossible to find out how wide/tall 
> characters are.
> 
> Guys, that won't work. I have to deal with LCD displays and TV output as 
> well (not to say "mainly") and I can't just set up odd modes like 
> 800x592, or mode resolutions based on calculations with any possible odd 
> font dimension.
> 

Yes, using stty is indeed limited.  This was implemented because midway
during development, when fbdev was completely separated from fbcon,
there was no way to resize the window at all.  The first solution was to
use stty, better it than none at all.  It did confuse a lot of people,
especially since not all drivers support changing the resolution without
help from the user.

Anyway, I have already brought fbset support back in my local copy :-)
As I've mentioned, I'll just wait for more replies to the "Feature
Freeze?" thread, and I'll submit a test patch.  

Tony

> Thomas
> 
> -- 
> Thomas Winischhofer
> Vienna/Austria
> mailto:thomas@winischhofer.net            http://www.winischhofer.net/
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 23:37, Thomas Winischhofer wrote:

> (shifted boot screen)
>  >>I am almost sure that this has to do with the fact that I adapt var in
>  >>my check_var from 800x592 to 800x600. Console (or whoever) seems to
>  >>attempt to change the mode to its initially desired dimension on many
>  >>occasions.
>  >
>  > Strange.  If you boot at 800x600, the console will compute that as
>  > 100x37.  On fbcon_resize, it will request 800x592 but because the
>  > difference is only 8, fb_set_var should be skipped, so no mode change
>  > should happen throughout.
> 
> But it definitely does. I can see this on my LCD (which goes dark during 
> mode changes) and, of course, the log.
> 
>  > I have no idea.  I booted with other drivers at 800x600 and get no ill
>  > effects.  I get a margin at the bottom of 8 pixels.
>  >
>  > How about checking what the offsets are during fb_pan_display()?
> 
> Done that. Nothing special; The penguin is where it should be, but the 
> text below starts 8 lines too low.
> 

How about removing fbcon_resize() from fbcon_switch()?  This should at
least give you an idea where the problem is (fbcon_resize, or somewhere
else)

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>> > Strange.  If you boot at 800x600, the console will compute that as
>> > 100x37.  On fbcon_resize, it will request 800x592 but because the
>> > difference is only 8, fb_set_var should be skipped, so no mode change
>> > should happen throughout.
>>
>>But it definitely does. I can see this on my LCD (which goes dark during 
>>mode changes) and, of course, the log.

Just check this with the newest versions from fbdev at bk. In my code 
(which is, as I said in the beginning, the stock 2.5.63 kernel), 
fbcon_resize does NO check whatsoever. It stupidly calls set_var().

I think that might be one reason for what I see :)

Now for a plain dumb question: Is there a patch available to update my 
kernel tree to the latest fbdev stuff? (I don't intend to spend much 
time with bk)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 00:17, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> >> > Strange.  If you boot at 800x600, the console will compute that as
> >> > 100x37.  On fbcon_resize, it will request 800x592 but because the
> >> > difference is only 8, fb_set_var should be skipped, so no mode change
> >> > should happen throughout.
> >>
> >>But it definitely does. I can see this on my LCD (which goes dark during 
> >>mode changes) and, of course, the log.
> 
> Just check this with the newest versions from fbdev at bk. In my code 
> (which is, as I said in the beginning, the stock 2.5.63 kernel), 
> fbcon_resize does NO check whatsoever. It stupidly calls set_var().

Of course.  My tree is so modified that I forgot that Jame's latest
patch was not yet applied to the main tree :-)
> 
> I think that might be one reason for what I see :)

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Note that there is still a bug in fbcon_resize().

1.  in fbcon_resize(), p->vrows must be updated unconditionally

2.  fbcon_resize() in fbcon_switch() must be moved higher up the code,
preferably before the scroll_phys_max calculation.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On 6 Mar 2003, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 00:17, Thomas Winischhofer wrote:
> > Antonino Daplas wrote:
> > >> > Strange.  If you boot at 800x600, the console will compute that as
> > >> > 100x37.  On fbcon_resize, it will request 800x592 but because the
> > >> > difference is only 8, fb_set_var should be skipped, so no mode change
> > >> > should happen throughout.
> > >>
> > >>But it definitely does. I can see this on my LCD (which goes dark during 
> > >>mode changes) and, of course, the log.
> > 
> > Just check this with the newest versions from fbdev at bk. In my code 
> > (which is, as I said in the beginning, the stock 2.5.63 kernel), 
> > fbcon_resize does NO check whatsoever. It stupidly calls set_var().
> 
> Of course.  My tree is so modified that I forgot that Jame's latest
> patch was not yet applied to the main tree :-)
> > 
> > I think that might be one reason for what I see :)
> 
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Note that this patch is dated Feb 20. In the mean time James applied at least
your accel_putcs() optimizations and my logo updates.

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> 
> Note that this patch is dated Feb 20. In the mean time James applied at least
> your accel_putcs() optimizations and my logo updates.

Please note I just release a new patch. Please try it out.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > I think that might be one reason for what I see :)
> 
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> 
> Note that there is still a bug in fbcon_resize().
> 
> 1.  in fbcon_resize(), p->vrows must be updated unconditionally

Applied in latest patch.
 
> 2.  fbcon_resize() in fbcon_switch() must be moved higher up the code,
> preferably before the scroll_phys_max calculation.

Do you have a patch?



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On 5 Mar 2003, Antonino Daplas wrote:
> On Wed, 2003-03-05 at 22:06, Thomas Winischhofer wrote:
> > > 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.  

Indeed, accel_clear_margins() calculates the margins as

    unsigned int cw = vc->vc_font.width;
    unsigned int ch = vc->vc_font.height;
    unsigned int rw = info->var.xres % cw;
    unsigned int bh = info->var.yres % ch;

However, if it would use

    unsigned int rw = info->var.xres - (vc->vc_cols*cw);
    unsigned int bh = info->var.yres - (vc->vc_rows*ch);

it would work with higher differences, too. And it would be a bit faster
(multiply and subtract vs. modulo).

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 23:40, Geert Uytterhoeven wrote:
> On 5 Mar 2003, Antonino Daplas wrote:
> > On Wed, 2003-03-05 at 22:06, Thomas Winischhofer wrote:
> > > > 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.  
> 
> Indeed, accel_clear_margins() calculates the margins as
> 
>     unsigned int cw = vc->vc_font.width;
>     unsigned int ch = vc->vc_font.height;
>     unsigned int rw = info->var.xres % cw;
>     unsigned int bh = info->var.yres % ch;
> 
> However, if it would use
> 
>     unsigned int rw = info->var.xres - (vc->vc_cols*cw);
>     unsigned int bh = info->var.yres - (vc->vc_rows*ch);
> 
> it would work with higher differences, too. And it would be a bit faster
> (multiply and subtract vs. modulo).
> 

Yes, I believe so.  This way, it will make rounding off of values more
clear cut and still produce an acceptable display (albeit with possibly
wider margins).

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Indeed, accel_clear_margins() calculates the margins as
> 
>     unsigned int cw = vc->vc_font.width;
>     unsigned int ch = vc->vc_font.height;
>     unsigned int rw = info->var.xres % cw;
>     unsigned int bh = info->var.yres % ch;
> 
> However, if it would use
> 
>     unsigned int rw = info->var.xres - (vc->vc_cols*cw);
>     unsigned int bh = info->var.yres - (vc->vc_rows*ch);
> 
> it would work with higher differences, too. And it would be a bit faster
> (multiply and subtract vs. modulo).

Applied.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 23:25, Antonino Daplas wrote:

> > > 
> > > 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.  
> 

I apologize for my stupidity, fbdev does not know the font dimensions. 
I guess, we'll just need to really bring back fbset resizing.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > 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.  
> > 
> 
> I apologize for my stupidity, fbdev does not know the font dimensions. 
> I guess, we'll just need to really bring back fbset resizing.

I disagree that fbset is the solution to all things. The problem is 
fbcon_resize is severally broken. The reality is that there are fixed mode 
resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
shoudl do is set the console mode fit slightly smaller than that the 
actually resolution. The reason being is partially drawn fonts at the 
bottom of the screen would look bad. So clearing the margins also has to 
be fixed. This way we clean up the screen for situtations where the 
console screen size doesn't quite fit the resolution. This is what shoudl 
be done. 



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
> I disagree that fbset is the solution to all things. The problem is 
> fbcon_resize is severally broken. The reality is that there are fixed mode 
> resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
> shoudl do is set the console mode fit slightly smaller than that the 
> actually resolution. The reason being is partially drawn fonts at the 
> bottom of the screen would look bad. So clearing the margins also has to 
> be fixed. This way we clean up the screen for situtations where the 
> console screen size doesn't quite fit the resolution. This is what shoudl 
> be done. 

Excuse me that I dare to comment on this as a total fbdev-rookie:

Please think about usability, too. Forcing people to fiddle with rows 
and cols, requiring knowledge about font sizes and stuff is at least 
inappropriate. Folks are used to think in resolutions, that's what they 
understand, and that's what is most obvious. I can't imagine anyone 
caring about the amount of rows or columns on a text screen.

BTW: What happens currently if I instruct console to replace the current 
font with a bigger one (if that's possible at run-time at all) ?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Excuse me that I dare to comment on this as a total fbdev-rookie:

No problem. Its rare I take things personally. So I don't mind people 
critizing my work. You have to have a thick skin for this line of work.
 
> Please think about usability, too. Forcing people to fiddle with rows 
> and cols, requiring knowledge about font sizes and stuff is at least 
> inappropriate. Folks are used to think in resolutions, that's what they 
> understand, and that's what is most obvious. I can't imagine anyone 
> caring about the amount of rows or columns on a text screen.

Actually it is normal. Changing a console via stty has been around 
forever. When you ask what size is your VGA console you say 80x25. Now why 
is that. The main thing is people think of it as a text mode and second
you really can't change it or boot to to many different size resolutions.
Does this mean VGA console should be limited? NO!!! I plan to make vgacon 
some day changable in window size. So the final answer is:

Portablity. 

You could use stty or some other program using the tty layer to change the 
resolution on any type of hardware running any type of console driver. The 
next best thing is some day we can get ride of con_switch in the upper 
console layers. We can just use set_font and vc_resize on VT switching 
since that is all you are doing on vc_switching. 

P.S
   If you look at struct winsize you have a ws_xpixel and a ws_ypixel 
field. The question is now do we place the exact size of the screen in 
pixels or vc->font.width[height]*width[height]. So it is stty program 
that is limiting and not the tty layer. In theory you could write fbset to 
use the proper tty ioctl to do this.
 
> BTW: What happens currently if I instruct console to replace the current 
> font with a bigger one (if that's possible at run-time at all) ?

It should work.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
> Actually it is normal. Changing a console via stty has been around 
> forever. When you ask what size is your VGA console you say 80x25. Now why 
> is that. The main thing is people think of it as a text mode and second
> you really can't change it or boot to to many different size resolutions.
> Does this mean VGA console should be limited? NO!!! I plan to make vgacon 
> some day changable in window size. So the final answer is:
> 
> Portablity. 
> 
> You could use stty or some other program using the tty layer to change the 
> resolution on any type of hardware running any type of console driver. The 
> next best thing is some day we can get ride of con_switch in the upper 
> console layers. We can just use set_font and vc_resize on VT switching 
> since that is all you are doing on vc_switching. 

OK, if this is your final word on this, I - as the maintainer of a 
driver which due to LCD and TV handling only supports a (huge) number of 
built-in modes - am forced to do the following:

If I receive a request for a mode that isn't supported, I go with the 
next larger one that is supported. Even if that leads to differences 
from requested 813x601 to displayed 1024x768.

Hope you and your console code can deal with that then :)

>>BTW: What happens currently if I instruct console to replace the current 
>>font with a bigger one (if that's possible at run-time at all) ?
> 
> 
> It should work.

... and lead to a mode switch? Funny: If I switch from a 8x16 font to a 
bigger one, because I forgot my glasses, the mode is switched to a 
higher one, because the number of cols and rows hasn't changed, leaving 
me with a nearly identical charcter size?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 06:21, Thomas Winischhofer wrote:
> James Simmons wrote:
> > I disagree that fbset is the solution to all things. The problem is 
> > fbcon_resize is severally broken. The reality is that there are fixed mode 
> > resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
> > shoudl do is set the console mode fit slightly smaller than that the 
> > actually resolution. The reason being is partially drawn fonts at the 
> > bottom of the screen would look bad. So clearing the margins also has to 
> > be fixed. This way we clean up the screen for situtations where the 
> > console screen size doesn't quite fit the resolution. This is what shoudl 
> > be done. 
> 
> Excuse me that I dare to comment on this as a total fbdev-rookie:
> 
> Please think about usability, too. Forcing people to fiddle with rows 
> and cols, requiring knowledge about font sizes and stuff is at least 
> inappropriate. Folks are used to think in resolutions, that's what they 
> understand, and that's what is most obvious. I can't imagine anyone 
> caring about the amount of rows or columns on a text screen.
> 

If you are working in a console, then you indeed need to work on rows
and columns.

> BTW: What happens currently if I instruct console to replace the current 
> font with a bigger one (if that's possible at run-time at all) ?

It will work, as the rows and columns are recalculated.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 03:43, James Simmons wrote:
> 
> > > 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.  
> > > 
> > 
> > I apologize for my stupidity, fbdev does not know the font dimensions. 
> > I guess, we'll just need to really bring back fbset resizing.
> 
> I disagree that fbset is the solution to all things. The problem is 
> fbcon_resize is severally broken. The reality is that there are fixed mode 

fbcon_resize() is not that broken, it's only trying to do what it's
supposed to do.  It is indeed limited because it is trying to outguess
the low-level drivers on the best resolution for a window size.

However, the brokenness is really on the driver side.  They are unable
to change the video mode unless they are supplied with the correct
timing parameters where in fact they actually have the best knowledge on
how to calculate them.  

So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
we let the drivers calculate it for themselves?  I go for the latter, as
fbcon really should not have any business with hardware.

> resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
> shoudl do is set the console mode fit slightly smaller than that the 
> actually resolution. The reason being is partially drawn fonts at the 

Yes, Geert's accel_clear_margin fix should help that.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> fbcon_resize() is not that broken, it's only trying to do what it's
> supposed to do.  It is indeed limited because it is trying to outguess
> the low-level drivers on the best resolution for a window size.
> 
> However, the brokenness is really on the driver side.  They are unable
> to change the video mode unless they are supplied with the correct
> timing parameters where in fact they actually have the best knowledge on
> how to calculate them.  

Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
requires at least x and y dimension AND A CLOCK (or a vertical refresh 
rate, which I would prefer).

The driver is supposed to handle the "var"s it's fed. If that var is 
like the ones that result from the current fbcon_resize, namely with a 
new x and y res, but no valid clock, how on earth should the driver do 
this then? It receives a var which looks correct, and in fact, *could* 
be correct sometimes:

Suppose we have another application, say DirectFB, feeding the low level 
drivers with complete and correct "var"s.

In both cases we have valid x any y resultions, and a non-zero clock field.

Should we then let the driver read the x and y resolution and forget 
about the rest of that var? I hardly think that's what the public var is 
for. It could be reduced to a struct { USHORT xres, USHORT yres } then.

> So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> we let the drivers calculate it for themselves?  I go for the latter, as
> fbcon really should not have any business with hardware.

What about the following solution: What if fbcon_resize sets the clock 
in the var to 0? We could use this to force low level drivers to decide 
on the clock for themselves. Otherwise, ie if the clock field is 
non-zero, they are supposed to take it as the desired clock.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Thu, 6 Mar 2003, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> > fbcon_resize() is not that broken, it's only trying to do what it's
> > supposed to do.  It is indeed limited because it is trying to outguess
> > the low-level drivers on the best resolution for a window size.
> > 
> > However, the brokenness is really on the driver side.  They are unable
> > to change the video mode unless they are supplied with the correct
> > timing parameters where in fact they actually have the best knowledge on
> > how to calculate them.  
> 
> Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
> requires at least x and y dimension AND A CLOCK (or a vertical refresh 
> rate, which I would prefer).
> 
> The driver is supposed to handle the "var"s it's fed. If that var is 
> like the ones that result from the current fbcon_resize, namely with a 
> new x and y res, but no valid clock, how on earth should the driver do 
> this then? It receives a var which looks correct, and in fact, *could* 
> be correct sometimes:
> 
> Suppose we have another application, say DirectFB, feeding the low level 
> drivers with complete and correct "var"s.
> 
> In both cases we have valid x any y resultions, and a non-zero clock field.
> 
> Should we then let the driver read the x and y resolution and forget 
> about the rest of that var? I hardly think that's what the public var is 
> for. It could be reduced to a struct { USHORT xres, USHORT yres } then.
> 
> > So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> > we let the drivers calculate it for themselves?  I go for the latter, as
> > fbcon really should not have any business with hardware.
> 
> What about the following solution: What if fbcon_resize sets the clock 
> in the var to 0? We could use this to force low level drivers to decide 
> on the clock for themselves. Otherwise, ie if the clock field is 
> non-zero, they are supposed to take it as the desired clock.

What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
current resolution?

If you use stty to change the number of cols/rows, or change the font, or use
fbset, your text console may end up being smaller or larger than the real
screen size, in which case margins are cleared, or columns/lines are lost.
(Optionally, we can center the text console if it's smaller than the real
 screen size.)

IMHO this is the most orthogonal approach. Fbcon takes care of the text
console, fbdev takes care of the graphics hardware and the video mode. Both
parts do (try to) not influence each other.

Optionally, fbset can call stty to change the number of cols/rows, if the user
wants that.

What do you think?

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 17:12, Geert Uytterhoeven wrote:
> 
> What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
> current resolution?
> 
> If you use stty to change the number of cols/rows, or change the font, or use
> fbset, your text console may end up being smaller or larger than the real
> screen size, in which case margins are cleared, or columns/lines are lost.
> (Optionally, we can center the text console if it's smaller than the real
>  screen size.)
> 

Which is basically what stty does for the standard console (except that
lines are not lost, but wrapped, and margins are not cleared).

So, we need to reimplement the clipping code.

> IMHO this is the most orthogonal approach. Fbcon takes care of the text
> console, fbdev takes care of the graphics hardware and the video mode. Both
> parts do (try to) not influence each other.
> 
> Optionally, fbset can call stty to change the number of cols/rows, if the user
> wants that.
> 

Or even a simple script that basically does "fbset 1024x768-60 && stty
cols 128 rows 48". Of course, adding this to fbset itself will make it
transparent to the user.

Sounds very logical to me :-)

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On 6 Mar 2003, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 17:12, Geert Uytterhoeven wrote:
> > What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
> > current resolution?
> > 
> > If you use stty to change the number of cols/rows, or change the font, or use
> > fbset, your text console may end up being smaller or larger than the real
> > screen size, in which case margins are cleared, or columns/lines are lost.
> > (Optionally, we can center the text console if it's smaller than the real
> >  screen size.)
> > 
> 
> Which is basically what stty does for the standard console (except that
> lines are not lost, but wrapped, and margins are not cleared).
> 
> So, we need to reimplement the clipping code.

In fbcon, I hope?

> > IMHO this is the most orthogonal approach. Fbcon takes care of the text
> > console, fbdev takes care of the graphics hardware and the video mode. Both
> > parts do (try to) not influence each other.
> > 
> > Optionally, fbset can call stty to change the number of cols/rows, if the user
> > wants that.
> 
> Or even a simple script that basically does "fbset 1024x768-60 && stty
> cols 128 rows 48". Of course, adding this to fbset itself will make it
> transparent to the user.
> 
> Sounds very logical to me :-)

Yep ;-)

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 18:14, Geert Uytterhoeven wrote:
> On 6 Mar 2003, Antonino Daplas wrote:
> > On Thu, 2003-03-06 at 17:12, Geert Uytterhoeven wrote:
> > > What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
> > > current resolution?
> > > 
> > > If you use stty to change the number of cols/rows, or change the font, or use
> > > fbset, your text console may end up being smaller or larger than the real
> > > screen size, in which case margins are cleared, or columns/lines are lost.
> > > (Optionally, we can center the text console if it's smaller than the real
> > >  screen size.)
> > > 
> > 
> > Which is basically what stty does for the standard console (except that
> > lines are not lost, but wrapped, and margins are not cleared).
> > 
> > So, we need to reimplement the clipping code.
> 
> In fbcon, I hope?
> 

Yes, it's easier to do this in fbcon.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 16:49, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> > fbcon_resize() is not that broken, it's only trying to do what it's
> > supposed to do.  It is indeed limited because it is trying to outguess
> > the low-level drivers on the best resolution for a window size.
> > 
> > However, the brokenness is really on the driver side.  They are unable
> > to change the video mode unless they are supplied with the correct
> > timing parameters where in fact they actually have the best knowledge on
> > how to calculate them.  
> 
> Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
> requires at least x and y dimension AND A CLOCK (or a vertical refresh 
> rate, which I would prefer).

The VESA GTF can calculate timings using only xres, yres and any of the
three...

1. desired pixelclock
2. desired refresh
3. desired hsync

... all of which can be chosen by the driver, or extracted from the monitor
(ie. DDC or uploaded by the user).

For non-GTF compatible monitors, you can choose any of the standard timings
table. 

> 
> The driver is supposed to handle the "var"s it's fed. If that var is 
> like the ones that result from the current fbcon_resize, namely with a 
> new x and y res, but no valid clock, how on earth should the driver do 
> this then? It receives a var which looks correct, and in fact, *could* 
> be correct sometimes:
> 

Mode checking is not simply looking at xres and yres, but also looking
at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
then compared to the monitor/graphics card's capability.  If any of the
values fall outside the limits then the mode is not valid.  Otherwise,
the new mode should still produce a usable display, perhaps not the one
the user wants (ie refresh rate is lower).  By this time though, the
user can freely use fbset to fine tune all the timings.

For fixed-frequency monitors or analog TV (where timings are critical),
you can use very strict operating limits (like vsync_min = 60 and
vsync_max = 60).  With strict limits, it's unlikely that the new timings
will be valid, so the driver will always be forced to calculate a new
mode.

> Suppose we have another application, say DirectFB, feeding the low level 
> drivers with complete and correct "var"s.
> 
> In both cases we have valid x any y resultions, and a non-zero clock field.
> 
> Should we then let the driver read the x and y resolution and forget 
> about the rest of that var? I hardly think that's what the public var is 
> for. It could be reduced to a struct { USHORT xres, USHORT yres } then.
> 
> > So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> > we let the drivers calculate it for themselves?  I go for the latter, as
> > fbcon really should not have any business with hardware.
> 
> What about the following solution: What if fbcon_resize sets the clock 
> in the var to 0? We could use this to force low level drivers to decide 
> on the clock for themselves. Otherwise, ie if the clock field is 
> non-zero, they are supposed to take it as the desired clock.
> 

Yes, that's another solution.  Just invalidate the timings and force the
driver to compute a modeline each time.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> On Thu, 2003-03-06 at 16:49, Thomas Winischhofer wrote:
>>>However, the brokenness is really on the driver side.  They are unable
>>>to change the video mode unless they are supplied with the correct
>>>timing parameters where in fact they actually have the best knowledge on
>>>how to calculate them.  
>>
>>Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
>>requires at least x and y dimension AND A CLOCK (or a vertical refresh 
>>rate, which I would prefer).
> 
> The VESA GTF can calculate timings using only xres, yres and any of the
> three...
> 
> 1. desired pixelclock
> 2. desired refresh
> 3. desired hsync
> 
> ... all of which can be chosen by the driver, or extracted from the monitor
> (ie. DDC or uploaded by the user).

See? Need a clock! My word! :)

> Mode checking is not simply looking at xres and yres, but also looking
> at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
> then compared to the monitor/graphics card's capability.  If any of the
> values fall outside the limits then the mode is not valid.  Otherwise,
> the new mode should still produce a usable display, perhaps not the one
> the user wants (ie refresh rate is lower).  By this time though, the
> user can freely use fbset to fine tune all the timings.

Perhaps I have not made myself clear:

I start with a default 800x600-60. Pixelclock in var is now X.

fbcon_resize adapts the xres and yres, leaving the pixelclock alone.

The driver sees upon the check_var call: xres, yres and X - the old 
pixelclock (which is non-zero).

That pixelclock *COULD* be valid, but it COULD also be invalid! There is 
no way of distinguishing!

>>What about the following solution: What if fbcon_resize sets the clock 
>>in the var to 0? We could use this to force low level drivers to decide 
>>on the clock for themselves. Otherwise, ie if the clock field is 
>>non-zero, they are supposed to take it as the desired clock.
> 
> Yes, that's another solution.  Just invalidate the timings and force the
> driver to compute a modeline each time.

I think Geert came up with a better solution in the meantime.

But a general rule should be anyway: Whenever passing a var to the 
driver which only changed in a few fields and through this invalidated 
the timing settings, the caller should set everthing else to ZERO, in 
other words: invalidate it in a recognizable way. That's IMHO the only 
way the driver can distinguish between intended and unintended settings.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 17:43, Thomas Winischhofer wrote:
> > Mode checking is not simply looking at xres and yres, but also looking
> > at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
> > then compared to the monitor/graphics card's capability.  If any of the
> > values fall outside the limits then the mode is not valid.  Otherwise,
> > the new mode should still produce a usable display, perhaps not the one
> > the user wants (ie refresh rate is lower).  By this time though, the
> > user can freely use fbset to fine tune all the timings.
> 
> Perhaps I have not made myself clear:
> 
> I start with a default 800x600-60. Pixelclock in var is now X.
> 
> fbcon_resize adapts the xres and yres, leaving the pixelclock alone.
> 
> The driver sees upon the check_var call: xres, yres and X - the old 
> pixelclock (which is non-zero).
> 
> That pixelclock *COULD* be valid, but it COULD also be invalid! There is 
> no way of distinguishing!
> 

Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
calculate hsync and vsync.  Compare this with your monitor's limit -- if
any fall outside, the entire mode, pixelclock and all is not valid.

(see fb_get_mode() and fb_validate_mode() in fbmon.c)

And if you use very narrow vsync and hsync ranges, then the "stale"
pixelclock will always most certainly be invalid.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Sven Luther]

On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> calculate hsync and vsync.  Compare this with your monitor's limit -- if
> any fall outside, the entire mode, pixelclock and all is not valid.
> 
> (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> 
> And if you use very narrow vsync and hsync ranges, then the "stale"
> pixelclock will always most certainly be invalid.

BTW, do we have an easy way of knowing if it is an LCD or analog monitor
which is attached to the card (or even a TV) ? I think the radeonfb
knows how to do this, not sure though.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 18:31, Sven Luther wrote:
> On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> > Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> > calculate hsync and vsync.  Compare this with your monitor's limit -- if
> > any fall outside, the entire mode, pixelclock and all is not valid.
> > 
> > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > 
> > And if you use very narrow vsync and hsync ranges, then the "stale"
> > pixelclock will always most certainly be invalid.
> 
> BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> which is attached to the card (or even a TV) ? I think the radeonfb
> knows how to do this, not sure though.
> 

There's an EDID parser in fbmon.c.  I think it will work only for the
PPC. This is currently used by rivafb and radeonfb. For the rest, either
we implement DDC or just have something similar to XF86Config's
HorizSync and VertRefresh.  We can load this either as a kernel/module
option or passed via ioctl/sysfs.  

I'm already doing this with the i810fb (as boot/module option), which
greatly simplified mode switching.

Tony





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 18:48, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 18:31, Sven Luther wrote:
> > On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> > > Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> > > calculate hsync and vsync.  Compare this with your monitor's limit -- if
> > > any fall outside, the entire mode, pixelclock and all is not valid.
> > > 
> > > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > > 
> > > And if you use very narrow vsync and hsync ranges, then the "stale"
> > > pixelclock will always most certainly be invalid.
> > 
> > BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> > which is attached to the card (or even a TV) ? I think the radeonfb
> > knows how to do this, not sure though.
> > 
> 
> There's an EDID parser in fbmon.c.  I think it will work only for the
> PPC. This is currently used by rivafb and radeonfb. For the rest, either
> we implement DDC or just have something similar to XF86Config's
> HorizSync and VertRefresh.  We can load this either as a kernel/module
> option or passed via ioctl/sysfs.  
> 
> I'm already doing this with the i810fb (as boot/module option), which
> greatly simplified mode switching.
> 

Oops, totally missed your question :-)  But yes, I think the EDID block
contains information about the monitor type, not sure thogh.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Sven Luther]

On Thu, Mar 06, 2003 at 06:51:58PM +0800, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 18:48, Antonino Daplas wrote:
> > On Thu, 2003-03-06 at 18:31, Sven Luther wrote:
> > > On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> > > > Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> > > > calculate hsync and vsync.  Compare this with your monitor's limit -- if
> > > > any fall outside, the entire mode, pixelclock and all is not valid.
> > > > 
> > > > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > > > 
> > > > And if you use very narrow vsync and hsync ranges, then the "stale"
> > > > pixelclock will always most certainly be invalid.
> > > 
> > > BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> > > which is attached to the card (or even a TV) ? I think the radeonfb
> > > knows how to do this, not sure though.
> > > 
> > 
> > There's an EDID parser in fbmon.c.  I think it will work only for the
> > PPC. This is currently used by rivafb and radeonfb. For the rest, either

Mmm, is it because the EDID parser uses the EDID information pased by
the OF ?

> > we implement DDC or just have something similar to XF86Config's
> > HorizSync and VertRefresh.  We can load this either as a kernel/module
> > option or passed via ioctl/sysfs.  

Most monitors today have DDC support, so i guess best would be to use
it, and fall back to a command line option if DDC is not supported.

> > I'm already doing this with the i810fb (as boot/module option), which
> > greatly simplified mode switching.
> 
> Oops, totally missed your question :-)  But yes, I think the EDID block
> contains information about the monitor type, not sure thogh.

X finds :

Digital Display Input

So, i guess this is it.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 19:40, Sven Luther wrote:
> > > 
> > > There's an EDID parser in fbmon.c.  I think it will work only for the
> > > PPC. This is currently used by rivafb and radeonfb. For the rest, either
> 
> Mmm, is it because the EDID parser uses the EDID information pased by
> the OF ?
> 

Yes.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > Oops, totally missed your question :-)  But yes, I think the EDID block
> > contains information about the monitor type, not sure thogh.
> 
> X finds :
> 
> Digital Display Input
> 
> So, i guess this is it.

Yes the EDID block does have info on the monitor type. It even has the 
vendor name. I wonder if it can detect when you unplug a monitor and plug 
in a new one?



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > 
> > And if you use very narrow vsync and hsync ranges, then the "stale"
> > pixelclock will always most certainly be invalid.
> 
> BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> which is attached to the card (or even a TV) ? I think the radeonfb
> knows how to do this, not sure though.

Not that I know of.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Alright: I tested the newest fbdev patch.

1) Boot logo support: Does not compile, misses a script "p??tologo" or 
anything like that.

2) Changed sisfb to accept practically any mode, but it now adapts to 
the next larger supported mode if no exact mode based on rows and cols 
is found. Previously, this adaption was limited to 16 pixels.

stty does not work at all now, because fbcon's fbcon_resize() checks the 
returned var from fb_set_var if the mode is off more than one character 
in height and width - and returns EINVAL in this case.

Since stty calles the console code twice if rows and cols are provided, 
this fails miserably, because the first attempt (which for example 
requests 800x768 if switching from 1024x768 to 800x600) fails.

So I changed fbcon from

	if(err || width != var.xres/fw || height != var.yres/fh)

to

	if(err)

and now it works.

However, there is still (at least) one problem within the console layer.

With my patch, I can now have a console of for instance 128x20 
characters, on a 1024x768 screen. Scrolling mostly works, but sometimes 
console seems to forget to pan. I can't reproduce this on purpose, but 
printing eg. a directory with ls works in 90% of the cases (=scrolls 
correctly), but prints text beyond the current amount of rows in the 
remaining 10% of the cases. If I press enter until the last line of the 
console is on the very bottom of the 1024x768 screen, then it remembers 
its amount of rows and pans correctly.

For estethical reasons, I would also recommend changing the order or 
panning and character drawing. Now, the characters seem to be drawn 
first, and panning is done later. That causes some flickering sometimes, 
and with a console smaller than the screen resolution (eg. screen is 
1024x768, console uses only 20 rows), text is shown below the 20th row 
for a fraction of a second before the panning is done.

I will send the current sisfb code to James later today. (It also fixes
some non-fbdev-related mode switching problems on some Asus laptops)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Fri, 7 Mar 2003, Thomas Winischhofer wrote:
> Alright: I tested the newest fbdev patch.
> 
> 1) Boot logo support: Does not compile, misses a script "p??tologo" or 
> anything like that.

--- linux-2.5.64/scripts/Makefile	Wed Mar  5 10:07:45 2003
+++ linux-logo-2.5.64/scripts/Makefile	Wed Mar  5 13:19:54 2003
@@ -9,7 +9,7 @@
 # conmakehash:	 Create arrays for initializing the kernel console tables
 
 host-progs    := fixdep split-include conmakehash docproc kallsyms modpost \
-		 mk_elfconfig
+		 mk_elfconfig pnmtologo
 build-targets := $(host-progs) empty.o
 
 modpost-objs  := modpost.o file2alias.o
--- linux-2.5.64/scripts/pnmtologo.c	Thu Jan  1 01:00:00 1970
+++ linux-logo-2.5.64/scripts/pnmtologo.c	Fri Jan 24 17:19:33 2003
@@ -0,0 +1,507 @@
+
+/*
+ *  Convert a logo in ASCII PNM format to C source suitable for inclusion in
+ *  the Linux kernel
+ *
+ *  (C) Copyright 2001-2003 by Geert Uytterhoeven <geert@linux-m68k.org>
+ *
+ *  --------------------------------------------------------------------------
+ *
+ *  This file is subject to the terms and conditions of the GNU General Public
+ *  License. See the file COPYING in the main directory of the Linux
+ *  distribution for more details.
+ */
+
+#include <ctype.h>
+#include <errno.h>
+#include <stdarg.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+
+static const char *programname;
+static const char *filename;
+static const char *logoname = "linux_logo";
+static const char *outputname;
+static FILE *out;
+
+
+#define LINUX_LOGO_MONO		1	/* monochrome black/white */
+#define LINUX_LOGO_VGA16	2	/* 16 colors VGA text palette */
+#define LINUX_LOGO_CLUT224	3	/* 224 colors */
+#define LINUX_LOGO_GRAY256	4	/* 256 levels grayscale */
+
+static const char *logo_types[LINUX_LOGO_GRAY256+1] = {
+    [LINUX_LOGO_MONO] = "LINUX_LOGO_MONO",
+    [LINUX_LOGO_VGA16] = "LINUX_LOGO_VGA16",
+    [LINUX_LOGO_CLUT224] = "LINUX_LOGO_CLUT224",
+    [LINUX_LOGO_GRAY256] = "LINUX_LOGO_GRAY256"
+};
+
+#define MAX_LINUX_LOGO_COLORS	224
+
+struct color {
+    unsigned char red;
+    unsigned char green;
+    unsigned char blue;
+};
+
+static const struct color clut_vga16[16] = {
+    { 0x00, 0x00, 0x00 },
+    { 0x00, 0x00, 0xaa },
+    { 0x00, 0xaa, 0x00 },
+    { 0x00, 0xaa, 0xaa },
+    { 0xaa, 0x00, 0x00 },
+    { 0xaa, 0x00, 0xaa },
+    { 0xaa, 0x55, 0x00 },
+    { 0xaa, 0xaa, 0xaa },
+    { 0x55, 0x55, 0x55 },
+    { 0x55, 0x55, 0xff },
+    { 0x55, 0xff, 0x55 },
+    { 0x55, 0xff, 0xff },
+    { 0xff, 0x55, 0x55 },
+    { 0xff, 0x55, 0xff },
+    { 0xff, 0xff, 0x55 },
+    { 0xff, 0xff, 0xff },
+};
+
+
+static int logo_type = LINUX_LOGO_CLUT224;
+static unsigned int logo_width;
+static unsigned int logo_height;
+static struct color **logo_data;
+static struct color logo_clut[MAX_LINUX_LOGO_COLORS];
+static unsigned int logo_clutsize = 0;
+
+static void die(const char *fmt, ...)
+    __attribute__ ((noreturn)) __attribute ((format (printf, 1, 2)));
+static void usage(void) __attribute ((noreturn));
+
+
+static unsigned int get_number(FILE *fp)
+{
+    int c, val;
+
+    /* Skip leading whitespace */
+    do {
+	c = fgetc(fp);
+	if (c == EOF)
+	    die("%s: end of file\n", filename);
+	if (c == '#') {
+	    /* Ignore comments 'till end of line */
+	    do {
+		c = fgetc(fp);
+		if (c == EOF)
+		    die("%s: end of file\n", filename);
+	    } while (c != '\n');
+	}
+    } while (isspace(c));
+
+    /* Parse decimal number */
+    val = 0;
+    while (isdigit(c)) {
+	val = 10*val+c-'0';
+	c = fgetc(fp);
+	if (c == EOF)
+	    die("%s: end of file\n", filename);
+    }
+    return val;
+}
+
+static unsigned int get_number255(FILE *fp, unsigned int maxval)
+{
+    unsigned int val = get_number(fp);
+    return (255*val+maxval/2)/maxval;
+}
+
+static void read_image(void)
+{
+    FILE *fp;
+    int i, j, magic;
+    unsigned int maxval;
+
+    /* open image file */
+    fp = fopen(filename, "r");
+    if (!fp)
+	die("Cannot open file %s: %s\n", filename, strerror(errno));
+
+    /* check file type and read file header */
+    magic = fgetc(fp);
+    if (magic != 'P')
+	die("%s is not a PNM file\n", filename);
+    magic = fgetc(fp);
+    switch (magic) {
+	case '1':
+	case '2':
+	case '3':
+	    /* Plain PBM/PGM/PPM */
+	    break;
+
+	case '4':
+	case '5':
+	case '6':
+	    /* Binary PBM/PGM/PPM */
+	    die("%s: Binary PNM is not supported\n"
+		"Use pnmnoraw(1) to convert it to ASCII PNM\n", filename);
+
+	default:
+	    die("%s is not a PNM file\n", filename);
+    }
+    logo_width = get_number(fp);
+    logo_height = get_number(fp);
+
+    /* allocate image data */
+    logo_data = (struct color **)malloc(logo_height*sizeof(struct color *));
+    if (!logo_data)
+	die("%s\n", strerror(errno));
+    for (i = 0; i < logo_height; i++) {
+	logo_data[i] = malloc(logo_width*sizeof(struct color));
+	if (!logo_data[i])
+	    die("%s\n", strerror(errno));
+    }
+
+    /* read image data */
+    switch (magic) {
+	case '1':
+	    /* Plain PBM */
+	    for (i = 0; i < logo_height; i++)
+		for (j = 0; j < logo_width; j++)
+		    logo_data[i][j].red = logo_data[i][j].green =
+			logo_data[i][j].blue = 255*(1-get_number(fp));
+	    break;
+
+	case '2':
+	    /* Plain PGM */
+	    maxval = get_number(fp);
+	    for (i = 0; i < logo_height; i++)
+		for (j = 0; j < logo_width; j++)
+		    logo_data[i][j].red = logo_data[i][j].green =
+			logo_data[i][j].blue = get_number255(fp, maxval);
+	    break;
+
+	case '3':
+	    /* Plain PPM */
+	    maxval = get_number(fp);
+	    for (i = 0; i < logo_height; i++)
+		for (j = 0; j < logo_width; j++) {
+		    logo_data[i][j].red = get_number255(fp, maxval);
+		    logo_data[i][j].green = get_number255(fp, maxval);
+		    logo_data[i][j].blue = get_number255(fp, maxval);
+		}
+	    break;
+    }
+
+    /* close file */
+    fclose(fp);
+}
+
+static inline int is_black(struct color c)
+{
+    return c.red == 0 && c.green == 0 && c.blue == 0;
+}
+
+static inline int is_white(struct color c)
+{
+    return c.red == 255 && c.green == 255 && c.blue == 255;
+}
+
+static inline int is_gray(struct color c)
+{
+    return c.red == c.green && c.red == c.blue;
+}
+
+static inline int is_equal(struct color c1, struct color c2)
+{
+    return c1.red == c2.red && c1.green == c2.green && c1.blue == c2.blue;
+}
+
+static void write_header(void)
+{
+    /* open logo file */
+    if (outputname) {
+	out = fopen(outputname, "w");
+	if (!out)
+	    die("Cannot create file %s: %s\n", outputname, strerror(errno));
+    } else {
+	out = stdout;
+    }
+
+    fputs("/*\n", out);
+    fputs(" *  DO NOT EDIT THIS FILE!\n", out);
+    fputs(" *\n", out);
+    fprintf(out, " *  It was automatically generated from %s\n", filename);
+    fputs(" *\n", out);
+    fprintf(out, " *  Linux logo %s\n", logoname);
+    fputs(" */\n\n", out);
+    fputs("#include <linux/linux_logo.h>\n\n", out);
+    fprintf(out, "static const unsigned char %s_data[] __initdata = {\n",
+	    logoname);
+}
+
+static void write_footer(void)
+{
+    fputs("\n};\n\n", out);
+    fprintf(out, "const struct linux_logo %s __initdata = {\n", logoname);
+    fprintf(out, "    .type\t= %s,\n", logo_types[logo_type]);
+    fprintf(out, "    .width\t= %d,\n", logo_width);
+    fprintf(out, "    .height\t= %d,\n", logo_height);
+    if (logo_type == LINUX_LOGO_CLUT224) {
+	fprintf(out, "    .clutsize\t= %d,\n", logo_clutsize);
+	fprintf(out, "    .clut\t= %s_clut,\n", logoname);
+    }
+    fprintf(out, "    .data\t= %s_data\n", logoname);
+    fputs("};\n\n", out);
+
+    /* close logo file */
+    if (outputname)
+	fclose(out);
+}
+
+static int write_hex_cnt = 0;
+
+static void write_hex(unsigned char byte)
+{
+    if (write_hex_cnt % 12)
+	fprintf(out, ", 0x%02x", byte);
+    else if (write_hex_cnt)
+	fprintf(out, ",\n\t0x%02x", byte);
+    else
+	fprintf(out, "\t0x%02x", byte);
+    write_hex_cnt++;
+}
+
+static void write_logo_mono(void)
+{
+    int i, j;
+    unsigned char val, bit;
+
+    /* validate image */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++)
+	    if (!is_black(logo_data[i][j]) && !is_white(logo_data[i][j]))
+		die("Image must be monochrome\n");
+
+    /* write file header */
+    write_header();
+
+    /* write logo data */
+    for (i = 0; i < logo_height; i++) {
+	for (j = 0; j < logo_width;) {
+	    for (val = 0, bit = 0x80; bit && j < logo_width; j++, bit >>= 1)
+		if (logo_data[i][j].red)
+		    val |= bit;
+	    write_hex(val);
+	}
+    }
+
+    /* write logo structure and file footer */
+    write_footer();
+}
+
+static void write_logo_vga16(void)
+{
+    int i, j, k;
+    unsigned char val;
+
+    /* validate image */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++) {
+	    for (k = 0; k < 16; k++)
+		if (is_equal(logo_data[i][j], clut_vga16[k]))
+		    break;
+	    if (k == 16)
+		die("Image must use the 16 console colors only\n"
+		    "Use ppmquant(1) -map clut_vga16.ppm to reduce the number "
+		    "of colors\n");
+	}
+
+    /* write file header */
+    write_header();
+
+    /* write logo data */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++) {
+	    for (k = 0; k < 16; k++)
+		if (is_equal(logo_data[i][j], clut_vga16[k]))
+		    break;
+	    val = k<<4;
+	    if (++j < logo_width) {
+		for (k = 0; k < 16; k++)
+		    if (is_equal(logo_data[i][j], clut_vga16[k]))
+			break;
+		val |= k;
+	    }
+	    write_hex(val);
+	}
+
+    /* write logo structure and file footer */
+    write_footer();
+}
+
+static void write_logo_clut224(void)
+{
+    int i, j, k;
+
+    /* validate image */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++) {
+	    for (k = 0; k < logo_clutsize; k++)
+		if (is_equal(logo_data[i][j], logo_clut[k]))
+		    break;
+	    if (k == logo_clutsize) {
+		if (logo_clutsize == MAX_LINUX_LOGO_COLORS)
+		    die("Image has more than %d colors\n"
+			"Use ppmquant(1) to reduce the number of colors\n",
+			MAX_LINUX_LOGO_COLORS);
+		logo_clut[logo_clutsize++] = logo_data[i][j];
+	    }
+	}
+
+    /* write file header */
+    write_header();
+
+    /* write logo data */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++) {
+	    for (k = 0; k < logo_clutsize; k++)
+		if (is_equal(logo_data[i][j], logo_clut[k]))
+		    break;
+	    write_hex(k+32);
+	}
+    fputs("\n};\n\n", out);
+
+    /* write logo clut */
+    fprintf(out, "static const unsigned char %s_clut[] __initdata = {\n",
+	    logoname);
+    write_hex_cnt = 0;
+    for (i = 0; i < logo_clutsize; i++) {
+	write_hex(logo_clut[i].red);
+	write_hex(logo_clut[i].green);
+	write_hex(logo_clut[i].blue);
+    }
+
+    /* write logo structure and file footer */
+    write_footer();
+}
+
+static void write_logo_gray256(void)
+{
+    int i, j;
+
+    /* validate image */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++)
+	    if (!is_gray(logo_data[i][j]))
+		die("Image must be grayscale\n");
+
+    /* write file header */
+    write_header();
+
+    /* write logo data */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++)
+	    write_hex(logo_data[i][j].red);
+
+    /* write logo structure and file footer */
+    write_footer();
+}
+
+static void die(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+
+    exit(1);
+}
+
+static void usage(void)
+{
+    die("\n"
+	"Usage: %s [options] <filename>\n"
+	"\n"
+	"Valid options:\n"
+	"    -h          : display this usage information\n"
+	"    -n <name>   : specify logo name (default: linux_logo)\n"
+	"    -o <output> : output to file <output> instead of stdout\n"
+	"    -t <type>   : specify logo type, one of\n"
+	"                      mono    : monochrome black/white\n"
+	"                      vga16   : 16 colors VGA text palette\n"
+	"                      clut224 : 224 colors (default)\n"
+	"                      gray256 : 256 levels grayscale\n"
+	"\n", programname);
+}
+
+int main(int argc, char *argv[])
+{
+    int opt;
+
+    programname = argv[0];
+
+    opterr = 0;
+    while (1) {
+	opt = getopt(argc, argv, "hn:o:t:");
+	if (opt == -1)
+	    break;
+
+	switch (opt) {
+	    case 'h':
+		usage();
+		break;
+
+	    case 'n':
+		logoname = optarg;
+		break;
+
+	    case 'o':
+		outputname = optarg;
+		break;
+
+	    case 't':
+		if (!strcmp(optarg, "mono"))
+		    logo_type = LINUX_LOGO_MONO;
+		else if (!strcmp(optarg, "vga16"))
+		    logo_type = LINUX_LOGO_VGA16;
+		else if (!strcmp(optarg, "clut224"))
+		    logo_type = LINUX_LOGO_CLUT224;
+		else if (!strcmp(optarg, "gray256"))
+		    logo_type = LINUX_LOGO_GRAY256;
+		else
+		    usage();
+		break;
+
+	    default:
+		usage();
+		break;
+	}
+    }
+    if (optind != argc-1)
+	usage();
+
+    filename = argv[optind];
+
+    read_image();
+    switch (logo_type) {
+	case LINUX_LOGO_MONO:
+	    write_logo_mono();
+	    break;
+
+	case LINUX_LOGO_VGA16:
+	    write_logo_vga16();
+	    break;
+
+	case LINUX_LOGO_CLUT224:
+	    write_logo_clut224();
+	    break;
+
+	case LINUX_LOGO_GRAY256:
+	    write_logo_gray256();
+	    break;
+    }
+    exit(0);
+}
+

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> On Fri, 7 Mar 2003, Thomas Winischhofer wrote:
> > Alright: I tested the newest fbdev patch.
> >
> > 1) Boot logo support: Does not compile, misses a script "p??tologo" or
> > anything like that.

??? That is getting annoying. Another patch is coming very soon.

P.S

   Almost done with porting matroxfb. Still some more to go tho.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Fri, 2003-03-07 at 20:08, Thomas Winischhofer wrote:
> 
> 
> However, there is still (at least) one problem within the console layer.
> 
> With my patch, I can now have a console of for instance 128x20 
> characters, on a 1024x768 screen. Scrolling mostly works, but sometimes 
> console seems to forget to pan. I can't reproduce this on purpose, but 
> printing eg. a directory with ls works in 90% of the cases (=scrolls 
> correctly), but prints text beyond the current amount of rows in the 
> remaining 10% of the cases. If I press enter until the last line of the 
> console is on the very bottom of the 1024x768 screen, then it remembers 
> its amount of rows and pans correctly.
>

Try this patch.  The fbcon_resize test is more liberal and it now correctly
updates p->vrows and scroll_phys_max (for panning glitches).

Tony


diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-06 01:29:29.000000000 +0000
+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-07 13:54:04.000000000 +0000
@@ -580,8 +580,8 @@
 	struct fb_info *info = p->fb_info;
 	unsigned int cw = vc->vc_font.width;
 	unsigned int ch = vc->vc_font.height;
-	unsigned int rw = info->var.xres % cw;
-	unsigned int bh = info->var.yres % ch;
+	unsigned int rw = info->var.xres - (cw * vc->vc_cols);
+	unsigned int bh = info->var.yres - (ch * vc->vc_rows);
 	unsigned int rs = info->var.xres - rw;
 	unsigned int bs = info->var.yres - bh;
 	struct fb_fillrect region;
@@ -1815,14 +1815,14 @@
 	   (y_diff < 0 || y_diff > fh)) {
 		var.activate = FB_ACTIVATE_TEST;
 		err = fb_set_var(&var, info);
-		if (err || width != var.xres/fw ||
-		    height != var.yres/fh)
+		if (err || width > var.xres/fw ||
+		    height > var.yres/fh)
 			return -EINVAL;
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
 		var.activate = FB_ACTIVATE_NOW;
 		fb_set_var(&var, info);
-		p->vrows = info->var.yres_virtual/fh;
 	}
+	p->vrows = info->var.yres_virtual/fh;
 	return 0;
 }
 
@@ -1857,6 +1857,7 @@
 	}
 	if (info)
 		info->var.yoffset = p->yscroll = 0;
+        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
 	switch (p->scrollmode & __SCROLL_YMASK) {
 	case __SCROLL_YWRAP:
 		scrollback_phys_max = p->vrows - vc->vc_rows;
@@ -1875,7 +1876,6 @@
 
 	info->currcon = unit;
 	
-        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
 	update_var(unit, info);
 	fbcon_set_palette(vc, color_table); 	
 




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

[-- Attachment #1: Type: text/plain, Size: 3889 bytes --]


This works - perfectly, I must say.

However, the scrolling problem is still here, but I think I know the 
reason for this:

Imagine a console of 120x40 (using the std 8x16 font), on a screen of 
1024x768, using ypanning.

This uses only 40*16=640 pixels vertically instead of the 768 available.

The problem is the y panning, and is kind of both console's as well as 
the driver's fault:

When the y panning area reaches its end, it's supposed to copy the 
screen to the beginning of this area and pan to position 0.

However, fbcon calculates p->vrows by info->var.yres_virtual / fontheight.

This disregards the fact that the visible screen area is actually larger 
than the area console is supposed to use.

Therefore, the calculation of vrows has to take the difference between 
these two into account.

The attached patch fixes this for me but I have no idea if I cought all 
possible itches. It will no apply cleanly, because I had made changes to 
fbcon.c before making a backup copy - but it sure illustrates the problem.

Why you used info->var.yres_virtual (and not the adapted 
var.yres_virtual) in fbcon_resize() is beyond me, BTW.

Thomas

Antonino Daplas wrote:
> On Fri, 2003-03-07 at 20:08, Thomas Winischhofer wrote:
> 
>>
>>However, there is still (at least) one problem within the console layer.
>>
>>With my patch, I can now have a console of for instance 128x20 
>>characters, on a 1024x768 screen. Scrolling mostly works, but sometimes 
>>console seems to forget to pan. I can't reproduce this on purpose, but 
>>printing eg. a directory with ls works in 90% of the cases (=scrolls 
>>correctly), but prints text beyond the current amount of rows in the 
>>remaining 10% of the cases. If I press enter until the last line of the 
>>console is on the very bottom of the 1024x768 screen, then it remembers 
>>its amount of rows and pans correctly.
>>
> 
> 
> Try this patch.  The fbcon_resize test is more liberal and it now correctly
> updates p->vrows and scroll_phys_max (for panning glitches).
> 
> Tony
> 
> 
> diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
> --- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-06 01:29:29.000000000 +0000
> +++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-07 13:54:04.000000000 +0000
> @@ -580,8 +580,8 @@
>  	struct fb_info *info = p->fb_info;
>  	unsigned int cw = vc->vc_font.width;
>  	unsigned int ch = vc->vc_font.height;
> -	unsigned int rw = info->var.xres % cw;
> -	unsigned int bh = info->var.yres % ch;
> +	unsigned int rw = info->var.xres - (cw * vc->vc_cols);
> +	unsigned int bh = info->var.yres - (ch * vc->vc_rows);
>  	unsigned int rs = info->var.xres - rw;
>  	unsigned int bs = info->var.yres - bh;
>  	struct fb_fillrect region;
> @@ -1815,14 +1815,14 @@
>  	   (y_diff < 0 || y_diff > fh)) {
>  		var.activate = FB_ACTIVATE_TEST;
>  		err = fb_set_var(&var, info);
> -		if (err || width != var.xres/fw ||
> -		    height != var.yres/fh)
> +		if (err || width > var.xres/fw ||
> +		    height > var.yres/fh)
>  			return -EINVAL;
>  		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
>  		var.activate = FB_ACTIVATE_NOW;
>  		fb_set_var(&var, info);
> -		p->vrows = info->var.yres_virtual/fh;
>  	}
> +	p->vrows = info->var.yres_virtual/fh;
>  	return 0;
>  }
>  
> @@ -1857,6 +1857,7 @@
>  	}
>  	if (info)
>  		info->var.yoffset = p->yscroll = 0;
> +        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
>  	switch (p->scrollmode & __SCROLL_YMASK) {
>  	case __SCROLL_YWRAP:
>  		scrollback_phys_max = p->vrows - vc->vc_rows;
> @@ -1875,7 +1876,6 @@
>  
>  	info->currcon = unit;
>  	
> -        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
>  	update_var(unit, info);
>  	fbcon_set_palette(vc, color_table); 	
>  
> 
> 


-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/



[-- Attachment #2: fbcon_patch --]
[-- Type: application/x-java-applet, Size: 1373 bytes --]

Re: Some questions

[Antonino Daplas]

On Fri, 2003-03-07 at 23:19, Thomas Winischhofer wrote:
> 
> This works - perfectly, I must say.
> 
> However, the scrolling problem is still here, but I think I know the 
> reason for this:
> 
> Imagine a console of 120x40 (using the std 8x16 font), on a screen of 
> 1024x768, using ypanning.
> 
> This uses only 40*16=640 pixels vertically instead of the 768 available.
> 
> The problem is the y panning, and is kind of both console's as well as 
> the driver's fault:
> 
> When the y panning area reaches its end, it's supposed to copy the 
> screen to the beginning of this area and pan to position 0.
> 
> However, fbcon calculates p->vrows by info->var.yres_virtual / fontheight.
> 
> This disregards the fact that the visible screen area is actually larger 
> than the area console is supposed to use.
> 
> Therefore, the calculation of vrows has to take the difference between 
> these two into account.
> 
> The attached patch fixes this for me but I have no idea if I cought all 
> possible itches. It will no apply cleanly, because I had made changes to 
> fbcon.c before making a backup copy - but it sure illustrates the problem.
> 

Right, fbcon never dealt with margins greater than a character
width/height before :-). I think your patch will do the Right Thing.

As for the one you commented out as INCOMPLETE, my guess is it won't
matter since that particular section of code is called only during
initialization.  An fbcon_switch() will be called later on, I think.

> Why you used info->var.yres_virtual (and not the adapted 
> var.yres_virtual) in fbcon_resize() is beyond me, BTW.
> 

Because info->var will _always_ contain the correct var, so we trust
that above all.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> Right, fbcon never dealt with margins greater than a character
> width/height before :-). I think your patch will do the Right Thing.

I hope so :) But please think it through, I have no idea about the 
possible impacts of this.

> As for the one you commented out as INCOMPLETE, my guess is it won't
> matter since that particular section of code is called only during
> initialization.  An fbcon_switch() will be called later on, I think.

No idea, but ... you're the expert!

>>Why you used info->var.yres_virtual (and not the adapted 
>>var.yres_virtual) in fbcon_resize() is beyond me, BTW.
> 
> Because info->var will _always_ contain the correct var, so we trust
> that above all.

Then I must have misunderstood the code. You submit var (and not 
info->var) to fb_set_var, so it is that var that will be treated by 
check_var and used for set_par. Since check_var() may (and does) change 
the yres_virtual according to the desired resolution/depth and so on, I 
thought it might be more correct to use it instead of info->var...

I have in the meantime submitted a new sisfb patch to James; it depends, 
however, on the changes to fbcon we are discussing now (especially the 
fbcon_resize thing which is too intolerant in James' current code base). 
Otherwise, mode switches using stty won't work.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Sat, 2003-03-08 at 01:00, Thomas Winischhofer wrote:
> >>Why you used info->var.yres_virtual (and not the adapted 
> >>var.yres_virtual) in fbcon_resize() is beyond me, BTW.
> > 
> > Because info->var will _always_ contain the correct var, so we trust
> > that above all.
> 
> Then I must have misunderstood the code. You submit var (and not 
> info->var) to fb_set_var, so it is that var that will be treated by 
> check_var and used for set_par. Since check_var() may (and does) change 
> the yres_virtual according to the desired resolution/depth and so on, I 
> thought it might be more correct to use it instead of info->var...
> 

Note that fbcon_resize made a copy of info->var, then modified it
according to the requested width and height.  Then it goes through a
test if it needs an fb_set_var or not.  So info->var and the modified
var can be different if fb_set_var() wasn't called at all.  If it indeed
went through fb_set_var(), the var returned from check_var() will be
placed automatically to info->var before calling set_par().  So, yes, in
this case, info->var and the adjusted var will be the same.

Of course, in this particular code it is not important whichever var is
used because we're only interested in yres_virtual.  But using info->var
instead of the adjusted var is safer because it is guaranteed to be
always correct.

BTW: I'll check the patch against vesafb and let you know.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Therefore, the calculation of vrows has to take the difference between
> these two into account.
>
> The attached patch fixes this for me but I have no idea if I cought all
> possible itches. It will no apply cleanly, because I had made changes to
> fbcon.c before making a backup copy - but it sure illustrates the problem.
>
> Why you used info->var.yres_virtual (and not the adapted
> var.yres_virtual) in fbcon_resize() is beyond me, BTW.

My mistake. I applied your patch.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
>>Therefore, the calculation of vrows has to take the difference between
>>these two into account.
>>
>>The attached patch fixes this for me but I have no idea if I cought all
>>possible itches. It will no apply cleanly, because I had made changes to
>>fbcon.c before making a backup copy - but it sure illustrates the problem.
>>
>>Why you used info->var.yres_virtual (and not the adapted
>>var.yres_virtual) in fbcon_resize() is beyond me, BTW.
> 
> 
> My mistake. I applied your patch.

Reading first Toni's post (because it came one minute earlier) and now 
yours, what's true resp. correct now?

Thomas

PS: James, are you "entitled" to add maintainers to the MAINTAINERS 
file? I have actually been the maintainer of sisfb since a year back, so 
I think this should perhaps be mentioned..?

SIS FRAMEBUFFER DRIVER
P:	Thomas Winischhofer
M:	thomas@winischhofer.net
W:	http://www.winischhofer.net/linuxsisvga.shtml
S:	Maintained



-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> PS: James, are you "entitled" to add maintainers to the MAINTAINERS 
> file? I have actually been the maintainer of sisfb since a year back, so 
> I think this should perhaps be mentioned..?
> 
> SIS FRAMEBUFFER DRIVER
> P:	Thomas Winischhofer
> M:	thomas@winischhofer.net
> W:	http://www.winischhofer.net/linuxsisvga.shtml
> S:	Maintained

Added.




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Fri, 2003-03-07 at 23:19, Thomas Winischhofer wrote:
> 
> This works - perfectly, I must say.
> 
> However, the scrolling problem is still here, but I think I know the 
> reason for this:
> 
> Imagine a console of 120x40 (using the std 8x16 font), on a screen of 
> 1024x768, using ypanning.
> 
> This uses only 40*16=640 pixels vertically instead of the 768 available.
> 
> The problem is the y panning, and is kind of both console's as well as 
> the driver's fault:
> 
> When the y panning area reaches its end, it's supposed to copy the 
> screen to the beginning of this area and pan to position 0.
> 
> However, fbcon calculates p->vrows by info->var.yres_virtual / fontheight.
> 
> This disregards the fact that the visible screen area is actually larger 
> than the area console is supposed to use.

I've tested where the virtual window size is much smaller than the
physical dimensions, and I do see the glitch you mentioned.  But it's
mainly due to clear_margins().  clear_margins always erases a constant
amount (physical_height - actual height).  So if you happen to pan just
enough that there's not enough screen estate left, it will attempt to
clear past yres_virtual.  Bad for drivers that do not implement
clipping. Perhaps, block moves are involved here also, I'm not sure. 

So your patch has the correct idea, but here's a simpler one. It just
reserves enough screen estate equal to difference of physical height and
virtual height. I've tested this even using stty cols 2, and it works
okay.

NOTE:  Since we need var->yres, this time, we need to refer to info->var
instead of the adjusted var.

BTW:  I've tested moving clear_margins before panning, it still doesn't
remove the onrushing text past the virtual window height.  This would
seem to need clipping to remove that eyesore.  

If the patch doesn't apply cleanly, it should be easy enough to do so
manually.

Tony

diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-07 15:03:06.000000000 +0000
+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-07 20:06:39.000000000 +0000
@@ -1044,6 +1044,7 @@
 		vc->vc_rows = nr_rows;
 	}
 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
+	p->vrows -= info->var.yres - vc->vc_rows;
 	if ((info->var.yres % vc->vc_font.height) &&
 	    (info->var.yres_virtual % vc->vc_font.height <
 	     info->var.yres % vc->vc_font.height))
@@ -1821,8 +1822,9 @@
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
 		var.activate = FB_ACTIVATE_NOW;
 		fb_set_var(&var, info);
-		p->vrows = info->var.yres_virtual/fh;
 	}
+	p->vrows = info->var.yres_virtual/fh;
+	p->vrows -= (info->var.yres + (fh - 1))/fh - vc->vc_rows;
 	return 0;
 }
 
@@ -2094,6 +2096,7 @@
 		/* reset wrap/pan */
 		info->var.xoffset = info->var.yoffset = p->yscroll = 0;
 		p->vrows = info->var.yres_virtual / h;
+		p->vrows -= info->var.yres/h - vc->vc_rows;
 		if ((info->var.yres % h)
 		    && (info->var.yres_virtual % h < info->var.yres % h))
 			p->vrows--;





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> On Fri, 2003-03-07 at 23:19, Thomas Winischhofer wrote:
> 
>>This works - perfectly, I must say.
>>
>>However, the scrolling problem is still here, but I think I know the 
>>reason for this:
>>
>>Imagine a console of 120x40 (using the std 8x16 font), on a screen of 
>>1024x768, using ypanning.
>>
>>This uses only 40*16=640 pixels vertically instead of the 768 available.
>>
>>The problem is the y panning, and is kind of both console's as well as 
>>the driver's fault:
>>
>>When the y panning area reaches its end, it's supposed to copy the 
>>screen to the beginning of this area and pan to position 0.
>>
>>However, fbcon calculates p->vrows by info->var.yres_virtual / fontheight.
>>
>>This disregards the fact that the visible screen area is actually larger 
>>than the area console is supposed to use.
> 
> 
> I've tested where the virtual window size is much smaller than the
> physical dimensions, and I do see the glitch you mentioned.  But it's
> mainly due to clear_margins().  clear_margins always erases a constant
> amount (physical_height - actual height).  So if you happen to pan just
> enough that there's not enough screen estate left, it will attempt to
> clear past yres_virtual.  Bad for drivers that do not implement
> clipping. Perhaps, block moves are involved here also, I'm not sure. 

1) Sisfb does no clipping, but there is plenty of video RAM past the 
virtual area.

2) I don't think we are talking about the same thing. Clear_margins() 
(which I haven't looked at, I confess) assumingly ... erm.. clears the 
margins. But why is it involved in scrolling any panning?

> So your patch has the correct idea, but here's a simpler one. It just
> reserves enough screen estate equal to difference of physical height and
> virtual height. I've tested this even using stty cols 2, and it works
> okay.

I don't see why this is simpler, but I do see it wastes a lot of screen 
space :)

BTW:

  	p->vrows = info->var.yres_virtual / vc->vc_font.height;
+	p->vrows -= info->var.yres - vc->vc_rows;

Look:

rows =          40
yres =         768
yres_v =      2048
font height =   16

vrows = 2048 / 16 = 128  (character unit)

128 - (768 - 40)

is negative...

Personally, I'd go with my first patch from earlier today. I tested this 
intensively in the meantime, and it Simpy Works(tm).

> NOTE:  Since we need var->yres, this time, we need to refer to info->var
> instead of the adjusted var.
> 
> BTW:  I've tested moving clear_margins before panning, it still doesn't
> remove the onrushing text past the virtual window height.  This would
> seem to need clipping to remove that eyesore.  

Honestly, I don't consider this important... But I thought you'd simply 
exchange the order of calling pan_var and drawing the characters... 
(which IMHO would be the correct order, logically speaking)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Sat, 2003-03-08 at 04:51, Thomas Winischhofer wrote:
> I don't see why this is simpler, but I do see it wastes a lot of screen 
> space :)
> 

yep, it'a a typo.

Tony

diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-07 15:03:06.000000000 +0000
+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-08 00:49:09.000000000 +0000
@@ -1044,6 +1044,7 @@
 		vc->vc_rows = nr_rows;
 	}
 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
+	p->vrows -= info->var.yres/h - vc->vc_rows;
 	if ((info->var.yres % vc->vc_font.height) &&
 	    (info->var.yres_virtual % vc->vc_font.height <
 	     info->var.yres % vc->vc_font.height))
@@ -1821,8 +1822,9 @@
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
 		var.activate = FB_ACTIVATE_NOW;
 		fb_set_var(&var, info);
-		p->vrows = info->var.yres_virtual/fh;
 	}
+	p->vrows = info->var.yres_virtual/fh;
+	p->vrows -= (info->var.yres + (fh - 1))/fh - vc->vc_rows;
 	return 0;
 }
 
@@ -2094,6 +2096,7 @@
 		/* reset wrap/pan */
 		info->var.xoffset = info->var.yoffset = p->yscroll = 0;
 		p->vrows = info->var.yres_virtual / h;
+		p->vrows -= info->var.yres/h - vc->vc_rows;
 		if ((info->var.yres % h)
 		    && (info->var.yres_virtual % h < info->var.yres % h))
 			p->vrows--;



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Sat, 2003-03-08 at 08:58, Antonino Daplas wrote:
> On Sat, 2003-03-08 at 04:51, Thomas Winischhofer wrote:
> > I don't see why this is simpler, but I do see it wastes a lot of screen 
> > space :)
> > 
> 
> yep, it'a a typo.
> 
> Tony
> 
> diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
> --- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-07 15:03:06.000000000 +0000
> +++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-08 00:49:09.000000000 +0000
> @@ -1044,6 +1044,7 @@
>  		vc->vc_rows = nr_rows;
>  	}
>  	p->vrows = info->var.yres_virtual / vc->vc_font.height;
> +	p->vrows -= info->var.yres/h - vc->vc_rows;
                    ^^^^^^^^^^^^^^^^

I also meant info->var.yres/vc->vc_font.height :-)

Tony





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>> 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
>>+	p->vrows -= info->var.yres/h - vc->vc_rows;
> 
>                     ^^^^^^^^^^^^^^^^
> 
> I also meant info->var.yres/vc->vc_font.height :-)

Tony,

Both ways it works, granted. But I still don't see the advantage of your 
solution over mine. Your's wastes an area of the size of a whole screen.

Certainly no offence, but can you explain why you think this is better?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Continued:  What happens with your solution of the virtual area is only 
1.5 times the size of the visible area? Did your check this?

 >> 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
 >>+	p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;

yres = 768
yres_virtual = 1152
fontheight= 16
rows = 48

vrows = 1152 / 16 = 72
72 - (768 / 16) - 48 = -24

:) Any question?

Thomas


Antonino Daplas wrote:
> On Sat, 2003-03-08 at 08:58, Antonino Daplas wrote:
> 
>>On Sat, 2003-03-08 at 04:51, Thomas Winischhofer wrote:
>>
>>>I don't see why this is simpler, but I do see it wastes a lot of screen 
>>>space :)
>>>
>>
>>yep, it'a a typo.
>>
>>Tony
>>
>>diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
>>--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-07 15:03:06.000000000 +0000
>>+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-08 00:49:09.000000000 +0000
>>@@ -1044,6 +1044,7 @@
>> 		vc->vc_rows = nr_rows;
>> 	}
>> 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
>>+	p->vrows -= info->var.yres/h - vc->vc_rows;
> 
>                     ^^^^^^^^^^^^^^^^
> 
> I also meant info->var.yres/vc->vc_font.height :-)
> 
> Tony
> 
> 
> 


-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Sat, 2003-03-08 at 22:20, Thomas Winischhofer wrote:
> 
> 
> Continued:  What happens with your solution of the virtual area is only 
> 1.5 times the size of the visible area? Did your check this?
> 
>  >> 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
>  >>+	p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;
> 
> yres = 768
> yres_virtual = 1152
> fontheight= 16
> rows = 48
> 
> vrows = 1152 / 16 = 72
> 72 - (768 / 16) - 48 = -24
> 
> :) Any question?
> 
Why?

Your example - 1024x768, yres_virtual = 1152, font = 8x16

2 cases:  

1. full screeen console
vc->vc_rows = 48

p->vrows = 72 - (768/16 - 48)
p->vrows = 72 - 0
p->vrows = 72

2. half-height console:
vc->vc_rows = 24

p->vrows = 1152 - (768/16 - 24)
p->vrows = 72 - 24
p->vrows = 48

Second case, 24 rows are wasted, why? See accel_clear_margins:

ch = vc->vc_font_height
bh =  yres - (vc->vc_rows * ch)
bh = 768 - (24 * 16)
bh = 768 - 384
bh = 384

This means that a rectangle of height 384 scanlines (_always_) at the
bottom of the display will be cleared .  If you pan to the end of
graphics memory, attempting to clear from yres_virtual + 384 will cause
the chipset to crash.  But it won't because we reserved 24 rows (384
pixels) to accomodate this.

For the clincher, this is your code:

if(info->var.yres > (vc->vc_font.height * (vc->vc_rows + 1))) {
	p->vrows -= (info->var.yres - (vc->vc_font.height * 		    
vc->vc_rows)) / vc->vc_font.height;
}

Simplifying the second line....

p->vrows -= (info->var.yres/vc->vc_font.height) - (vc->vc_font.height *
vc->vc_rows)/vc->vc_font.height;
p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;

Do you recognize the last line?  Yep, it's mine. It's also simpler (1
division and 1 subtraction vs 1 division, 1 multiplication and 1
subtraction). 

Code correctness was never the issue.  The only thing I'm questioning is
using info->var.yres instead of var.yres, and I have explained this
enough times already. 

Granted, the patch I submitted was a quickwrite, never meant to be
applied but serves only to illustrate.  This is a more proper patch,
applied against James latest fbdev.diff.  It simplifies the equation,
remove the unnecessary 'if' conditional.  Apply it, don't apply it, I
don't care.

Tony

diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-08 21:33:25.000000000 +0000
+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-08 21:47:26.000000000 +0000
@@ -1044,9 +1044,7 @@
 		vc->vc_rows = nr_rows;
 	}
 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
-	if(info->var.yres > (vc->vc_font.height * (vc->vc_rows + 1))) {
-		p->vrows -= (info->var.yres - (vc->vc_font.height * vc->vc_rows)) / vc->vc_font.height;
-	}
+	p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;
 	if ((info->var.yres % vc->vc_font.height) &&
 	    (info->var.yres_virtual % vc->vc_font.height <
 	     info->var.yres % vc->vc_font.height))
@@ -1825,9 +1823,8 @@
 		var.activate = FB_ACTIVATE_NOW;
 		fb_set_var(&var, info);
 	}
-	p->vrows = var.yres_virtual/fh;
-	if(var.yres > (fh * (height + 1)))
-		p->vrows -= (var.yres - (fh * height)) / fh;
+	p->vrows = info->var.yres_virtual/fh;
+	p->vrows -= (info->var.yres + (fh - 1))/fh - height;
 	return 0;
 }
 
@@ -2099,11 +2096,7 @@
 		/* reset wrap/pan */
 		info->var.xoffset = info->var.yoffset = p->yscroll = 0;
 		p->vrows = info->var.yres_virtual / h;
-
-#if 0          /* INCOMPLETE - let the console gurus handle this */
-		if(info->var.yres > (h * (vc->vc_rows + 1))
-			p->vrows -= (info->var.yres - (h * vc->vc_rows)) / h;
-#endif
+		p->vrows -= info->var.yres/h  - vc->vc_rows;
 		if ((info->var.yres % h)
 		    && (info->var.yres_virtual % h < info->var.yres % h))
 			p->vrows--;



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino,
> Your example - 1024x768, yres_virtual = 1152, font = 8x16
> 
> 2 cases:  
> 
> 1. full screeen console
> vc->vc_rows = 48
> 
> p->vrows = 72 - (768/16 - 48)
> p->vrows = 72 - 0
> p->vrows = 72

You're right. I made a mistake in my calculation.

> Granted, the patch I submitted was a quickwrite, never meant to be
> applied but serves only to illustrate.  This is a more proper patch,
> applied against James latest fbdev.diff.  It simplifies the equation,
> remove the unnecessary 'if' conditional.  Apply it, don't apply it, I
> don't care.

That's not up to me to decide. For me, the only thing that counts is 
that the console can deal with text areas that are smaller than the 
screen resolution. Besides, your last sentence was certainly not 
neccessary. You among friends here.

Thomas


-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Sun, 2003-03-09 at 11:47, Thomas Winischhofer wrote:
> 
> > Granted, the patch I submitted was a quickwrite, never meant to be
> > applied but serves only to illustrate.  This is a more proper patch,
> > applied against James latest fbdev.diff.  It simplifies the equation,
> > remove the unnecessary 'if' conditional.  Apply it, don't apply it, I
> > don't care.
> 
> That's not up to me to decide. For me, the only thing that counts is 
> that the console can deal with text areas that are smaller than the 
> screen resolution. Besides, your last sentence was certainly not 
> neccessary. You among friends here.
> 

My apologies if I sounded too harsh, no offense was intended.  I just
meant that your code and mine achieves the same and (hopefully) correct
results  And because the code is in a non-performance critical section,
I don't care whichever is used (except for the var->yres and
info->var.yres issue).  

If the code affects a critical section (blitting, character painting,
etc), of course, that's another story.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Try this patch.  The fbcon_resize test is more liberal and it now correctly
> updates p->vrows and scroll_phys_max (for panning glitches).

Applied.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> However, the brokenness is really on the driver side.  They are unable
> to change the video mode unless they are supplied with the correct
> timing parameters where in fact they actually have the best knowledge on
> how to calculate them.  
> 
> So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> we let the drivers calculate it for themselves?  I go for the latter, as
> fbcon really should not have any business with hardware.

I agree. 



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
>>However, the brokenness is really on the driver side.  They are unable
>>to change the video mode unless they are supplied with the correct
>>timing parameters where in fact they actually have the best knowledge on
>>how to calculate them.  
>>
>>So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
>>we let the drivers calculate it for themselves?  I go for the latter, as
>>fbcon really should not have any business with hardware.
> 
> 
> I agree. 

Me Too(tm). SiSfb (sorry for mentioning this one over and over, but 
that's the only one I am working on) does that now, according to the 
following assumptions:

If old_x == new_x && old_y == new_y && old_clock == new_clock

	-> assume a change in depth, hence recalculate the clock
	based on the htotal and vtotal values (which are calculated
	using var's horizontal and vertical timing.

else if (old_x != new_x || old_y != new_y) && old_clock == new_clock

	-> assume a mode change originating from fbcon_resize (where
	only xres and yres are changed, everything else left unchanged; 	 
hence, use the default clock (user selectable) because clock is
	invalid.

else if(timings are valid)

	-> use these timings, they originate from an application
	using the framebuffer device properly (directFB, for instance)

else -> use default clock

Works perfectly. Tested all possible applications (mplayer, sdl stuff, 
etc), no problems.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[James Simmons]

> > 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.

Things like pixclock rates can be changes by fbset and fbcon still 
sees these changes. stty is for the basic changes and fbset for advance 
changes. 

On a personal note. Many fbdev drivers in 2.4.X where also broken in that 
only the boot mode worked. This is where the fbset mode database in 
userland hack came in (/etc/fb.modes). This is horriable. Even with that 
userland database I often couldn't change video modes after booting. 

We should split the monitor programing stuff out from stuff like bpp etc.
Now if you think about it we can do things like change the bpp without 
having to redo the monitor programming. This is the flaw with the old and 
even the new api. 
 



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, James Simmons wrote:
> On a personal note. Many fbdev drivers in 2.4.X where also broken in that 
> only the boot mode worked. This is where the fbset mode database in 
> userland hack came in (/etc/fb.modes). This is horriable. Even with that 

Do you remember how modes were set before the existence of fbset? I guess not
:-)

A driver could support up to 31 modes (cfr. the old minors). You changed mode
by touch'ing the /dev/fb0my_favorite_mode special device that corresponded to
the mode you wanted.

> userland database I often couldn't change video modes after booting. 

Ugh, those are serious driver bugs....

> We should split the monitor programing stuff out from stuff like bpp etc.
> Now if you think about it we can do things like change the bpp without 
> having to redo the monitor programming. This is the flaw with the old and 
> even the new api. 

You could have done that from the beginning. Just look at which fields have
changed and which haven't.

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Do you remember how modes were set before the existence of fbset? I guess not
> :-)

before my time.

> A driver could support up to 31 modes (cfr. the old minors). You changed mode
> by touch'ing the /dev/fb0my_favorite_mode special device that corresponded to
> the mode you wanted.

Yuck!!!!
 
> > userland database I often couldn't change video modes after booting. 
> 
> Ugh, those are serious driver bugs....

So the arrgument that fbset is the solution to all problems is bogus IMO.

> > We should split the monitor programing stuff out from stuff like bpp etc.
> > Now if you think about it we can do things like change the bpp without 
> > having to redo the monitor programming. This is the flaw with the old and 
> > even the new api. 
> 
> You could have done that from the beginning. Just look at which fields have
> changed and which haven't.

I should of but didn't because I knew driver would take teh path of lest 
resistance to port there drivers. TO much change would have made the 
current situtation much much worst. 



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
>>>We should split the monitor programing stuff out from stuff like bpp etc.
>>>Now if you think about it we can do things like change the bpp without 
>>>having to redo the monitor programming. This is the flaw with the old and 
>>>even the new api. 
>>
>>You could have done that from the beginning. Just look at which fields have
>>changed and which haven't.
> 
> 
> I should of but didn't because I knew driver would take teh path of lest 
> resistance to port there drivers. TO much change would have made the 
> current situtation much much worst. 

One could argue that changing stuff more or less constantly does not 
make it any easier to keep up with a working driver.... :)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > I should of but didn't because I knew driver would take teh path of lest 
> > resistance to port there drivers. TO much change would have made the 
> > current situtation much much worst. 
> 
> One could argue that changing stuff more or less constantly does not 
> make it any easier to keep up with a working driver.... :)

Well that was a policy change later on. At first the approach was small 
changes at a time. I was even converting each driver by myself. This upset 
some people. It was discussed the best solution would be to dump all the 
changes at one time and then let the driver maintainers deal with it. 
That is why the shift in what was going on.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, James Simmons wrote:
> > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > Now if you think about it we can do things like change the bpp without 
> > > having to redo the monitor programming. This is the flaw with the old and 
> > > even the new api. 
> > 
> > You could have done that from the beginning. Just look at which fields have
> > changed and which haven't.
> 
> I should of but didn't because I knew driver would take teh path of lest 
> resistance to port there drivers. TO much change would have made the 
> current situtation much much worst. 

One other reason why this isn't done is because X may interfere with it. If we
don't do a full register update, but change the parts that need a change only,
we will see less flickering (no PLL reprogramming), but we will suffer if X
doesn't restore the registers to the exact same values they were before.

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Sven Luther]

On Thu, Mar 06, 2003 at 09:33:34AM +0100, Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, James Simmons wrote:
> > > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > > Now if you think about it we can do things like change the bpp without 
> > > > having to redo the monitor programming. This is the flaw with the old and 
> > > > even the new api. 
> > > 
> > > You could have done that from the beginning. Just look at which fields have
> > > changed and which haven't.
> > 
> > I should of but didn't because I knew driver would take teh path of lest 
> > resistance to port there drivers. TO much change would have made the 
> > current situtation much much worst. 
> 
> One other reason why this isn't done is because X may interfere with it. If we
> don't do a full register update, but change the parts that need a change only,
> we will see less flickering (no PLL reprogramming), but we will suffer if X
> doesn't restore the registers to the exact same values they were before.

X is supposed to do that, even if it doesn't know anything about fbdevs,
maybe especially if it doesn't know anything about fbdevs. If it knows
about fbdev and uses it, X should not be touching the modes anyway,
right ?

So, we are saving/restoring things twice, one time in X, the other in
the fbdev.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 16:33, Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, James Simmons wrote:
> > > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > > Now if you think about it we can do things like change the bpp without 
> > > > having to redo the monitor programming. This is the flaw with the old and 
> > > > even the new api. 
> > > 
> > > You could have done that from the beginning. Just look at which fields have
> > > changed and which haven't.
> > 
> > I should of but didn't because I knew driver would take teh path of lest 
> > resistance to port there drivers. TO much change would have made the 
> > current situtation much much worst. 
> 
> One other reason why this isn't done is because X may interfere with it. If we
> don't do a full register update, but change the parts that need a change only,
> we will see less flickering (no PLL reprogramming), but we will suffer if X
> doesn't restore the registers to the exact same values they were before.
> 

Ideally, that is what should happen.  However, fb_set_var does a check
if the passed var is different from the default var.  If it's the same,
fb_set_par is skipped.  Switching back from X, this check will be mostly
false, so fb_set_par will be skipped, and register refreshing would have
failed.

So, I think fbcon should also detect if the previous console is not
fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if
it isn't, force an fb_set_par.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> So, I think fbcon should also detect if the previous console is not
> fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if
> it isn't, force an fb_set_par.

This whole idea of mapping a specific VC to a specific piece of hardware 
is just plain dumb and overly complex. The new console system will 
allocate a set of 16 console to each independent VT.




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 00:29, James Simmons wrote:
> 
> > So, I think fbcon should also detect if the previous console is not
> > fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if
> > it isn't, force an fb_set_par.
> 
> This whole idea of mapping a specific VC to a specific piece of hardware 
> is just plain dumb and overly complex. The new console system will 
> allocate a set of 16 console to each independent VT.
> 

Well, you have info->currcon, fg_console etc...  No mapping is done,
fbcon will just keep track of the tty's it's currently switched to (vt.c
does it, and so does fbcon_switch), and fbcon will just look if the vc
has a valid PID (which means a process installed its own vc) and
therefore not trust it to completely preserve the graphics state.

Note that X does something like this to protect itself.  When switch
from console to X, it refreshes its own registers.

I think you may need some support for this.  Several have already
reported that switching from X to a console results in a corrupted
display which can be cleared by doing an fbset. 

The choices are:

1. refresh the registers at every switch - slowest but guarantees
hardware state is always preserved 
 
2. do not refresh unless var changed - fasted but can result in
corruption/crash if registers were changed behind the back of fbdev

3. selective refresh - do not refresh if switching between "trusted"
consoles, refresh if switching from "untrusted" consoles.

4. Find a method to detect if the registers were changed behind the back
of fbdev.

Tony 



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> Well, you have info->currcon, fg_console etc...  No mapping is done,
> fbcon will just keep track of the tty's it's currently switched to (vt.c
> does it, and so does fbcon_switch), and fbcon will just look if the vc
> has a valid PID (which means a process installed its own vc) and
> therefore not trust it to completely preserve the graphics state.
> 
> Note that X does something like this to protect itself.  When switch
> from console to X, it refreshes its own registers.

Which does not neccessarily mean that the framebuffer driver must do the 
same, resulting in two mode switches. Not really healthy for LCD panels.

The current implementation (as with James' latest patch) does not show 
any problems with this, even when switching back to a console with a 
different resolution than the one X was started under. Then again, maybe 
that's just due to a all too well working sis driver combination :)

> I think you may need some support for this.  Several have already
> reported that switching from X to a console results in a corrupted
> display which can be cleared by doing an fbset. 
> 
> The choices are:
> 
> 1. refresh the registers at every switch - slowest but guarantees
> hardware state is always preserved 

Bad. Takes long time, especially on LCD displays which always need a 
little delay for backlight and sync stability reasons.

> 2. do not refresh unless var changed - fasted but can result in
> corruption/crash if registers were changed behind the back of fbdev

I think one can rely on tidyness of applications changing the registers. 
Like X does.

> 3. selective refresh - do not refresh if switching between "trusted"
> consoles, refresh if switching from "untrusted" consoles.
> 
> 4. Find a method to detect if the registers were changed behind the back
> of fbdev.

Very time taking on some hardware (such as ... erm... SiS) with more 
than 100 registers for graphic mode setup.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 04:56, Thomas Winischhofer wrote:
> > 
> > The choices are:
> > 
> > 1. refresh the registers at every switch - slowest but guarantees
> > hardware state is always preserved 
> 
> Bad. Takes long time, especially on LCD displays which always need a 
> little delay for backlight and sync stability reasons.
> 
> > 2. do not refresh unless var changed - fasted but can result in
> > corruption/crash if registers were changed behind the back of fbdev
> 
> I think one can rely on tidyness of applications changing the registers. 
> Like X does.
 
Unfortunately, this is what we are trying to prevent.  X assumes that
the console is in text mode, so only registers that affect text mode are
restored.  Frequently, cursor registers and bitmaps, as an example, are
not refreshed.  There's probably more, ie accel engine, etc.

Of course, X is not totally to blame, it's doing its best to restore the
console back.  It really depends on the X drivers, how complicated they
are, how comprehensive are their restore routines, etc.  

> > 3. selective refresh - do not refresh if switching between "trusted"
> > consoles, refresh if switching from "untrusted" consoles.

I actually prefer #3, and I already have working code for this.  We can
also make this driver switchable (ie, drivers that are not affected by X
can disable this, and only drivers that are affected such as the riva,
aty, radeon, etc can turn this on).

Tony



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>>>2. do not refresh unless var changed - fasted but can result in
>>>corruption/crash if registers were changed behind the back of fbdev
>>
>>I think one can rely on tidyness of applications changing the registers. 
>>Like X does.
> 
>  
> Unfortunately, this is what we are trying to prevent.  X assumes that
> the console is in text mode, so only registers that affect text mode are
> restored.  Frequently, cursor registers and bitmaps, as an example, are
> not refreshed.  There's probably more, ie accel engine, etc.

That surprises me. The X drivers I looked at (quite a bunch) restore all 
registers (that need to be restored, that is)

>>>3. selective refresh - do not refresh if switching between "trusted"
>>>consoles, refresh if switching from "untrusted" consoles.
>>
> 
> I actually prefer #3, and I already have working code for this.  We can
> also make this driver switchable (ie, drivers that are not affected by X
> can disable this, and only drivers that are affected such as the riva,
> aty, radeon, etc can turn this on).

What exactly is a "trusted" console?

Thomas


-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > 
> > I actually prefer #3, and I already have working code for this.  We can
> > also make this driver switchable (ie, drivers that are not affected by X
> > can disable this, and only drivers that are affected such as the riva,
> > aty, radeon, etc can turn this on).
> 
> What exactly is a "trusted" console?
> 

By default, the pid of each vt is -1.  When X loads, it installs its own
VT (ie vt7), which in that case the pid of that particular vt == X's
pid.  We can check this pid, and if switching from a vt with pid == -1,
we can safely assume that the hardware state is still sane, and if not,
assume the hardware state is undefined.

Tony




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Michel Dänzer]

On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > 
> > > I actually prefer #3, and I already have working code for this.  We can
> > > also make this driver switchable (ie, drivers that are not affected by X
> > > can disable this, and only drivers that are affected such as the riva,
> > > aty, radeon, etc can turn this on).
> > 
> > What exactly is a "trusted" console?
> 
> By default, the pid of each vt is -1.  When X loads, it installs its own
> VT (ie vt7), which in that case the pid of that particular vt == X's
> pid.  We can check this pid, and if switching from a vt with pid == -1,
> we can safely assume that the hardware state is still sane, and if not,
> assume the hardware state is undefined.

Can you also detect when the app has opened the framebuffer device, and
assume it's playing nice when it has? (for Option "UseFBDev")


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > 
> > > > I actually prefer #3, and I already have working code for this.  We can
> > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > can disable this, and only drivers that are affected such as the riva,
> > > > aty, radeon, etc can turn this on).
> > > 
> > > What exactly is a "trusted" console?
> > 
> > By default, the pid of each vt is -1.  When X loads, it installs its own
> > VT (ie vt7), which in that case the pid of that particular vt == X's
> > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > we can safely assume that the hardware state is still sane, and if not,
> > assume the hardware state is undefined.
> 
> Can you also detect when the app has opened the framebuffer device, and
> assume it's playing nice when it has? (for Option "UseFBDev")
> 

X using fbdev will also have the same limitation. I have implemented
something like this before.  For each fb_open, the current->pid can be
saved into a "white list" and removed for each fb_close.  fbcon can then
compare this to the pid of the vt it's switching from.

This is becoming to sound very ugly though.  I guess, the best way is to
really support Option "UseFBDev", or at least have the user decide if
he/she wants to have the hardware refreshed.  

Tony   





-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Michel Dänzer]

On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > 
> > > > > I actually prefer #3, and I already have working code for this.  We can
> > > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > > can disable this, and only drivers that are affected such as the riva,
> > > > > aty, radeon, etc can turn this on).
> > > > 
> > > > What exactly is a "trusted" console?
> > > 
> > > By default, the pid of each vt is -1.  When X loads, it installs its own
> > > VT (ie vt7), which in that case the pid of that particular vt == X's
> > > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > > we can safely assume that the hardware state is still sane, and if not,
> > > assume the hardware state is undefined.
> > 
> > Can you also detect when the app has opened the framebuffer device, and
> > assume it's playing nice when it has? (for Option "UseFBDev")
> > 
> 
> X using fbdev will also have the same limitation. I have implemented
> something like this before.  For each fb_open, the current->pid can be
> saved into a "white list" and removed for each fb_close.  fbcon can then
> compare this to the pid of the vt it's switching from.

I see, makes sense.

> This is becoming to sound very ugly though.  I guess, the best way is to
> really support Option "UseFBDev", or at least have the user decide if
> he/she wants to have the hardware refreshed.  

I'm afraid I don't understand what you're saying here.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Geert Uytterhoeven]

On 12 Mar 2003, Michel [ISO-8859-1] Dänzer wrote:
> On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> > On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> > > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > > 
> > > > > > I actually prefer #3, and I already have working code for this.  We can
> > > > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > > > can disable this, and only drivers that are affected such as the riva,
> > > > > > aty, radeon, etc can turn this on).
> > > > > 
> > > > > What exactly is a "trusted" console?
> > > > 
> > > > By default, the pid of each vt is -1.  When X loads, it installs its own
> > > > VT (ie vt7), which in that case the pid of that particular vt == X's
> > > > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > > > we can safely assume that the hardware state is still sane, and if not,
> > > > assume the hardware state is undefined.
> > > 
> > > Can you also detect when the app has opened the framebuffer device, and
> > > assume it's playing nice when it has? (for Option "UseFBDev")
> > 
> > X using fbdev will also have the same limitation. I have implemented
> > something like this before.  For each fb_open, the current->pid can be
> > saved into a "white list" and removed for each fb_close.  fbcon can then
> > compare this to the pid of the vt it's switching from.

The application cannot play not nice unless it mmap()s the MMIO registers. To
be able to do that, it first has to clear FB_ACCELF_TEXT in var.accel_flags.

> > This is becoming to sound very ugly though.  I guess, the best way is to
> > really support Option "UseFBDev", or at least have the user decide if
> > he/she wants to have the hardware refreshed.  
> 
> I'm afraid I don't understand what you're saying here.

But I think you do agree :-) He says that if fbdev is active, the X server has
to be fbdev compliant and thus not mess with the hardware where it's not
allowed to.

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



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Michel Dänzer]

On Mit, 2003-03-12 at 09:24, Geert Uytterhoeven wrote:
> On 12 Mar 2003, Michel [ISO-8859-1] Dänzer wrote:
> > On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> > > On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> > > > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > > > 
> > > > > > > I actually prefer #3, and I already have working code for this.  We can
> > > > > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > > > > can disable this, and only drivers that are affected such as the riva,
> > > > > > > aty, radeon, etc can turn this on).
> > > > > > 
> > > > > > What exactly is a "trusted" console?
> > > > > 
> > > > > By default, the pid of each vt is -1.  When X loads, it installs its own
> > > > > VT (ie vt7), which in that case the pid of that particular vt == X's
> > > > > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > > > > we can safely assume that the hardware state is still sane, and if not,
> > > > > assume the hardware state is undefined.
> > > > 
> > > > Can you also detect when the app has opened the framebuffer device, and
> > > > assume it's playing nice when it has? (for Option "UseFBDev")
> > > 
> > > X using fbdev will also have the same limitation. I have implemented
> > > something like this before.  For each fb_open, the current->pid can be
> > > saved into a "white list" and removed for each fb_close.  fbcon can then
> > > compare this to the pid of the vt it's switching from.
> 
> The application cannot play not nice unless it mmap()s the MMIO registers. To
> be able to do that, it first has to clear FB_ACCELF_TEXT in var.accel_flags.

X will map the MMIO registers with Option "UseFBDev" and still play nice
(hopefully :).

> > > This is becoming to sound very ugly though.  I guess, the best way is to
> > > really support Option "UseFBDev", or at least have the user decide if
> > > he/she wants to have the hardware refreshed.  
> > 
> > I'm afraid I don't understand what you're saying here.
> 
> But I think you do agree :-) He says that if fbdev is active, the X server has
> to be fbdev compliant and thus not mess with the hardware where it's not
> allowed to.

I agree that's how it should be.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> Unfortunately, this is what we are trying to prevent.  X assumes that
> the console is in text mode, so only registers that affect text mode are
> restored.  Frequently, cursor registers and bitmaps, as an example, are
> not refreshed.  There's probably more, ie accel engine, etc.

Argh.. of course, cursor and accelerator registers are usually not 
restored, you're right at this. But the drivers usually leave the engine 
in the same state as when started. (A "restore" of accelerator engine 
registers is mostly impossible, because a complete restore would cause 
the last command to be executed again)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 06:27, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> > Unfortunately, this is what we are trying to prevent.  X assumes that
> > the console is in text mode, so only registers that affect text mode are
> > restored.  Frequently, cursor registers and bitmaps, as an example, are
> > not refreshed.  There's probably more, ie accel engine, etc.
> 
> Argh.. of course, cursor and accelerator registers are usually not 
> restored, you're right at this. But the drivers usually leave the engine 
> in the same state as when started. (A "restore" of accelerator engine 
> registers is mostly impossible, because a complete restore would cause 
> the last command to be executed again)
> 

The accel engine is probably not a problem if it uses mmio.  However,
engines that use command buffers are more susceptible to this if the
buffers can be dynamically allocated by the process.

The i810 for instance uses ringbuffers.  It has to be dynamically
allocated via agpgart.  Fortunately, the i810 can support 2 ringbuffers,
so X can use one and fb the other, so there's no conflict. 

Then you also have DRI joining in the confusion :-)

The best solution, personally, is to have one module controlling chipset
access -- DRM for 2D and 3D, and fb for video mode switching.

Tony



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> The accel engine is probably not a problem if it uses mmio.  However,
> engines that use command buffers are more susceptible to this if the
> buffers can be dynamically allocated by the process.

OK, ack.

> 
> The i810 for instance uses ringbuffers.  It has to be dynamically
> allocated via agpgart.  Fortunately, the i810 can support 2 ringbuffers,
> so X can use one and fb the other, so there's no conflict. 
> 
> Then you also have DRI joining in the confusion :-)

Not in my case :) The SiS DRI stuff is made in a way to prevent problems 
of this kind. But I ack that it might be on others.

> The best solution, personally, is to have one module controlling chipset
> access -- DRM for 2D and 3D, and fb for video mode switching.

Well. I personally don't want every graphics application to depend on 
kernel modules.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Geert Uytterhoeven]

On 5 Mar 2003, Antonino Daplas wrote:
> > 3) The resizing using stty is - how do I put this - slightly imperfect.
> > I don't know how you fbdev folks do it, but I am not used to think in
> > row/col categories, but *resolutions* instead. Apart from this - IMHO a
> > bit annoying - inconvenience, this method has further issues:
> > 
> > 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.

But if I say e.g. `fbset 800x600-90', I do want a 90 Hz 800x600 mode, whatever
the font may be.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Thomas Winischhofer]

Geert Uytterhoeven wrote:
>>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.
> 
> 
> But if I say e.g. `fbset 800x600-90', I do want a 90 Hz 800x600 mode, 
 > whatever the font may be.

Seems the fbdev people themselves aren't really happy with that stty 
solution...? :)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Thomas Winischhofer]

Further to my mail from a few minutes ago:

I wrote:
 > But I noticed another issue here:
 >
 > When switching to gfx mode during boot (ie as soon as the penguin
 > appears), the text console is aligned correctly at all edges, with all
 > lines visible.

 > But when "initial console" starts, the mode is again changed, and now
 > the last line of text is nearly invisible, its upper half appears at
 > the lower screen edge, the lower half is below the screen's edge. The
 > space between the penguin and the text is notably thicker.
 >
 > This can be recovered by switching to another VT and back. This makes
 > the penguin disappear, and restores the console dimensions/edges to
 > normal.

 > Interestingly, this only happens with 800x600; this mode is chosen
 > upon requesting 800x592 (because of the font size). At 1024x768,
 > everything is as it should.

I am almost sure that this has to do with the fact that I adapt var in 
my check_var from 800x592 to 800x600. Console (or whoever) seems to 
attempt to change the mode to its initially desired dimension on many 
occasions.

- This leads to the (unncessary) second mode switch during boot (when 
the "initial console" starts), assumingly because the xres does not 
match fontsize * rows,

- and probably is the reason for that vertical offset I see after this 
mode switch: The text area on the screen is shifted down by exactly 8 
pixels - 600-592=8

Any hints?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 22:16, Thomas Winischhofer wrote:
> 
> Further to my mail from a few minutes ago:
> 
> I wrote:
>  > But I noticed another issue here:
>  >
>  > When switching to gfx mode during boot (ie as soon as the penguin
>  > appears), the text console is aligned correctly at all edges, with all
>  > lines visible.
> 
>  > But when "initial console" starts, the mode is again changed, and now
>  > the last line of text is nearly invisible, its upper half appears at
>  > the lower screen edge, the lower half is below the screen's edge. The
>  > space between the penguin and the text is notably thicker.
>  >
>  > This can be recovered by switching to another VT and back. This makes
>  > the penguin disappear, and restores the console dimensions/edges to
>  > normal.
> 
>  > Interestingly, this only happens with 800x600; this mode is chosen
>  > upon requesting 800x592 (because of the font size). At 1024x768,
>  > everything is as it should.
> 
> I am almost sure that this has to do with the fact that I adapt var in 
> my check_var from 800x592 to 800x600. Console (or whoever) seems to 
> attempt to change the mode to its initially desired dimension on many 
> occasions.
> 

Strange.  If you boot at 800x600, the console will compute that as
100x37.  On fbcon_resize, it will request 800x592 but because the
difference is only 8, fb_set_var should be skipped, so no mode change
should happen throughout.  

> - This leads to the (unncessary) second mode switch during boot (when 
> the "initial console" starts), assumingly because the xres does not 
> match fontsize * rows,

At boot time, there are several times the display changes (not
necessarily mode changes) --  while the logo is being displayed, after
the logo got displayed, and during init.

> 
> - and probably is the reason for that vertical offset I see after this 
> mode switch: The text area on the screen is shifted down by exactly 8 
> pixels - 600-592=8
> 
> Any hints?
> 

I have no idea.  I booted with other drivers at 800x600 and get no ill
effects.  I get a margin at the bottom of 8 pixels.

How about checking what the offsets are during fb_pan_display()?

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Sorry, but I send mails faster than I can think sometimes:

 > - and probably is the reason for that vertical offset I see after this
 >  mode switch: The text area on the screen is shifted down by exactly 8
 > pixels - 600-592=8

Or perhaps the fbcon_resize stuff does

1) either not take the penguin into account,

or

2) does this too early, namely before the call to check_var()?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > 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.

I fixed this in my latest patch. You can use con2fb again!!!!!!

> > b) The call to fb_set_var() inside fbcon_resize() is checked for errors,
> > but not the call to fbcon_resize() from within fbcon_switch(). This
> > leads to catastrophic drawing errors if the requested mode is not
> > supported by the low level driver.
> 
> Yes, it's a bug.  I think I submitted a patch to fix that, but I'm not
> sure if James applied it to his tree.

Applied.

> Another solution is to reimplement resizing by fbset.  The code is not
> very difficult and can be added if most people want it.

:-( 

> 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.

???? stty rows 128 cols 48 works for me. It should'nt calling con_resize 
twice. 

> > 3) About y panning: In the 2.4 version of sisfb, I simply forced the
> > console to do y panning (unless positively disabled by the user) by
> > "patching" yres_virtual to the maximum, depending on the available video
> > memory. I am allowed to do that with the 2.5 API? (The rivafb code makes
> > be believe so...)
> 
> 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.

Scrolling needs alot of work. I plan to fix that.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 03:02, James Simmons wrote:
> > 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.
> 
> ???? stty rows 128 cols 48 works for me. It should'nt calling con_resize 
> twice. 
> 

It does.  You probably won't notice it if the driver supports flexible
video mode changing.  For drivers that don't it will fail.  For
instance, if a driver supports 800x600 and 1024x768 only, and stty is
used to change the mode from 1024x768 to 800x600, it will be done like
this:

resize to 800x768 <--- because no mode matches this, resizing fails
resize to 800x600

If you don't believe me, do an strace stty cols 80 rows 30.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> I am currently porting the SiS framebuffer driver to the - more or less
> - new API. Better late than never :)
> 
> Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for
> development, no fbdev patches)

Please try your driver with the patch I post and tell me what problems you 
still have. Most of those shoudl have been fixes now.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com