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

[Linux-fbdev-devel] Re: gpm selection vs VGA console & fbcon

[Daniel B. <da...@cg...>]

Benjamin Herrenschmidt <be...@ke...> writes:

> There's an endian bug that have been around for some time causing
> text & attributes to be flipped when doing selections with gpm
> in console mode with VGA console enabled & running on an fbdev.
> 
> I didn't follow that closely, but since it's popping up again for
> users I beleive a fix was never merged in the main tree. Is there
> such a patch available or it's still on the list of "things to
> look into one day"  ?

I have a patch still that fixes it, and i keep inserting it into my
tree.

3 liner to include/asm-ppc/vga.h
4 liner to drivers/video/fbcon.c
(this is really two seperate patches, I wasn't about to set up two
trees simply to get 20 lines worth of diff. :P)

*** vga.h	Wed Jul  4 10:58:40 2001
--- /root/linux/include/asm-ppc/vga.h	Thu Jun 28 14:22:02 2001
*************** extern inline u16 scr_readw(volatile con
*** 37,42 ****
--- 37,45 ----
  
  #define VT_BUF_HAVE_MEMCPYW
  #define scr_memcpyw	memcpy
+ #define VT_BUF_HAVE_MEMCPYF
+ #define scr_memcpyw_to memcpy
+ #define scr_memcpyw_from memcpy
  
  #endif /* !CONFIG_VGA_CONSOLE && !CONFIG_MDA_CONSOLE */
  
*** fbcon.c	Tue Jul  3 17:58:41 2001
--- /root/linux/drivers/video/fbcon.c	Wed Jun 27 14:52:59 2001
*************** static void fbcon_invert_region(struct v
*** 1954,1966 ****
  	if (!conp->vc_can_do_color)
  	    *p++ ^= 0x0800;
  	else if (conp->vc_hi_font_mask == 0x100) {
! 	    u16 a = *p;
  	    a = ((a) & 0x11ff) | (((a) & 0xe000) >> 4) | (((a) & 0x0e00) << 4);
! 	    *p++ = a;
  	} else {
! 	    u16 a = *p;
  	    a = ((a) & 0x88ff) | (((a) & 0x7000) >> 4) | (((a) & 0x0700) << 4);
! 	    *p++ = a;
  	}
  	if (p == (u16 *)softback_end)
  	    p = (u16 *)softback_buf;
--- 1954,1966 ----
  	if (!conp->vc_can_do_color)
  	    *p++ ^= 0x0800;
  	else if (conp->vc_hi_font_mask == 0x100) {
! 	    u16 a = scr_readw(p);
  	    a = ((a) & 0x11ff) | (((a) & 0xe000) >> 4) | (((a) & 0x0e00) << 4);
! 	    scr_writew(a, p++);
  	} else {
! 	    u16 a = scr_readw(p);
  	    a = ((a) & 0x88ff) | (((a) & 0x7000) >> 4) | (((a) & 0x0700) << 4);
! 	    scr_writew(a, p++);
  	}
  	if (p == (u16 *)softback_end)
  	    p = (u16 *)softback_buf;


> ;)
> 
> Ben.
> 
> 
> ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

-- 
"Last night, I walked up to this beautiful woman in a bar and
asked her, "Do you live around here often?"  She said, "You're
wearing two different colored socks."  I said, "Yes, but to me
they're the same because I go by thickness."  Then she asked,
"How do you feel?"  and I said, "Well, you know when you're
sitting on a chair and you lean back so you're just on two legs
then you lean too far and you almost fall over but at the last
second you catch yourself?  I feel like that all the time."
"-Steven Wright

[Linux-fbdev-devel] gpm selection vs VGA console & fbcon

[Benjamin H. <be...@ke...>]

There's an endian bug that have been around for some time causing
text & attributes to be flipped when doing selections with gpm
in console mode with VGA console enabled & running on an fbdev.

I didn't follow that closely, but since it's popping up again for
users I beleive a fix was never merged in the main tree. Is there
such a patch available or it's still on the list of "things to 
look into one day"  ? 

;)

Ben.

Re: i810 kernel intergation into version 2.4.4 was Re: [Linux-fbdev-devel] Query on framebuffer implementations

[tea a. <th...@ag...>]

