linux-fbdev-devel — linux-fbdev mailing list for project developers

[Linux-fbdev-devel] Re: [BK FBDEV] Updates.

[James S. <jsi...@in...>]

> Happily using this as sis fb doesn't compile in 2.5.64; This is the
> first 2.5 kernel that boots for me. X seems faster than under 2.4. This
> (almost) all sis based laptop likes things now.

Yeah!!!!!! I have more updates for the SIS drivers. I'm going to upload 
the new stuff in about 30 minutes.

Re: [Linux-fbdev-devel] Why aty128fb is so slow?

[James S. <jsi...@in...>]

> Hello,
> Could anybody explain why aty128fb is so slow?
> I'm using kernel-2.4.20.
> 
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro TF (prog-if 00 [VGA])
>         Subsystem: ATI Technologies Inc Rage 128 Pro TF
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
>         Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 32 (2000ns min), cache line size 08
>         Interrupt: pin A routed to IRQ 11
>         Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
>         Region 1: I/O ports at c000 [size=256]
>         Region 2: Memory at e7000000 (32-bit, non-prefetchable) [size=16K]
>         Expansion ROM at <unassigned> [disabled] [size=128K]
>         Capabilities: [50] AGP version 2.0
>                 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
>                 Command: RQ=0 SBA+ AGP- 64bit- FW- Rate=<none>
>         Capabilities: [5c] Power Management version 2
>                 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 
> Computer has Athlon 1.8+ processor on K7VTA3 motherboard.
> 
> In directory with 5000 files ls on console takes more than 6 seconds.
> In xterm or rxvt ls takes only 0.6 s.

Because the driver is completely unaccelerated. Everything is drawn pixel 
by pixel :-( 2.5.X is much faster :-)

[Linux-fbdev-devel] Why aty128fb is so slow?

[Witold F. <wi...@po...>]

Hello,
Could anybody explain why aty128fb is so slow?
I'm using kernel-2.4.20.

01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro TF (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc Rage 128 Pro TF
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min), cache line size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
        Region 1: I/O ports at c000 [size=256]
        Region 2: Memory at e7000000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [50] AGP version 2.0
                Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
                Command: RQ=0 SBA+ AGP- 64bit- FW- Rate=<none>
        Capabilities: [5c] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-


Computer has Athlon 1.8+ processor on K7VTA3 motherboard.

In directory with 5000 files ls on console takes more than 6 seconds.
In xterm or rxvt ls takes only 0.6 s.

-- 
Witold Filipczyk
<wi...@po...>

[Linux-fbdev-devel] Re: [BK FBDEV] Updates.

[Thomas Z. <Th...@zi...>]

On Thu, 6 Mar 2003 08:40:14 -0800 (PST)
James Simmons <jsi...@in...> wrote:

> 
> Linus, please do a
> 
> 	bk pull http://fbdevA.bkbits.net/fbdev-2.5
> 
> This will update the following files:
[snip]
>  drivers/video/sis/325vtbl.h                | 2335 -----
>  drivers/video/sis/sisfb.h                  |  153
>  drivers/video/sstfb.h                      |  355
[snip]
>  include/linux/sisfb.h                      |  169
[snip]
>  drivers/video/sis/300vtbl.h                | 1373 ++-
>  drivers/video/sis/310vtbl.h                | 2465 ++++-
>  drivers/video/sis/init.c                   | 5841 ++++++++-----
>  drivers/video/sis/init.h                   |  303
>  drivers/video/sis/init301.c                |12286
>  ++++++++++++++++++----------- drivers/video/sis/init301.h            
>     |  508 -
>  drivers/video/sis/initdef.h                |  114
>  drivers/video/sis/oem300.h                 |  468 +
>  drivers/video/sis/oem310.h                 |  218
>  drivers/video/sis/osdef.h                  |   13
>  drivers/video/sis/sis.h                    |   10
>  drivers/video/sis/sis_accel.c              |  166
>  drivers/video/sis/sis_accel.h              |  509 +
>  drivers/video/sis/sis_main.c               | 4526 ++++++----
>  drivers/video/sis/sis_main.h               |  672 +
>  drivers/video/sis/vgatypes.h               |   26
>  drivers/video/sis/vstruct.h                |  683 +
[snip]
>  include/video/sisfb.h                      |  191
[snip]
> <jsi...@ma...> (03/03/05 1.939)
>    [FBDEV] Updates for the SIS fbdev driver to the new api. Removed
>    poll. We wil use signals in the future instead.
[snip]
> Diff is at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz


