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

Re: [Linux-fbdev-devel] how to rotate 90 the LCD image

[irene7 <ir...@ma...>]

=20Thank=20your=20for=20your=20comprehensive=20explanation=20.
=20And=20i=20also=20get=20the=20information,that=20the=20embedded=20GUI=20sy=
stem=20can=20support=20it's=20GUI=20rotate=2090.
=20Is=20that=20true=20?
=20and=20if=20it=20is=20true,=20maybe=20it's=20efficiency=20would=20be=20a=20=
probelm?

-----Original=20message-----
From:Antonino=20Daplas=20<ad...@po...>
To:ir...@ma...
Cc:Linux=20Fbdev=20development=20list=20<lin...@li...=
.net>
Date:10=20Mar=202003=2010:06:45=20+0800
Subject:Re:=20[Linux-fbdev-devel]=20how=20to=20rotate=2090=20the=20LCD=20ima=
ge

On=20Sun,=202003-03-09=20at=2017:37,=20irene7=20wrote:
>=20
>=20=20HI~=20
>=20
>=20=20=20=20=20i=20am=20an=20newbie.=20and=20i=20have=20a=20trouble=20:
>=20=20=20=20=20my=20LCD=20driver=20is=20working=20fine=20,=20but=20the=20on=
ly=20problem=20is=20the=20LCD=20image=20is=20rotate=2090.
>=20=20=20=20=20what=20should=20i=20modified=20the=20driver=20to=20rotate=20=
it=20back?=20

Hmm,=20a=20lot=20of=20LCD=20hardware=20have=20this=20sort=20of=20problem.=20=
=20If=20you=20do=20not
have=20a=20hardware=20option=20to=20change=20how=20the=20data=20is=20to=20be=
=20displayed=20(such
as=20rotate=2090=20degrees=20the=20other=20way),=20you=20can=20do=20at=20lea=
st=20two=20things:

1.=20=20have=20your=20own=20fbcon-cfb*.c=20functions=20that=20draws,=20clear=
s=20and=20moves
pixels=20from=20top->bottom,=20right->left=20(90=20degrees=20CW)=20or=20bott=
om->top,
left->right=20(90=20degrees=20CCW).=20=20You=20may=20also=20want=20to=20pre-=
rotate
display->fontdata=20in=20your=20xxxfb_setup=20routine,=20so=20you=20don't=20=
degrade
performance.=20You=20also=20need=20to=20modify=20the=20fbcon_show_logo=20in=20=
fbcon.c=20to
do=20the=20same=20thing.=20=20The=20advantage=20of=20this=20method=20is=20yo=
u're=20going=20to=20have
a=20fairly=20efficient=20framebuffer=20console,=20the=20disadvantage=20is=20=
user
applications=20will=20not=20work.

2.=20=20The=20second=20method=20is=20to=20allocate=20a=20virtual=20framebuff=
er.=20=20Then=20on=20a
periodic=20basis,=20you=20transfer=20the=20data=20in=20the=20virtual=20frame=
buffer=20to=20the
actual=20framebuffer,=20doing=20the=20rotating=20on=20the=20fly.=20=20The=20=
advantage=20of
this=20method=20is=20user=20applications=20should=20work,=20the=20disadvanta=
ge=20is=20it=20is
not=20the=20most=20efficient=20method.

You=20can=20look=20at:=20

ftp://ssv-embedded.de/ssv/products/trm916/sample/x86/linux/fbdev

(authored=20by=20Henry)

for=20a=20template=20on=20how=20to=20implement=20#2.=20=20You=20still=20have=
=20to=20implement=20the
rotation=20yourself.=20=20If=20you=20have=20questions=20rotating=20the=20dat=
a,=20let=20me
know.


Tony

Re: [Linux-fbdev-devel] newbie question

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