Am Thursday 05 July 2001 21:00, schrieb Jeff Garzik: / On Thursday 05 July 
2001 21:00, Jeff Garzik wrote:
> tea age wrote:
> > Sorry for answering that late. I uploaded today changes I made inside the
> > kernel sources versions 2.2.18 and 2.4.4
> > Please check following link.
> >
> > http://www.visuelle-maschinen.de/ctfb/fb/drivers/i810.kernelmerges/
>
> Cool!
>
> Have you tested it with fbtest, or similar?
>
> Last time I saw the i810fb code running on an i810 machine, it was not
> reliable at all.

It works fine for me. Bugs I do not know so far. BUT there is an issue if you 
like to run XFree and the i810fb in parallel (XFBDev on top of i810fb should 
work).This is not a bug, neither a feature! It is from my point of view an 
implementing problem of the agpgart stuff (no memory server). 

Details you can find under

http://vis...@ww.../public_ftp/fb/drivers/i810/README.i810fb_XFree_Issue

I uploaded this file today and it contains some mail exchange about this 
matter. Unfortunately I have not the power to solve this. 

Thomas

Re: [Linux-fbdev-devel] i810/815 Frame Buffer

[tea a. <th...@ag...>]

Am Saturday 07 July 2001 06:09, schrieb pa...@ra...: / On Saturday 07 
July 2001 06:09, pa...@ra... wrote:
> Hi,
>
> I downloaded the drivers from :
>
> http://www.visuelle-maschinen.de/ctfb/fb/drivers/i810.kernelmerges/
>
> I put everything on a 2.4.6 kernel, compiled in kernel.
> Everything worked ok , I have a Intel 815 Desktop Board .I didn't have
> time yet to test more so if a standart test procedure exist tell me so I
> can send you the results (fbtest ?).
>
> The only problem that I see is that when I didn't select the ctfb drivers
> in configure the compile failed telling that a union named ctfb cannot be
> found.After selecting ctfb worked.I think there is a dependency between
> i810fb and ctfb and I am not sure that this should be.
>
> Regards,
>
>  --
> ......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::......
>                   - iMedia Linux Senior Developer -
>          --    My favorite music : tcpdump > /dev/dsp   --
>
>
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

This should _not_ be. I'll check this out. 
Thomas

Re: [Linux-fbdev-devel] i810/815 Frame Buffer

[Herman T. <HEt...@cs...>]

Hmmm,

agpgart_be.c was copied to linux/drivers/char instead of linux/drivers/char=
/agp.

But now, i8018fb.c stops the compile with errors similar to the following:

warning: pasting "." and "vmode" does not give valid preprocessing token.


gcc --version on my Mandrake 8.0 system gives 2.96

Any ideas?
Herman

>>> Nicu Pavel <pa...@ra...> 07/09/01 09:04AM >>>
> Hi,
>=20
> I tried to do the same, everything compiles fine until linking.
> Then I get the following error:
>  "undefined reference to 'agp_init'
>=20
> Now, this is on a Mandrake 8.0 system. Which system/compiler did you
> use?
>=20
> Thanks
> Herman
>=20
=09
	My system is somehow :) a RH 7.0 .GCC 2.96-69.
	Make sure you include modification to linux/drivers/char/agp/agpgar=
t_be.c
=09
=09

--=20
......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::......
                  - iMedia Linux Senior Developer -
         --    My favorite music : tcpdump > /dev/dsp   --

Re: [Linux-fbdev-devel] i810/815 Frame Buffer

[Nicu P. <pa...@ra...>]

> Hi,
> 
> I tried to do the same, everything compiles fine until linking.
> Then I get the following error:
>  "undefined reference to 'agp_init'
> 
> Now, this is on a Mandrake 8.0 system. Which system/compiler did you
> use?
> 
> Thanks
> Herman
> 
	
	My system is somehow :) a RH 7.0 .GCC 2.96-69.
	Make sure you include modification to linux/drivers/char/agp/agpgart_be.c
	
	

-- 
......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::......
                  - iMedia Linux Senior Developer -
         --    My favorite music : tcpdump > /dev/dsp   --

Re: [Linux-fbdev-devel] i810/815 Frame Buffer

[Herman T. <HEt...@cs...>]

Hi,

I tried to do the same, everything compiles fine until linking.
Then I get the following error:
 "undefined reference to 'agp_init'