Happily using this as sis fb doesn't compile in 2.5.64; This is the
first 2.5 kernel that boots for me. X seems faster than under 2.4. This
(almost) all sis based laptop likes things now.

Thomas

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

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:th...@wi...          *** http://www.winischhofer.net

Re: [Linux-fbdev-devel] Some questions

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

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

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

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:	th...@wi...
W:	http://www.winischhofer.net/linuxsisvga.shtml
S:	Maintained



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

Re: [Linux-fbdev-devel] Some questions

[James S. <jsi...@in...>]

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

Re: [Linux-fbdev-devel] Some questions

[James S. <jsi...@in...>]

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

Re: [Linux-fbdev-devel] Some questions

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

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

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

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:th...@wi...            http://www.winischhofer.net/

Re: [Linux-fbdev-devel] Some questions

[James S. <jsi...@in...>]

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

Re: [Linux-fbdev-devel] Adding Radeon 9100 support to radeonfb.c

[Sven L. <lu...@dp...>]

On Fri, Mar 07, 2003 at 05:50:04PM +0100, pem3v78 wrote:
> Has anyone started working on this ?
> 
> Whoever has any documentation on this chip please send it to me.

It is just a rebranded radeon 8500. You could simply look at what
/proc/pci tells you and copy what is done for the 8500.

Friendly,

Sven Luther

[Linux-fbdev-devel] Adding Radeon 9100 support to radeonfb.c

[pem3v78 <pe...@wp...>]

Has anyone started working on this ?

Whoever has any documentation on this chip please send it to me.

Re: [Linux-fbdev-devel] Some questions

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

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

[Linux-fbdev-devel] [PATCH]: Improvements/fixes to fbcon

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

James,

Attached is a patch hopefully to improve/fix the current framebuffer
framework.  The patch is quite massive, so I'll enumerate the changes:

1.  Resource allocation

	Allocation of fbcon resources will be acquired on a per device
(fb_info) basis.  This includes data for the cursor, the cursor
timer/vbl irq handler, the scrollback buffer, and optionally the pixmap
buffer.  The justification for these changes may not be obvious right
now (since only 1 console is active at a time), but it should at least
make it ready for the future when multiple active consoles are to be
supported

2. Console mapping

	a. fb_console_init
	
	The current method of determining which framebuffer should be mapped to