On Mon, 2003-03-10 at 01:21, ayachi gherissi wrote:
> 
> hi  i'm newbie in framebuffer driver development
> 
> i have a graphics card siliconmotion 721 (Lynx3DM) i want to make the framebuffer driver i get the spec of the card
> 
> i take cyber2000fb driver and i start modifying it
> 
> 
> i activate pci burst 
>     enable linear memory
>     get memory size
>     calculate vclck
>     calculate mclck  
> 
> i know that each hardware is specfic
> my question is
> what other general steps related to hardware
> must i done to get things work
> 

You also need to modify the registers that determines the video mode
(ie, 1024x768 at 85 Hz), the type of colorspace (RGB, 8, 16, 24, 32
bit/pseudocolor, truecolor, directcolor etc), and the hardware color
look-up table (if using pseudocolor, directcolor).

Tony

Re: [Linux-fbdev-devel] how to rotate 90 the LCD image

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

On Sun, 2003-03-09 at 17:37, irene7 wrote:
> 
>  HI~ 
> 
>     i am an newbie. and i have a trouble :
>     my LCD driver is working fine , but the only problem is the LCD image is rotate 90.
>     what should i modified the driver to rotate it back? 

Hmm, a lot of LCD hardware have this sort of problem.  If you do not
have a hardware option to change how the data is to be displayed (such
as rotate 90 degrees the other way), you can do at least two things:

1.  have your own fbcon-cfb*.c functions that draws, clears and moves
pixels from top->bottom, right->left (90 degrees CW) or bottom->top,
left->right (90 degrees CCW).  You may also want to pre-rotate
display->fontdata in your xxxfb_setup routine, so you don't degrade
performance. You also need to modify the fbcon_show_logo in fbcon.c to
do the same thing.  The advantage of this method is you're going to have
a fairly efficient framebuffer console, the disadvantage is user
applications will not work.

2.  The second method is to allocate a virtual framebuffer.  Then on a
periodic basis, you transfer the data in the virtual framebuffer to the
actual framebuffer, doing the rotating on the fly.  The advantage of
this method is user applications should work, the disadvantage is it is
not the most efficient method.

You can look at: 

ftp://ssv-embedded.de/ssv/products/trm916/sample/x86/linux/fbdev

(authored by Henry)

for a template on how to implement #2.  You still have to implement the
rotation yourself.  If you have questions rotating the data, let me
know.


Tony

[Linux-fbdev-devel] how to rotate 90 the LCD image

[irene7 <ir...@ma...>]

=20=20=20=20
=20HI~=20

=20=20=20=20i=20am=20an=20newbie.=20and=20i=20have=20a=20trouble=20:
=20=20=20=20my=20LCD=20driver=20is=20working=20fine=20,=20but=20the=20only=20=
problem=20is=20the=20LCD=20image=20is=20rotate=2090.
=20=20=20=20what=20should=20i=20modified=20the=20driver=20to=20rotate=20it=20=
back?=20
=20=20=20
=20Thansk=20...


=20=20=20=20

Re: [Linux-fbdev-devel] Re: FBdev updates.

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

On Mon, 2003-03-10 at 06:54, Petr Vandrovec wrote:
> On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote:
> > On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> > 
> > As for synchronization, I was meaning to ask some pointers on that.  The
> > setup currently works like this:
> > 
> >                         (blink)
> > fbcon_cursor         fbcon_vbl_handler (interrupt or timer)   
> >      |                     |
> >      -----------------------
> >                |
> >            accel_cursor
> >                |
> >      -----------------------
> >      |                      |
> >   hardware              soft_cursor    accel_putcs    accel_putc
> >                             |              |               |
> >                             -------------- -----------------
> >                                            | 
> >                                    fb_get_buffer_offset
> >                                            |
> >                                      xxxfb_imageblit
> >                                            |
> >                                   -------------------
> >                                   |                  |
> >                               hardware           software
> > 
> > 
> > I was thinking of placing locks in accel_cursor and
> > fb_get_buffer_offset, but I'm not sure.
> 
> Maybe just auditing code is enough: cursor_on should be zero while
> we are inside accel_putc/putcs (or inside any other fb function), and
> if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making
> sure that fbcon_vbl_handler is not running on other CPU while we set
> cursor_on = 0 should be enough.