Now, this is on a Mandrake 8.0 system. Which system/compiler did you
use?

Thanks
Herman

****************************************
Herman Theron
Hermanus Magnetic Observatory
CSIR
PO Box 32
Hermanus
7200
South Africa
E-mail: het...@cs...
Phone: +27 28 3121196
Fax: +27 28 3122039
Cel: +27 82 697 8546

>>> "P@NiC" <pa...@ra...> 07/07/01 06:09AM >>>

Hi,

I downloaded the drivers from :

http://www.visuelle-maschinen.de/ctfb/fb/drivers/i810.kernelmerges/=20

I put everything on a 2.4.6 kernel, compiled in kernel.
Everything worked ok , I have a Intel 815 Desktop Board .I didn't have
time yet to test more so if a standart test procedure exist tell me so I
can send you the results (fbtest ?).

The only problem that I see is that when I didn't select the ctfb drivers
in configure the compile failed telling that a union named ctfb cannot be
found.After selecting ctfb worked.I think there is a dependency between
i810fb and ctfb and I am not sure that this should be.

Regards,

 --=20
......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::......
                  - iMedia Linux Senior Developer -
         --    My favorite music : tcpdump > /dev/dsp   --



_______________________________________________
Linux-fbdev-devel mailing list
Lin...@li...=20
http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel=20

[Linux-fbdev-devel] SiS 6326 driver

[Mattias N. <ni...@fd...>]

Hallo guys!

I'm a German student and I've got a SiS 6326 board in my machine. Bad news
for me, it is (was) really not supported very well. No I started writing
some fbdev code for the board after downloading some documentation from
www.sis.com.tw. And I finally got a somewhat working version that is able to
set a vidoemode and provide a minimal fbdev interface. Now some questions:

1. Someone interested to have a driver for SiS 6326 boards?
2. If I continue coding, should I contact SiS and ask for permission to
write a driver and for additional support?
3. Someone got a SiS 6326 chip to test the driver (the driver is actually
not that far, but it could be soon)?
4. What to do next?

Waiting for reply....

Mattias

Deege, Flick, Nissler und Schuster GdbR
http://www.fdns-web.de
http://www.fdns-services.de

[Linux-fbdev-devel] fbtest

[Michel <mic...@ii...>]

The good news is that I ran it in 565 with my aty128fb patch applied and it
seems to have passed all tests. :)


The slightly bad news is that on my Debian testing/unstable system I've had to
modify two things to get it to build: Add -lpnm for pnmtohex and remove
-Werror in Rules.make due to this:

pnmtohex.c: In function `convert_image':
pnmtohex.c:173: warning: implicit declaration of function `strerror'
pnmtohex.c:173: warning: format argument is not a pointer (arg 4)
pnmtohex.c:179: warning: format argument is not a pointer (arg 3)


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

Re: [Linux-fbdev-devel] i810/815 Frame Buffer (fwd)

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

Retry...

---------- Forwarded message ----------
Date: Sat, 7 Jul 2001 09:09:46 +0200 (CEST)
From: Geert Uytterhoeven <ge...@li...>
To: "P@NiC" <pa...@ra...>
Cc: lin...@li...
Subject: Re: [Linux-fbdev-devel] i810/815 Frame Buffer

On Sat, 7 Jul 2001, P@NiC wrote:
> I downloaded the drivers from :
> 
> http://www.visuelle-maschinen.de/ctfb/fb/drivers/i810.kernelmerges/
> 
> I put everything on a 2.4.6 kernel, compiled in kernel.
> Everything worked ok , I have a Intel 815 Desktop Board .I didn't have
> time yet to test more so if a standart test procedure exist tell me so I
> can send you the results (fbtest ?).

Yes, you can try fbtest. Just check it out from the CVS repository at
http://sourceforge.net/projects/linux-fbdev/. So far I didn't try it on ia32
yet (I did compile it on ia32, though), so I really like to know whether it
works.

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

[Linux-fbdev-devel] i810/815 Frame Buffer

[<P...@Ni...>]

Hi,

I downloaded the drivers from :

http://www.visuelle-maschinen.de/ctfb/fb/drivers/i810.kernelmerges/

I put everything on a 2.4.6 kernel, compiled in kernel.
Everything worked ok , I have a Intel 815 Desktop Board .I didn't have
time yet to test more so if a standart test procedure exist tell me so I
can send you the results (fbtest ?).