the console on initialization is incorrect for 2.5 (it's okay for 2.4)
because of the separation and modularity of fbcon/fbdev.  It currently
uses registered_fb[num_registered_fb-1].  This is incorrect if the user
does something like this:

modprobe firstfb; modprobe secondfb; rmmod firstfb; modprobe fbcon

So, it now searches for the first valid framebuffer in registered_fb[]
instead.

	b. set_con2fb_map

	There are numerous problems with this.  The first one is related to
2.a.  The second one is it uses take_over_console().  The problem with
this method is that it will call fbcon_startup() several times. (In 2.4
fbcon_startup is called only once).  Since it is in fbcon_startup where
resources are allocated, doing set_con2fb_map more than once will cause
resource leaks (cursor timer, info->display_fg, etc).  

	The change is to deallocate all acquired resources when a particular
framebuffer is not mapped anymore to any of the console.  Basically,
fbdev will be dissociated from fbcon.

	Thirdly, the code will not work, due to various reasons, if fbcon is
compiled as a module.  This is also fixed.

	set_con2fb_map should now work if fbcon is compiled statically or as a
module, and fbcon will also load correctly even when there is no
registered framebuffer.  The user can then use con2fbmap later on.

3. Forced register updates

	This may be useful in cases when switching from a tty where X is
currently  active.  It basically checks for vt_cons[con]->vt_pid.  If
this value is valid, it means a process has installed its own VT, so
switching from that tty will be "untrusted".  fb_set_var will force an
fb_set_par whether var has changed or not

4. Minor fixes to scrolling and fbcon_resize

	The test done in fbcon_resize is now more liberal.  This is congruent
with Geert's accel_clear_margins() fix.  Also, scrollback_phys_max and
p->vrows are now updated on time in hope of fixing some panning glitches

5. Minor fixes in fbmon.c

	The functions fb_get_mode and fb_validate_mode should now also consider
the dotclock, besides hsync and vsync.

6. Reference counting of buffer usage inf accel_putcs

	Reference counting is done for fb_pixmap->addr, hopefully to improve
concurrency even more.

7. Cosmetic changes

	All kernel parameters are standardized to [driver]fb.  Also fixed
affected docs in Documentation/fb/*.


The diff is against 2.5.64 + fbdev.diff.gz (Mar  6 23:58).
 
Tony

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

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:th...@wi...            http://www.winischhofer.net/

Re: [Linux-fbdev-devel] Some questions

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

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

Re: [Linux-fbdev-devel] Some questions

[Geert U. <ge...@li...>]

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 <ge...@li...>
+ *
+ *  --------------------------------------------------------------------------
+ *
+ *  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 -- ge...@li...

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

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

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:th...@wi...            http://www.winischhofer.net/

[Linux-fbdev-devel] [BK FBDEV] Updates.

[James S. <jsi...@in...>]

Linus, please do a

	bk pull http://fbdevA.bkbits.net/fbdev-2.5

This will update the following files:

 drivers/video/aty128fb.c                   | 2353 -----
 drivers/video/maxinefb.h                   |   37
 drivers/video/pm2fb.h                      |  218
 drivers/video/pm3fb.h                      | 1284 ---
 drivers/video/pmag-ba-fb.h                 |   24
 drivers/video/pmagb-b-fb.h                 |   32
 drivers/video/sis/325vtbl.h                | 2335 -----
 drivers/video/sis/sisfb.h                  |  153
 drivers/video/sstfb.h                      |  355
 include/asm-alpha/linux_logo.h             |   27
 include/asm-arm/linux_logo.h               |   19
 include/asm-i386/linux_logo.h              |   27
 include/asm-ia64/linux_logo.h              |   28
 include/asm-m68k/linux_logo.h              |  924 --
 include/asm-m68knommu/linux_logo.h         |   13
 include/asm-mips/linux_logo.h              |   43
 include/asm-mips/linux_logo_dec.h          |  907 --
 include/asm-mips/linux_logo_sgi.h          |  919 --
 include/asm-mips64/linux_logo.h            |  919 --
 include/asm-parisc/linux_logo.h            | 1438 ---
 include/asm-ppc64/linux_logo.h             |   26
 include/asm-sh/linux_logo.h                | 1418 ---
 include/asm-sparc/linux_logo.h             |  934 --
 include/asm-sparc64/linux_logo.h           |  934 --
 include/asm-um/linux_logo.h                |    6
 include/asm-x86_64/linux_logo.h            |   29
 include/linux/sisfb.h                      |  169
 arch/mips64/Kconfig                        |    4
 arch/ppc/syslib/prom.c                     |    3
 arch/ppc/syslib/prom_init.c                |   28
 arch/ppc64/kernel/prom.c                   |   27
 drivers/char/vt.c                          |    8
 drivers/video/Kconfig                      |   23
 drivers/video/Makefile                     |    9
 drivers/video/aty/Makefile                 |    2
 drivers/video/aty/aty128fb.c               | 2362 +++++
 drivers/video/aty/atyfb.h                  |  133
 drivers/video/aty/atyfb_base.c             | 2124 ++---
 drivers/video/aty/mach64_accel.c           |   51
 drivers/video/aty/mach64_ct.c              |  846 +
 drivers/video/aty/mach64_cursor.c          |    4
 drivers/video/aty/mach64_gx.c              |   18
 drivers/video/aty/xlinit.c                 |  367
 drivers/video/aty128fb.c                   |  162
 drivers/video/cfbcopyarea.c                |  218
 drivers/video/cfbfillrect.c                |   12
 drivers/video/cfbimgblt.c                  |  255
 drivers/video/cg6.c                        |    8
 drivers/video/console/fbcon.c              |  926 +-
 drivers/video/console/fbcon.h              |    4
 drivers/video/console/newport_con.c        |   69
 drivers/video/console/vgacon.c             |  801 -
 drivers/video/dnfb.c                       |    9
 drivers/video/fbmem.c                      |  340
 drivers/video/fbmon.c                      |    3
 drivers/video/ffb.c                        |   12
 drivers/video/hgafb.c                      |   15
 drivers/video/hitfb.c                      |    2
 drivers/video/hpfb.c                       |    2
 drivers/video/i810/i810.h                  |    9
 drivers/video/i810/i810_accel.c            |  150
 drivers/video/i810/i810_main.c             |  486 -
 drivers/video/i810/i810_main.h             |   14
 drivers/video/imsttfb.c                    | 1616 +--
 drivers/video/logo/Kconfig                 |   75
 drivers/video/logo/Makefile                |   27
 drivers/video/logo/clut_vga16.ppm          |   20
 drivers/video/logo/logo.c                  |  100
 drivers/video/logo/logo_dec_clut224.ppm    | 1604 +++
 drivers/video/logo/logo_linux_clut224.ppm  | 1604 +++
 drivers/video/logo/logo_linux_mono.pbm     |  203
 drivers/video/logo/logo_linux_vga16.ppm    | 1604 +++
 drivers/video/logo/logo_mac_clut224.ppm    | 1604 +++
 drivers/video/logo/logo_parisc_clut224.ppm | 1604 +++
 drivers/video/logo/logo_sgi_clut224.ppm    | 1604 +++
 drivers/video/logo/logo_sun_clut224.ppm    | 1604 +++
 drivers/video/logo/logo_superh_clut224.ppm | 1604 +++
 drivers/video/logo/logo_superh_mono.pbm    |  203
 drivers/video/logo/logo_superh_vga16.ppm   | 1604 +++
 drivers/video/maxinefb.c                   |    2
 drivers/video/modedb.c                     |    8
 drivers/video/neofb.c                      |  113
 drivers/video/pm2fb.c                      |    2
 drivers/video/pm3fb.c                      |    3
 drivers/video/pmag-ba-fb.c                 |    2
 drivers/video/pmagb-b-fb.c                 |    2
 drivers/video/q40fb.c                      |    1
 drivers/video/radeonfb.c                   |    1
 drivers/video/riva/fbdev.c                 |  405
 drivers/video/riva/nv_driver.c             |  156
 drivers/video/riva/rivafb.h                |    2
 drivers/video/sgivwfb.c                    |  192
 drivers/video/sis/300vtbl.h                | 1373 ++-
 drivers/video/sis/310vtbl.h                | 2465 ++++-
 drivers/video/sis/init.c                   | 5841 ++++++++-----
 drivers/video/sis/init.h                   |  303
 drivers/video/sis/init301.c                |12286 ++++++++++++++++++-----------
 drivers/video/sis/init301.h                |  508 -
 drivers/video/sis/initdef.h                |  114
 drivers/video/sis/oem300.h                 |  468 +
 drivers/video/sis/oem310.h                 |  218
 drivers/video/sis/osdef.h                  |   13
 drivers/video/sis/sis.h                    |   10
 drivers/video/sis/sis_accel.c              |  166
 drivers/video/sis/sis_accel.h              |  509 +
 drivers/video/sis/sis_main.c               | 4526 ++++++----
 drivers/video/sis/sis_main.h               |  672 +
 drivers/video/sis/vgatypes.h               |   26
 drivers/video/sis/vstruct.h                |  683 +
 drivers/video/skeletonfb.c                 |    6
 drivers/video/softcursor.c                 |   72
 drivers/video/sstfb.c                      |   16
 drivers/video/tdfxfb.c                     |   31
 drivers/video/tgafb.c                      |   18
 drivers/video/tridentfb.c                  |    4
 drivers/video/vga16fb.c                    |  145
 include/linux/fb.h                         |   43
 include/linux/linux_logo.h                 | 1435 ---
 include/video/mach64.h                     |   75
 include/video/maxinefb.h                   |   37
 include/video/pm3fb.h                      | 1284 +++
 include/video/pmag-ba-fb.h                 |   24
 include/video/pmagb-b-fb.h                 |   32
 include/video/sgivw.h                      |   40
 include/video/sisfb.h                      |  191
 include/video/sstfb.h                      |  355
 include/video/vga.h                        |   23
 scripts/Makefile                           |    4
 scripts/pnmtologo                          |binary
 scripts/pnmtologo.c                        |  523 +
 130 files changed, 45047 insertions(+), 32138 deletions(-)

through these ChangeSets:

<jsi...@ma...> (03/03/05 1.941)
   [TWIN TURBO FBDEV] Ported over to new api.

<jsi...@ma...> (03/03/05 1.940)
   [FBCON] Help clear margins for modes where the resolution does quite fit the console size.

<jsi...@ma...> (03/03/05 1.939)
   [FBDEV] Updates for the SIS fbdev driver to the new api. Removed poll. We wil use signals in the future instead.

<jsi...@ma...> (03/03/03 1.936)
   [FBDEV] Accelerated functions pass in const structs.

   [ATY128 FBDEV] Gcc compile issue fixes.

<jsi...@ma...> (03/03/03 1.935)
   [GENRIC ACCEL] Megred David Millers changes with my own.

   [FBCON] Small scrolling fix.

<jsi...@ma...> (03/02/28 1.931)
   [FRAMEBUFFER]: cfbcopyarea accesses fb without using FB_{READ,WRITE}L.

<jsi...@ma...> (03/02/27 1.929)
   [ATY FBDEV] Rage XL cards can now be booted with needed the BIOS :-)

   [FBCON] Moving to use ring buffers and DMA cards.

<jsimmons@kozmo.(none)> (03/02/26 1.926)
   [ATY128 FBDEV] Moved aty128fb to aty/ and a few minor changes so aty128fb.c compiles with the newest compiler standards.

<jsimmons@kozmo.(none)> (03/02/26 1.925)
   [FBCON] More struct display cleanup. Also killed off static buffer for accel_putcs.

<jsi...@ma...> (03/02/24 1.923)
   [FBDEV] Minor fixes for logo code.

   [FBCON] More optimizations for drawing a string of characters.

   [VGACON] Using more code from video/vga.h.
   [VGA] Changes membase to unsigned long to support 64 bit platforms.


<jsi...@ma...> (03/02/19 1.913.1.3)
   [FBDEEV] Need to add support to build pnmtologo.

<jsi...@ma...> (03/02/19 1.913.1.1)
   Removed obsolete functions in fbcon.c and re-enabled mapping console(s) to a framebuffer device. A few compile fixes for rivafb and using standard macros for vgacon.c.

<jsi...@ma...> (03/02/16 1.913)
   [FBDEV] Data in struct fb_image is now const.

   [FBDEV] Updates to the logo code. We seperated it into two functions.

   [I810 FBDEV] Updates to the driver. PCI hooks for PCI supsend and resume to save the AGP GART mapping during power saving.

   [ATY 128] Add proper support for two graphics cards. Also added support for two more models of the Rage 128.

   [SGIVW FBDEV] Updates for the SGI Visual Workstation framebuffer.


<jsi...@ma...> (03/02/13 1.910)
   [LOGO] New better logo code.

   [FBDEV] Moved a few more header files.

<jsi...@ma...> (03/02/11 1.909)
   [FBCON] Removal of useless code.

<jsi...@ma...> (03/02/11 1.906)
   [ATY FBDEV] Reversed mobilty patches. They busted every other card.

<jsi...@ma...> (03/02/09 1.900)
   [ATY FBDEV] Updates to support Rage Mobility Chipstes.

<jsi...@ma...> (03/01/30 1.899)
   [RIVA FBDEV] SUpprot Directcolor mode. Needed for some cards.

<jsimmons@kozmo.(none)> (03/01/28 1.897)
   [NEOMAGIC FBDEV] Fix to work with no 21xx versions of the chip.

<jsi...@ma...> (03/01/28 1.889.53.3)
   [RADEON FBDEV] Add cursor support. Now the cursor is back.
   [RIVA FBDEV] Added support for interlace mode and are now using TRUECOLOR instead of DIRECTCOLOR. Setting the graphics card in DIRECTCOLOR confusses the X server.

<jsi...@ma...> (03/01/26 1.889.53.2)
   Accel rountines pass in constant data into each function. The reason being was some of the code in the upper layers depended on the data being passed to the low level function not be altered because the upper layers was altering the data themselves.

   Pan display fix for fbcon.c. p->vrow needed to be updated.

   PPC build fix for fbmon.c

   I810 fbdev updates.

<jsi...@ma...> (03/01/17 1.889.53.1)
   [GENERIC ACCELERATION] Fixed the generic image drawing function tfor 64 bit machines.

   [RIVA FBDEV] The cursor and imageblit functions have been fixed.


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

Re: [Linux-fbdev-devel] Some questions

[James S. <jsi...@in...>]

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

Re: [Linux-fbdev-devel] Some questions

[James S. <jsi...@in...>]

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

[Linux-fbdev-devel] Radeon Mobility M6 LY - Various Issues

[<to...@au...>]

I own a Toshiba notebook (satellite 1900-303) that uses a Radeon Mobility
M6 LY. I encountered many problems using this video card with framebuffer,
I'm explaining them here.-
I'm using linux 2.4.20 and i've tryed the original framebuffer driver and
then this one: http://www.berserk.demon.co.uk/linux/radeonfb/. Both give
me the same problems.-
First [little] problem: the whole screen is "moved up" a couple of
millimeters. So the first line of text is halt cut out and on the bottom
there is some blank space. If I do "fbset -vsync high", the screen returns
on its correct position: perfectly centered in the LCD screen. I'd like to
understand why this happens, and why setting vsync high solved the
problem.The VESA framebuffer has the same problem, but I can't solve it with
vsync=high.-
Second [very annoying] problem: when there is the switch from VGA to
framebuffer and from framebuffer to Xwindows often (not always!) happens
that the screen stasts flickering drawing many horizontal lines. From that
condition if I switch a couple of times from X to console and vice versa
the problem disappears, and come back randomally if I switch again from X
to console some times. I already heard about this problem from a user with
a sony vaio notebook.I think that this problem could be related with pixclock: if I simply
change the pixclock some times (instead of switching from and to X and
console) I encounter the same problem (flickering with horizontal lines
every 4 - 6 pixclock changes, returns almost every next pixclock change).The same issue is present also with the Xfree86 driver, even with a
standard VGA console.I use 1024x768, with 800x600 the problem is less visible but still there.
-
Third [not very important] problem: if I try to user
video=radeon:1024x768-16, fbset tells me that it's using 16bpp, but I
think that actually they're 4 (the penguin logo looks horrible).-
Fourth [last!] problem, maybe OT, maybe not: when using DRI on Xfree86
(and the xfree radeon driver) AND the framebuffer console, if I switch a
couple of times from console to X the graphic interface crashes (I can't
see anything logic but I can still reboot with ctrl+alt+del). Do you have
any idea about this?-
Thank you for your time.
I'd like also to test some pre-release radeon drivers if they exist,
please tell me if I can help.-
Paride

Re: [Linux-fbdev-devel] Some questions

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

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