Framebuffer fbtest issues

Framebuffer fbtest issues

[Hetz Ben Hamo]

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

Hi,

I took the fbtest from the CVS and compiled it. It seems it needs some 
updating ;)

in the fbtest/pnmtohex/Makefile - it won't compile, as the NetPBM library has 
been changed, so you'll need to install it and change the Makefile to 
something like:

LIBS += -lnetpbm

One weird issue - the netpbm package that comes with redhat doesn't compile 
the fbtest - any suggestions why? (same in mandrake) - only installing the 
netpbm from sourceforge seems to help (and modifying the Makefile)..

I'm also enclosing sort of README to save others the hair tearing I had here 
;)

Could someone please commit those changes to CVS?

Thanks,
Hetz

[-- Attachment #2: README --]
[-- Type: text/english, Size: 674 bytes --]

Framebuffer test "suite"
------------------------

This is a package which contains 10 tests to make sure your framebuffer works.

In order to compile it, you'll need NetPBM to be installed first 
(http://netpbm.sf.net) and make sure your libnetpbm.so files are correctly known
to the either your LD_LIBRARY_PATH or to your /etc/ld.so.conf (in Linux)

After compiling (a simple "make" should do the job), you can run the test by
runnning: ./fbtest

On some machines, running the fbtest might take a bit of pause and then the demos
will run, so you might want to launch the fbtest with: ./fbtest -d -v

Good Luck,
The framebuffer development team
(http://linux-fbdev.sf.net)

Re: Framebuffer fbtest issues

[John Zielinski]

Hetz Ben Hamo wrote:

>On some machines, running the fbtest might take a bit of pause and then the demos
>will run, so you might want to launch the fbtest with: ./fbtest -d -v
>  
>

I got that pause when running it as well.  Seems that the memcpy from 
video memory is what causes this.  Do you (or anyone else on the list) 
know why reading video memory takes so long?  I have a Radeon 9200 on an 
ASUS A7V133 motherboard.

I modified fbtest so that it doesn't bother saving or restoring if the 
console was in KD_TEXT as it will get restored by the console anyways.  
This go rid of the pause.  I'll post those patches once I test it with 
the normal VGA console.

John






-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Framebuffer fbtest issues

[Geert Uytterhoeven]

On Wed, 26 Nov 2003, John Zielinski wrote:
> Hetz Ben Hamo wrote:
> >On some machines, running the fbtest might take a bit of pause and then the demos
> >will run, so you might want to launch the fbtest with: ./fbtest -d -v
> 
> I got that pause when running it as well.  Seems that the memcpy from 
> video memory is what causes this.  Do you (or anyone else on the list) 
> know why reading video memory takes so long?  I have a Radeon 9200 on an 
> ASUS A7V133 motherboard.

How much memory does the Radeon 9200 have? Probably at least 64 MiB. Usually
reading from video memory across PCI/AGP is slow, that's why usually it's
faster for fbcon to scroll by redrawing all characters instead of copying video
data.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Framebuffer fbtest issues

[John Zielinski]

Geert Uytterhoeven wrote:

> How much memory does the Radeon 9200 have? Probably at least 64 MiB. 
> Usually
> reading from video memory across PCI/AGP is slow, that's why usually it's
> faster for fbcon to scroll by redrawing all characters instead of 
> copying video
> data.
>
>  
>
It has 128 MiB.  I didn't realize that reading video memory was that 
slow...

So it's a better idea to not save the frame buffer if it's in KD_TEXT 
mode and just have the fbcon redraw it.  I'll post  my patches to fbtest 
later so you can see what I'm talking about.

John





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/