The only problem that I see is that when I didn't select the ctfb drivers
in configure the compile failed telling that a union named ctfb cannot be
found.After selecting ctfb worked.I think there is a dependency between
i810fb and ctfb and I am not sure that this should be.

Regards,

 -- 
......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::......
                  - iMedia Linux Senior Developer -
         --    My favorite music : tcpdump > /dev/dsp   --

[Linux-fbdev-devel] use of palette for TRUECOLOR modes... puzzled

[David T E. <dt...@us...>]

What do framebuffer drivers need to provide in terms of palette calls for
non-palette modes?  I'm writing a truecolor driver and much to my surprise
getting lots of calls for palette use...

-David Eger

Re: [Linux-fbdev-devel] 69030 driver

[Jordan C. <jo...@Ce...>]

Adrian - Thanks!

I will test CRT / Flatpanel mode as well as multihead display for the 69000 
this week and report my results back to you and the list.

Jordan

On Thursday 05 July 2001 12:56, Adrian Cox mentioned:
> A first version of my much delayed Asiliant (formerly Chips & Tech)
> 69000 and 69030 driver for Linux 2.4 is now available.
>
> The patch is at http://www.humboldt.co.uk/asiliant.html
>
> Feedback is requested from anybody with these chips, particularly if
> using a panel and a 69000. I'm on vacation for a week from the 8th of
> July, and when I get back I plan to work on:
> + making this into a module
> + supporting kernel command line arguments
> + testing and documenting twin display mode

Re: i810 kernel intergation into version 2.4.4 was Re: [Linux-fbdev-devel] Query on framebuffer implementations

[Jeff G. <jg...@ma...>]

tea age wrote:
> 
> Sorry for answering that late. I uploaded today changes I made inside the
> kernel sources versions 2.2.18 and 2.4.4
> Please check following link.
> 
> http://www.visuelle-maschinen.de/ctfb/fb/drivers/i810.kernelmerges/

Cool!

Have you tested it with fbtest, or similar?

Last time I saw the i810fb code running on an i810 machine, it was not
reliable at all.

-- 
Jeff Garzik      | Thalidomide, eh? 
Building 1024    | So you're saying the eggplant has an accomplice?
MandrakeSoft     |

[Linux-fbdev-devel] 69030 driver

[Adrian C. <ad...@hu...>]

A first version of my much delayed Asiliant (formerly Chips & Tech) 
69000 and 69030 driver for Linux 2.4 is now available.

The patch is at http://www.humboldt.co.uk/asiliant.html

Feedback is requested from anybody with these chips, particularly if 
using a panel and a 69000. I'm on vacation for a week from the 8th of 
July, and when I get back I plan to work on:
+ making this into a module
+ supporting kernel command line arguments
+ testing and documenting twin display mode

-- 
Adrian Cox   http://www.humboldt.co.uk/

i810 kernel intergation into version 2.4.4 was Re: [Linux-fbdev-devel] Query on framebuffer implementations

[tea a. <th...@ag...>]

Sorry for answering that late. I uploaded today changes I made inside the 
kernel sources versions 2.2.18 and 2.4.4
Please check following link. 

http://www.visuelle-maschinen.de/ctfb/fb/drivers/i810.kernelmerges/

Hope that helps.

Thomas

ps:
Somebody else asked for a 2.4.5 patch. Unfortunately I lost this mail. I hope 
he is watching the mailing list 