I think that's what happens.  cursor_on is set to 0 at the beginning of
fbcon_cursor(), and it remains 0 until the next fbcon_cursor() is
CM_DRAW or CM_MOVE.  And while cursor_on is 0, fbcon_vbl_handler just
exits immediately.  Yes, it's basically the code in 2.4, but instead of
using revc, it uses imageblit, and instead of allowing the drivers to do
the blinking, fbcon does it entirely, whether a hardware or software
cursor method is installed.  

> 
> > >     if fbdev provides hardware cursor... And HZ/50 delay after
> > >     putcs makes orientation on screen very complicated, as there
> > >     is no cursor while new characters are appearing on screen.
> > 
> > The delay is only for the blinking.  After drawing a character/stream of
> > characters, an explicit "draw cursor" command immediately follows (I
> > think) via fbcon_cursor.
> 
> Why we schedule cursor painting at all then? While we are inside putcs,
> we cannot paint cursor anyway (as we are busy with painting characters

I don't think any cursor painting is done while doing putcs, if the
CM_ERASE, putc/putcs, CM_DRAW/CM_MOVE sequence is followed.  Note that I
haven't verified if that particular sequence is followed, I just assume
the console layer does.

Tony

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Petr V. <van...@vc...>]

On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote:
> On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> 
> As for synchronization, I was meaning to ask some pointers on that.  The
> setup currently works like this:
> 
>                         (blink)
> fbcon_cursor         fbcon_vbl_handler (interrupt or timer)   
>      |                     |
>      -----------------------
>                |
>            accel_cursor
>                |
>      -----------------------
>      |                      |
>   hardware              soft_cursor    accel_putcs    accel_putc
>                             |              |               |
>                             -------------- -----------------
>                                            | 
>                                    fb_get_buffer_offset
>                                            |
>                                      xxxfb_imageblit
>                                            |
>                                   -------------------
>                                   |                  |
>                               hardware           software
> 
> 
> I was thinking of placing locks in accel_cursor and
> fb_get_buffer_offset, but I'm not sure.

Maybe just auditing code is enough: cursor_on should be zero while
we are inside accel_putc/putcs (or inside any other fb function), and
if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making
sure that fbcon_vbl_handler is not running on other CPU while we set
cursor_on = 0 should be enough.

> >     if fbdev provides hardware cursor... And HZ/50 delay after
> >     putcs makes orientation on screen very complicated, as there
> >     is no cursor while new characters are appearing on screen.
> 
> The delay is only for the blinking.  After drawing a character/stream of
> characters, an explicit "draw cursor" command immediately follows (I
> think) via fbcon_cursor.