Am Friday 18 May 2001 06:55, schrieb Dawud, Muhd: / On Friday 18 May 2001 
06:55, Dawud, Muhd wrote:
> Hi all,
>
> I've donwloaded the updated i810 framebuffer drivers. Pardon me for asking
> but I'm not exactly a seasoned Linux whiz and I understand that this
> question is rather trivial but I've tried a few things so far but they
> haven't worked... I don't really know how I can install and enable the
> drivers. In the tarred file, there is only two files which are i810fb.c &
> i810fb.h. What I've done so far is :-
>
> 	- I've put both the i810fb.c and i810fb.h in the
> /usr/src/linux/drivers/video directory
> 	- I've also downloaded a previous version of drivers_video.tgz, and
> I've placed the Config.in and the fbmem.c file in the
> /usr/src/linux/drivers/video directory.
> 	- What's next.... any tips....
>
> Thanks,
> Dawud
>
>
>
> -----Original Message-----
> From: Tea Age [mailto:th...@vi...]
> Sent: Thursday, May 17, 2001 12:36 AM
> To: Geert Uytterhoeven; James Simmons
> Cc: Dawud, Muhd; antirez; lin...@li...
> Subject: Re: [Linux-fbdev-devel] Query on framebuffer implementations
>
> On Tuesday 15 May 2001 19:40, Geert Uytterhoeven wrote:
> > On Tue, 15 May 2001, James Simmons wrote:
> > > > Currently I'm using an i810 machine which does not support VESA 2.0,
> > >
> > > Their is a i810 framebuffer driver avaiable. It should be in fbdev CVS.
> >
> >                                                   ^^^^^^
> > `should be', like in `should be there, but it isn't yet'.
>
> I have no idea about the fbdev CVS and its policy.
> The latest copy I know, can be found here:
> http://www.visuelle-maschinen.de/ctfb/i810/i810fb1-06.tgz
>
> Thomas
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] console and overlay/underaly (was: Re: more penguins (fwd)

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

> > Something like this can also be done for vgacon. I haven't added that yet.
> 
> vgacon can do overlay ???

Not really. It is a trick you do with planes and the attribute fields in
text mode.

> > plus a flag to say what it is. This would break things tho. I guess it
> > will be for the fb filesystem for 2.5.X.
> 
> Maybe we should involve the author of fbtv, he could tell us the kind of
> stuff that would be needed for efficient hardware YUV->RGB and/or
> zooming in fbtv. I guess other app would have similar requirements.

Good idea.

Re: [Linux-fbdev-devel] console and overlay/underaly (was: Re: more penguins (fwd)

[<dol...@cl...>]

> > Apparently there's some interest in marginaly useful feature like
> > displaying penguin. I was wondering if there could be an interest in
> > even less useful feature like overlay support. Like a full-color, full
> > screen penguin under your text console.
> 
> Something like this can also be done for vgacon. I haven't added that yet.

vgacon can do overlay ???

The advantage of the hardware overlay is that there's zero system
overhead ; only the actual drawing function _might_ be slower depending
on the hardware. And you only eat up FB memory.

> This would be really nice. We had this discussion some time ago but
> nothing was resolved. Basically we have to develope a way to define what
> composes the framebuffer in a generic way. Something like fb_bitfields
> plus a flag to say what it is. This would break things tho. I guess it
> will be for the fb filesystem for 2.5.X.

Maybe we should involve the author of fbtv, he could tell us the kind of
stuff that would be needed for efficient hardware YUV->RGB and/or
zooming in fbtv. I guess other app would have similar requirements.

-- 
Romain DOLBEAU               | For a hill, men would kill,
ENS Cachan / Ker Lann        |   Why ? They do not know.
Thesard IRISA / CAPS         |      -- Metallica
dol...@cl...    |       in 'For Whom The Bell Tolls'

Re: [Linux-fbdev-devel] console and overlay/underaly (was: Re: more penguins (fwd)

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

> Apparently there's some interest in marginaly useful feature like
> displaying penguin. I was wondering if there could be an interest
> in even less useful feature like overlay support. Like a full-color,
> full screen penguin under your text console.

Something like this can also be done for vgacon. I haven't added that yet.

> The second (much less trivial, not yet implemented, and much
> more useful) is to use the video capability of the hardware ;
> the Permedia3 can overlay video (including blending) on the
> framebuffer. This could be used for still background picture,
> or for video overlay (fbtv from the xawtv package could
> benefit from hardware YUV->RGB conversion...)

This would be really nice. We had this discussion some time ago but
nothing was resolved. Basically we have to develope a way to define what
composes the framebuffer in a generic way. Something like fb_bitfields
plus a flag to say what it is. This would break things tho. I guess it
will be for the fb filesystem for 2.5.X. 
             				

Re: [Linux-fbdev-devel] fbdev accel lib

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

> Good idea. But note that acceleration in kernel space will be limited to
> rectfill, rectcopy and perhaps monochrome bitmap expansion for text drawing.
> Of course these are the first things you want to accelerate in a userland
> application too.

Don't forget accelerated drawing of the penguin :-)

> You may want to take a look at fbtest (check out CVS at
> http://www.sf.net/projects/linux-fbdev/). 

Nice :-) 

As a note for a common userland library. Well it would be nice to have
such a thing. The question is would such a library be accepted as a
standard. Most likely people would still go off and do their own thing
which I have no problem with. Often the needs of people vary when it comes
to graphics. 

At present we have the following fbdev libraries that I know of:

libfbx -> General purpose library.
libfgl -> for kaffe (Java embedded devices) 
directfb -> For embedded devices?
gtk/qte -> Again for embedded devices.
libGGI -> Some fbdev wrapper.
libsvga -> Newest version uses /dev/fb. Nice for older non X programs.

Then we have a whole bunch of windowing systems. 

[Linux-fbdev-devel] console and overlay/underaly (was: Re: more penguins (fwd)

[Romain D. <do...@ir...>]

Geert Uytterhoeven wrote:

> Here's a patch against 2.4.5 so we can display a decent number of
> penguins at boot time (wraps the display of the boot penguins when
> they can't all fit on one line).

Apparently there's some interest in marginaly useful feature like
displaying penguin. I was wondering if there could be an interest
in even less useful feature like overlay support. Like a full-color,
full screen penguin under your text console.

Such a feature isn't hard to hack: I have a hacked pm3fb that only
change a handful of lines. The hardware is set up as 32bpp, with
the upper 8 of each u32 being used for the ColorIndexed value used
at the console level. pm3fb is fully accelerated, so it's only
adding the hardware planemask. The other 24 bpp are full-color RGB
used when the CI color is 0 (background color), and are never touched
by the console subsytem. Any image put in these will appear as a
underlay :-) Given that software like fbi are usually broken and assume
32bpp is RGB8888, they can be directly used to put the underlay...

I don't think it's really something to be made standard part of the
API, but other might disagree :-)

The second (much less trivial, not yet implemented, and much
more useful) is to use the video capability of the hardware ;
the Permedia3 can overlay video (including blending) on the
framebuffer. This could be used for still background picture,
or for video overlay (fbtv from the xawtv package could
benefit from hardware YUV->RGB conversion...)

Any comments ?

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

[Linux-fbdev-devel] [PATCH] more penguins (fwd)

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

---------- Forwarded message ----------
Date: Tue, 3 Jul 2001 17:43:20 +1000
From: Christopher Yeoh <cy...@sa...>
To: Geert Uytterhoeven <ge...@li...>
Cc: lin...@vg...
Subject: [PATCH] more penguins

Hi,

Here's a patch against 2.4.5 so we can display a decent number of
penguins at boot time (wraps the display of the boot penguins when
they can't all fit on one line).

Chris.
-- 
ye...@au...
IBM OzLabs Linux Development Group
Canberra, Australia

diff -urN linux-2.4.5/drivers/video/fbcon.c linux-2.4.5-logo/drivers/video/fbcon.c
--- linux-2.4.5/drivers/video/fbcon.c	Thu Feb 22 14:25:28 2001
+++ linux-2.4.5-logo/drivers/video/fbcon.c	Sun Jul  1 17:10:27 2001
@@ -608,8 +608,16 @@
     	/* Need to make room for the logo */
 	int cnt;
 	int step;
-    
-    	logo_lines = (LOGO_H + fontheight(p) - 1) / fontheight(p);
+        int logo_rows;
+
+        /* Work out how many rows of logos will be displayed.
+           Leave at least two rows worth of logos at bottom to
+           display boot information */
+        logo_rows = (smp_num_cpus - 1) / (p->var.xres/(LOGO_W+8)) + 1;
+        if ((int)p->var.yres - logo_rows * (LOGO_H+8) < LOGO_H*2)
+            logo_rows = (p->var.yres - LOGO_H*2) / (LOGO_H+8);
+
+    	logo_lines = ((LOGO_H+8)*logo_rows + fontheight(p) - 9) / fontheight(p);
     	q = (unsigned short *)(conp->vc_origin + conp->vc_size_row * old_rows);
     	step = logo_lines * old_cols;
     	for (r = q - logo_lines * old_cols; r < q; r++)
@@ -2055,6 +2063,7 @@
     unsigned char *dst, *src;
     int i, j, n, x1, y1, x;
     int logo_depth, done = 0;
+    int yoff = 0, logo_count = 0;
 
     /* Return if the frame buffer is not mapped */
     if (!fb)
@@ -2115,8 +2124,8 @@
     if (p->fb_info->fbops->fb_rasterimg)
     	p->fb_info->fbops->fb_rasterimg(p->fb_info, 1);
 
-    for (x = 0; x < smp_num_cpus * (LOGO_W + 8) &&
-    	 x < p->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
+    x = 0;
+    while (logo_count < smp_num_cpus && yoff < p->var.yres - (LOGO_H*3)) {
     	 
 #if defined(CONFIG_FBCON_CFB16) || defined(CONFIG_FBCON_CFB24) || \
     defined(CONFIG_FBCON_CFB32) || defined(CONFIG_FB_SBUS)
@@ -2134,7 +2143,7 @@
 		/* have at least 8 bits per color */
 		src = logo;
 		bdepth = depth/8;
-		for( y1 = 0; y1 < LOGO_H; y1++ ) {
+		for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
 		    dst = fb + y1*line + x*bdepth;
 		    for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
 			val = (*src << redshift) |
@@ -2160,7 +2169,7 @@
 		unsigned int pix;
 		src = linux_logo16;
 		bdepth = (depth+7)/8;
-		for( y1 = 0; y1 < LOGO_H; y1++ ) {
+		for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
 		    dst = fb + y1*line + x*bdepth;
 		    for( x1 = 0; x1 < LOGO_W/2; x1++, src++ ) {
 			pix = (*src >> 4) | 0x10; /* upper nibble */
@@ -2208,7 +2217,7 @@
 	    blueshift  = p->var.blue.offset  - (8-p->var.blue.length);
 
 	    src = logo;
-	    for( y1 = 0; y1 < LOGO_H; y1++ ) {
+	    for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
 		dst = fb + y1*line + x*bdepth;
 		for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
 		    val = safe_shift((linux_logo_red[*src-32]   & redmask), redshift) |
@@ -2234,7 +2243,7 @@
 #if defined(CONFIG_FBCON_CFB4)
 	if (depth == 4 && p->type == FB_TYPE_PACKED_PIXELS) {
 		src = logo;
-		for( y1 = 0; y1 < LOGO_H; y1++) {
+		for( y1 = yoff; y1 < yoff + LOGO_H; y1++) {
 			dst = fb + y1*line + x/2;
 			for( x1 = 0; x1 < LOGO_W/2; x1++) {
 				u8 q = *src++;
@@ -2250,7 +2259,7 @@
 	    /* depth 8 or more, packed, with color registers */
 		
 	    src = logo;
-	    for( y1 = 0; y1 < LOGO_H; y1++ ) {
+	    for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
 		dst = fb + y1*line + x;
 		for( x1 = 0; x1 < LOGO_W; x1++ )
 		    fb_writeb (*src++, dst++);
@@ -2282,7 +2291,7 @@
 			 (1 << ((8-((pix*logo_depth)&7)-logo_depth) + bit)))
 		
 	    src = logo;
-	    for( y1 = 0; y1 < LOGO_H; y1++ ) {
+	    for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
 		for( x1 = 0; x1 < LOGO_LINE; x1++, src += logo_depth ) {
 		    dst = fb + y1*line + MAP_X(x/8+x1);
 		    for( bit = 0; bit < logo_depth; bit++ ) {
@@ -2301,7 +2310,7 @@
 	     * special case for logo_depth == 4: we used color registers 16..31,
 	     * so fill plane 4 with 1 bits instead of 0 */
 	    if (depth > logo_depth) {
-		for( y1 = 0; y1 < LOGO_H; y1++ ) {
+		for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
 		    for( x1 = 0; x1 < LOGO_LINE; x1++ ) {
 			dst = fb + y1*line + MAP_X(x/8+x1) + logo_depth*plane;
 			for( i = logo_depth; i < depth; i++, dst += plane )
@@ -2327,7 +2336,7 @@
 
 	    int is_hga = !strncmp(p->fb_info->modename, "HGA", 3);
 	    /* can't use simply memcpy because need to apply inverse */
-	    for( y1 = 0; y1 < LOGO_H; y1++ ) {
+	    for( y1 = yoff; y1 < yoff + LOGO_H; y1++ ) {
 		src = logo + y1*LOGO_LINE;
 		if (is_hga)
 		    dst = fb + (y1%4)*8192 + (y1>>2)*line + x/8;
@@ -2346,7 +2355,7 @@
 		outb_p(5,0x3ce); outb_p(0,0x3cf);
 
 		src = logo;
-		for (y1 = 0; y1 < LOGO_H; y1++) {
+		for (y1 = yoff; y1 < yoff + LOGO_H; y1++) {
 			for (x1 = 0; x1 < LOGO_W / 2; x1++) {
 				dst = fb + y1*line + x1/4 + x/8;
 
@@ -2370,6 +2379,12 @@
 		done = 1;
 	}
 #endif			
+        logo_count++;
+        x += LOGO_W + 8;
+        if (x >= p->var.xres - (LOGO_W + 8)) {
+            yoff += LOGO_H + 8;
+            x = 0;
+        }
     }
     
     if (p->fb_info->fbops->fb_rasterimg)

Re: [Linux-fbdev-devel] fbdev accel lib

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

On Mon, 2 Jul 2001, Jeff Garzik wrote:
> When implementing accels in kernel space, it would be nice to go ahead
> and shove those into a library for userland apps to use as well. 
> "fbdev-lib" or whatever.  Then, software such as gdk's fbdev backend or
> qt's fbdev backend or Mesa's fbdev target could link against this
> library, and automatically benefit from the code sharing (when new
> hardware accels are implemented, especially).

Good idea. But note that acceleration in kernel space will be limited to
rectfill, rectcopy and perhaps monochrome bitmap expansion for text drawing.
Of course these are the first things you want to accelerate in a userland
application too.

> It would also be nice to have other commonly-coded userland routines for
> accessing Linux kernel fbdev devices, if such exist.

You may want to take a look at fbtest (check out CVS at
http://www.sf.net/projects/linux-fbdev/). It doesn't do acceleration, since
that's chipset specific, but is supposed to handle whatever hardware you have
and find possible bugs in a fbdev implementation. I did my best to keep
everything as generic as possible. Speed is not the most important issue (but
it is important), correctness is.

It's built on a layered design:
  - Low-level drawing, for different video memory organizations (yes, you can
    get away with implementing [gs]etpixel only), using an opaque pixel value.
  - Visual handling, to map colors to an opaque pixel value.
  - Tests run on top of this.

So far I ran it on pseudocolor/directcolor devices only, in cfb{8,16,24,32}. I
have to run a test on my Amiga (planes) again.

To do:
  - Add support for cfb{2,4}
  - Add more optimized routines for various video memory organizations
  - Add ellipse drawing, so I can mimic the fancy calibration image I once
    saw in a magazine
  - Add lots of new tests :-)

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

[Linux-fbdev-devel] fbdev accel lib

[Jeff G. <jg...@ma...>]

I haven't been following the 2.5.x fbdev discussions, so I apologize if
this is out of line with the future.

When implementing accels in kernel space, it would be nice to go ahead
and shove those into a library for userland apps to use as well. 
"fbdev-lib" or whatever.  Then, software such as gdk's fbdev backend or
qt's fbdev backend or Mesa's fbdev target could link against this
library, and automatically benefit from the code sharing (when new
hardware accels are implemented, especially).

It would also be nice to have other commonly-coded userland routines for
accessing Linux kernel fbdev devices, if such exist.

This is NOT a suggestion for a new userland graphics interface or
anything of that sort.  What I propose is a --small-- library with
nothing but code that should be shared across low-level fbdev users.

Regards,

	Jeff


-- 
Jeff Garzik      | The LSB is a bunch of crap.
Building 1024    | E-mail for details.
MandrakeSoft     |

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

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

On Sun, Jul 01, 2001 at 07:27:39AM -0700, James Simmons wrote:
> 
> > but will you have access to the font drawing accels of fbdev, or should you do
> > it by hand ?
> 
> No. It is to slow that way. It is better if userland does it itself. Plus
> you have code to use inside the kernel.

But that would mean a 3rd serie of drivers, in a userland library that would
enable some kind of accel ofor userland fbdev apps.

Having 2 copies of the drivers 'fbdev + X) is bad enough, without needing to
maintain a 3rd version.

That is, unless we manage to re-use the X drivers in some way, or go with full
mesa/openGL ...

Friendly,

Sven Luther