Why we schedule cursor painting at all then? While we are inside putcs,
we cannot paint cursor anyway (as we are busy with painting characters
at cursor position...) and fbcon_cursor(CM_DRAW) should restart timer interval
anyway (so you see cursor while you type characters, and not like Solaris
where cursor appears after you stop typing characters) (unfortunately when 
I tried to verify how it behaves on secondary head of matrox (which does not
have hardware cursor), I made a typo and ...

Unable to handle kernel NULL pointer dereference at virtual address 00000196
 printing eip:
c02f9258
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0060:[<c02f9258>]    Tainted: PFS
EFLAGS: 00010202
EIP is at fb_open+0x28/0xf0
eax: c6ed2c30   ebx: 00000020   ecx: 00000001   edx: c04848e0
esi: 00000002   edi: 00000000   ebp: c6ed2c30   esp: c4bb3f18
ds: 007b   es: 007b   ss: 0068
Process con2fb (pid: 18180, threadinfo=c4bb2000 task=d874d940)
Stack: 00000006 c8a8aae4 c4bb2000 00000000 c8a8aae4 c01669ea c6ed2c30 c8a8aae4
       dffe6830 c01435e3 c8a8aae4 c6ed2c30 dffe6830 00000000 c015af91 c6ed2c30
       c8a8aae4 00000002 bffffe7a dcaa5000 c4bb2000 c015adb7 ca74978c dffe6830
Call Trace:
 [<c01669ea>] chrdev_open+0xaa/0x110
 [<c01435e3>] file_ra_state_init+0x23/0x40
 [<c015af91>] dentry_open+0x1d1/0x1f0
 [<c015adb7>] filp_open+0x67/0x70
 [<c015b26b>] sys_open+0x5b/0x90
 [<c0109983>] syscall_call+0x7/0xb

Code: 8b 86 94 01 00 00 b9 01 00 00 00 8b 10 85 d2 74 1c b8 00 e0

so I'll have to check it tomorrow on real dualhead system...)

						Petr Vandrovec
						van...@vc...

Re: [Linux-fbdev-devel] Re: FBdev updates.

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

On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> Hi James,
>   I tried to use fb_cursor and I have quite a lot problems with
> it:
> (1) it uses global variables for storing last cursor value -
>     - but there is no global hardware, so after switching from
>     one fbdev to another you can have cursor with wrong shape,
>     wrong color and so on...
> (2) callback from timer for cursor blinking may set almost any
>     FB_CUR_* bits. But in this case fb_cursor callback may be
>     called from interrupt context, while accelerator is busy
>     and so on... Did I miss some synchronization? Best for me
>     would be disabling blinking code in fbcon completely:
>     in VGA mode cursor blinks automatically, and in graphics mode
>     more lightweight only 'flash' callback is more appropriate
>     for me. But then there is problem with

I've also noticed problems with 1 and 2, and I submitted a patch to
James that allocates resources on a per device basis instead of being
global and statically allocated.  This includes the cursor data
structures, cursor timer/vbl interrupt service, putcs buffer, and
optionally the softback buffer.  The last is probably not very important
for the present setup but may become useful later on (ie, multiple
active consoles).

As for synchronization, I was meaning to ask some pointers on that.  The
setup currently works like this:

                        (blink)
fbcon_cursor         fbcon_vbl_handler (interrupt or timer)   
     |                     |
     -----------------------
               |
           accel_cursor
               |
     -----------------------
     |                      |
  hardware              soft_cursor    accel_putcs    accel_putc
                            |              |               |
                            -------------- -----------------
                                           | 
                                   fb_get_buffer_offset
                                           |
                                     xxxfb_imageblit
                                           |
                                  -------------------
                                  |                  |
                              hardware           software


I was thinking of placing locks in accel_cursor and
fb_get_buffer_offset, but I'm not sure.
  
> (3) cursor_undrawn... I have no idea how is this supposed to work

In the present cursor api, the driver just needs to draw/undraw the
cursor whether by software or hardware.  So the problem here is with
cursors that does it's own blinking, such as text modes.

>     if fbdev provides hardware cursor... And HZ/50 delay after
>     putcs makes orientation on screen very complicated, as there
>     is no cursor while new characters are appearing on screen.

The delay is only for the blinking.  After drawing a character/stream of
characters, an explicit "draw cursor" command immediately follows (I
think) via fbcon_cursor.

Tony

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Petr V. <van...@vc...>]

Hi James,
  I tried to use fb_cursor and I have quite a lot problems with
it:
(1) it uses global variables for storing last cursor value -
    - but there is no global hardware, so after switching from
    one fbdev to another you can have cursor with wrong shape,
    wrong color and so on...
(2) callback from timer for cursor blinking may set almost any
    FB_CUR_* bits. But in this case fb_cursor callback may be
    called from interrupt context, while accelerator is busy
    and so on... Did I miss some synchronization? Best for me
    would be disabling blinking code in fbcon completely:
    in VGA mode cursor blinks automatically, and in graphics mode
    more lightweight only 'flash' callback is more appropriate
    for me. But then there is problem with
(3) cursor_undrawn... I have no idea how is this supposed to work
    if fbdev provides hardware cursor... And HZ/50 delay after
    putcs makes orientation on screen very complicated, as there
    is no cursor while new characters are appearing on screen.
    
					Thanks,
						Petr Vandrovec
						van...@vc...

[Linux-fbdev-devel] newbie question

[ayachi g. <aya...@ya...>]

hi  i'm newbie in framebuffer driver development

i have a graphics card siliconmotion 721 (Lynx3DM) i want to make the framebuffer driver i get the spec of the card

i take cyber2000fb driver and i start modifying it


i activate pci burst 
    enable linear memory
    get memory size
    calculate vclck
    calculate mclck  

i know that each hardware is specfic
my question is
what other general steps related to hardware
must i done to get things work

thank's


 



---------------------------------
Post your free ad now! Yahoo! Canada Personals

[Linux-fbdev-devel] how to rotate 90 the LCD image

[irene7 <ir...@ma...>]

=20HI~=20

=20=20=20=20i=20am=20an=20newbie.=20and=20i=20have=20a=20trouble=20:
=20=20=20=20my=20LCD=20driver=20is=20working=20fine=20,=20but=20the=20only=20=
problem=20is=20the=20LCD=20image=20is=20rotate=2090.
=20=20=20=20what=20should=20i=20modified=20the=20driver=20to=20rotate=20it=20=
back?=20
=20=20=20
=20Thansk=20...

Re: [Linux-fbdev-devel] Some questions

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

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

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

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

On Fri, Mar 07, 2003 at 10:52:28PM +0000, James Simmons wrote:
> 
> > 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 :-)

OK. I'll try it.

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

Re: [Linux-fbdev-devel] Some questions

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

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

Re: [Linux-fbdev-devel] Some questions

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

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

Re: [Linux-fbdev-devel] [BK updates]

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

On Sat, 2003-03-08 at 09:46, Antonino Daplas wrote:
> On Sat, 2003-03-08 at 08:26, James Simmons wrote:
> > 
> > Hi folks!!!
> > 
> >   More updates. Lots of fixes in drivers and in the upper layers. Its 
> > starting to really shape up. You can get the standard diff at
> > 
> 
> James, 
> 
> The ff. code is not totally correct:
> 

James, can you apply this?  Code logic is retained, it just simplifies
the calculations, removed unnecessary conditionals, and used
info->var.yres instead of var.yres.

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

[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.
> 
> Do you have something for tdfx? :)
> 
> It's not usable in depth 16 or 24 bits (I've reported it).

I will give it try. Sorry about the delay. 

Re: [Linux-fbdev-devel] [BK updates]

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

> On Sat, 8 Mar 2003, James Simmons wrote:
> >  scripts/Makefile                           |    4 
> >  scripts/pnmtologo                          |binary
> >  scripts/pnmtologo.c                        |  523 +
> 
> Are you really pushing the pnmtologo binary?

I did by mistake then removed it. It still is in the BK logs as being 
there.

Re: [Linux-fbdev-devel] [BK updates]

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

On Sat, 8 Mar 2003, James Simmons wrote:
>  scripts/Makefile                           |    4 
>  scripts/pnmtologo                          |binary
>  scripts/pnmtologo.c                        |  523 +

Are you really pushing the pnmtologo binary?

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

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

Re: [Linux-fbdev-devel] Some questions

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

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

Re: [Linux-fbdev-devel] Some questions

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

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

Re: [Linux-fbdev-devel] [BK updates]

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

On Sat, 2003-03-08 at 08:26, James Simmons wrote:
> 
> Hi folks!!!
> 
>   More updates. Lots of fixes in drivers and in the upper layers. Its 
> starting to really shape up. You can get the standard diff at
> 

James, 

The ff. code is not totally correct:

static int fbcon_resize(struct vc_data *vc, unsigned int width, 
			unsigned int height)
{
	struct display *p = &fb_display[vc->vc_num];
	struct fb_info *info = p->fb_info;
	struct fb_var_screeninfo var = info->var;
	int err; int x_diff, y_diff;
	int fw = vc->vc_font.width;
	int fh = vc->vc_font.height;

	var.xres = width * fw;
	var.yres = height * fh;
	x_diff = info->var.xres - var.xres;
	y_diff = info->var.yres - var.yres;
	if (x_diff < 0 || x_diff > fw ||
	   (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)
			return -EINVAL;
		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
		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;
	return 0;
}

I'm getting tired of explaining this repeatedly, so I'll give 2
hypothetical cases:

Case 1:

1. display is at 800x600, fonts are 8x16.
2. console requests width of 100, row of 37, which are computed as
800x592
3. the requested resolution is tested against the actual, and since the
difference between the actual yres (600) and requested yres (592) is
less than a character height, doing an fb_set_var() is skipped.
4. in the last 3 lines, p->vrows is adjusted, but it uses the requested
yres (592) instead of the actual (600).  This part is wrong.

Case 2:

1. again, display is at 800x600, fonts are 8x16
2. console requests width of 128, row of 48, which are computed as
1024x768. 
3. the requested resolution is tested against the actual, and determines
that it needs to do an fb_set_var() because the difference between the
requested and actual dimensions are greater than a character's
dimensions.
4. it first does a check if the resolution is acceptable
(FB_ACTIVATE_TEST).  The hardware supports it, so it passes the test.
5. it then proceeds changing the video mode (FB_ACTIVATE_NOW).  Look at
fb_set_var() in fbmem.c.  Note that the var returned from
xxfb_check_var() is placed in info->var before doing an
xxxfb_set_par().  So upon return, the requested var is the same as the
one in info->var
6. in the last two lines, it does not matter if it uses the requested
yres or the actual yres.  In this case, it will be the same.

So using info->var.yres, instead of var.yres is preferable because
info->var will always be right.  In this specific code, the effect is
probably insignificant, but I hate code that does not do what's
expected.  It might appear as a hard-to-catch bug later on.

Tony

Re: [Linux-fbdev-devel] Some questions

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

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

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

[<bl...@ds...>]

On Sat, 8 Mar 2003, James Simmons wrote:
> > 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.

Do you have something for tdfx? :)

It's not usable in depth 16 or 24 bits (I've reported it).

-- 
---------------------------------
pozdr.  Paweł Gołaszewski        
---------------------------------
CPU not found - software emulation...

[Linux-fbdev-devel] [BK updates]

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

Hi folks!!!

  More updates. Lots of fixes in drivers and in the upper layers. Its 
starting to really shape up. You can get the standard diff at

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

For the BK users just do a pull

bk pull http://fbdev.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              |  944 --
 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                | 1555 ++-
 drivers/video/sis/310vtbl.h                | 3373 +++++--
 drivers/video/sis/init.c                   | 6345 ++++++++-----
 drivers/video/sis/init.h                   |  310 
 drivers/video/sis/init301.c                |13192 ++++++++++++++++++-----------
 drivers/video/sis/init301.h                |  529 -
 drivers/video/sis/initdef.h                |  114 
 drivers/video/sis/oem300.h                 |  468 -
 drivers/video/sis/oem310.h                 |  239 
 drivers/video/sis/osdef.h                  |   13 
 drivers/video/sis/sis.h                    |   10 
 drivers/video/sis/sis_accel.c              |  176 
 drivers/video/sis/sis_accel.h              |  513 +
 drivers/video/sis/sis_main.c               | 4743 ++++++----
 drivers/video/sis/sis_main.h               |  686 -
 drivers/video/sis/vgatypes.h               |   26 
 drivers/video/sis/vstruct.h                |  687 -
 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, 46575 insertions(+), 33426 deletions(-)

through these ChangeSets:

<jsi...@ma...> (03/03/07 1.946)
   [SIS FBDEV] More sisfb driver updates.
   
   [FBCON] Many fixes dealing with reszing the screen.

<jsi...@ma...> (03/03/06 1.943)
   [SIS FBDEV] Make it compile as a module.

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