linux-fbdev-users — Generic mailing list for users of frame buffers

Re: [Linux-fbdev-users] intelfb and 945GM

[Antonino A. D. <ad...@gm...>]

On Sat, 2007-03-17 at 22:06 +0000, Matteo Vescovi wrote:
> Hi,
> 

> 
> If there is anything else I can do to help diagnose the problem, please 
> let me know.video=intelfb:mode=1024x768-8@75
> 
> I would appreciate any help.
> 
> 

Use this boot line instead:
video=intelfb:mode=1024x768-8@75 vga=0x305


Tony

[Linux-fbdev-users] Linux FB driver for SED1335

[Joshua X. <jx...@wo...>]

Is there anybody working on the FB driver for SED1335? I would like to
join the development/testing if possible. I recently got an LCD with
build-in SED1335 controller and I would like to get it to work with my
TS-7250 ARM based SBC. Thank you.

=20

Joshua

=20

[Linux-fbdev-users] strange problems

[<so...@fm...>]

Hi,

I am developing a framebuffer driver (ARM Linux).  I have the some
doubts regarding the values to be filled in var and fix screeninfo.

static struct fb_fix_screeninfo sssfb_fix __initdata = {
	.id		= "sss",
	.smem_len	= 1024*1024,
	.type		= FB_TYPE_PACKED_PIXELS,
	.visual		= FB_VISUAL_TRUECOLOR,
	.line_length	= 1024*2,
	.accel		= FB_ACCEL_NONE,
};

static struct fb_var_screeninfo sssfb_var __initdata = {
	.xres		= 1024,
	.yres		= 512,
	.xres_virtual	= 1024,
	.yres_virtual	= 512,
	.bits_per_pixel	= 16,
    	.red		= {6, 5, 0},
	.green		= {11, 5, 0},
	.blue		= {0, 6, 0},
	.activate	= FB_ACTIVATE_NOW,
	.height		= 640,
	.width		= 480,
	.vmode		= FB_VMODE_NONINTERLACED,
};


Are the values correct?  I am getting the linux boot up screen (with the
penguin), but it appears in 3 columns (same output) - although i figured
that pixels of a line were distributed (offset?) in 3 columns in the
same line giving the output.

Please tell me whether the above values are correct and when does
setcolreg() function come into picture

Regards
Har
-- 
  
  so...@fm...

-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free

[Linux-fbdev-users] intelfb and 945GM

[Matteo V. <mat...@ya...>]

Hi,

I am having a bit of trouble getting the intelfb driver to work with my 
945GM graphics card.

I read the existing posts regarding intelfb and 945GM, and I confirm 
that I am having similar problems to those previosly reported.

A bit of information about my setup...

matt@burrow:~$ uname -a
Linux burrow 2.6.18 #8 SMP Sat Mar 17 20:05:52 GMT 2007 i686 GNU/Linux


matt@burrow:~$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 
945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 
945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML 
Express Integrated Graphics Controller (rev 03)
...


I compiled support for frame buffer devices and the intelfb driver into 
the kernel:
CONFIG_FB=y
CONFIG_FB_INTEL=y
CONFIG_FB_INTEL_DEBUG=y

I disabled the vesafb framebuffer driver to avoid any potential 
conflicts (if any are possible?) and left console support enabled:
# CONFIG_FB_VESA is not set
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_FRAMEBUFFER_CONSOLE=y


I changed the kernel statement in my grub menu.lst entry to use 
video=intelfb:mode=1024x768-8@75
I also tried video=intelfb:1024x768-8@75 with no luck.

<snip from dmesg output> Kernel command line: root=/dev/hda1 ro 
video=intelfb:mode=1024x768-8@75


The problem I have is that I cannot get the framebuffer working. The 
relevant output from dmesg says:
intelfb: intelfb_init
intelfb: Framebuffer driver for Intel(R) 
830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM chipsets
intelfb: Version 0.9.4
intelfb: intelfb_setup
intelfb: options: mode=1024x768-8@75
intelfb: intelfb_pci_register
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 169
intelfb: fb aperture: 0xc0000000/0x10000000, MMIO region: 0xdff00000/0x80000
intelfb: 00:02.0: Intel(R) 945GM, aperture size 256MB, stolen memory 7932kB
intelfb: fb: 0xc0000000(+ 0x0)/0x7bf000 (0xf8a00000)
intelfb: MMIO: 0xdff00000/0x80000 (0xfc200000)
intelfb: ring buffer: 0xc3001000/0x10000 (0xfba01000)
intelfb: HW cursor: 0x0/0x0 (0x00000000) (offset 0x0) (phys 0x0)
intelfb: options: vram = 4, accel = 1, hwcursor = 0, fixed = 0, noinit = 0
intelfb: options: mode = "1024x768-8@75"
intelfb: Non-CRT device is enabled ( LVDS port ).  Disabling mode switching.
intelfb: Video mode must be programmed at boot time.
intelfb: cleanup


I would very much like to get the framebuffer to work, as this machine 
(a Dell D420) comes with a12.1" display and I would like to make the 
most of it by enabling a higher resolution.

If there is anything else I can do to help diagnose the problem, please 
let me know.

I would appreciate any help.


Cheers,
- Matteo

Re: [Linux-fbdev-users] Screen capture - using Frame buffer from theapplication

[Jenkins, C. <Cli...@xe...>]

> Currently I need to capture the screen shot (print screen)  with my
> application.
> Is there any idea\code by which we can capture the screen from
> application by using the frame buffer ?
> =20
> Thanks,
> Narendra

You can do it with a shell command:

 cp /dev/fb0 screenshot.raw

[then maybe use ImageMagick to process the file screenshot.raw]

Or you can do it with your own program using open(), read()or mmap(),
close() on the frame buffer device.

Look at the frame buffer documentation in the kernel tree under the
Documentation directory, and use Google to find other material.

Clive

[Linux-fbdev-users] Screen capture - using Frame buffer from the application

[Babu, N. \(GE Healthcare\) <Nar...@ge...>]

Hi,
=20
I am new to frame buffer concept.
Currently I need to capture the screen shot (print screen)  with my
application.
Is there any idea\code by which we can capture the screen from
application by using the frame buffer ?
=20
Thanks,
Narendra

Re: [Linux-fbdev-users] atyfb - system hangs at bootup prior to enabling framebuffer console -- linux 2.6.18

[cga2000 <cg...@op...>]

On Sun, Feb 25, 2007 at 06:11:21AM EST, Ville Syrjälä wrote:
> On Sat, Feb 24, 2007 at 02:35:57PM -0500, cga2000 wrote:
> > On Sat, Feb 17, 2007 at 08:19:12AM EST, Ville Syrjälä wrote:
[..]
> > 
> > 1. I tried to apply the patch to the 2.6.18 kernel and but it failed.
> > 
> > 2. I took a look at the source and it looks like there was at least one
> >    intervening patch between 2.6.18 and 2.6.20. The .. par->mclk_per !=
> >    .. test appears to have been reversed: 
> > 
> >    '.. mclk_per == par->xclk_per) .. instead of '.. != par->xclk_per' 
> >                 ^                                   ^
> 
> The test has been reversed because in 2.6.18 the busy loop is in the 
> 'else' branch and in 2.6.20 it's in the 'if' branch.

This is why I assumed that there was an intervening patch (or patches)
between 2.6.18 and 2.6.20.  So I was not too happy about making the
change to the 2.6.18 source thinking that the changes brought about by
the intervening patch(es) might be needed for your new patch to work
correctly.

> > 3. I downloaded kernels 2.6.20 and 2.6.20.1 but patching failed on both
> >    hunks.
> 
> IIRC I made the patch against 2.6.20 so it shouldn't have failed. Maybe 
> your mail program corrupted the patch.

Oh, that it did .. but it was not so much mutt that broke the patch ..
more of a problem with our respective email encodings.  

But what I guessed regarding what "patch" was complaining about .. it
looked more like a problem with the line numbers -- the code is there
all right but the line numbers don't match.

But that's OK, since I have little HD space to spare and I don't plan
on maintaining a patched source tree alongside with the original.

> > 4. On the other hand, with these new versions, I was able to locate the
> >    code in mach64_ct.c and manually made the changes.
> >    
> > 5. With your changes applied I rebooted at least a half a dozen times
> >    and I never again experienced the hang.
> > 
> > 6. I obviously have not run the modified code for any length of time but
> >    as far as I can tell the changes do not seem to cause any adverse
> >    side-effects.
> 
> There should be no side effects as this code is only executed when the 
> driver is initialized.

A convincing argument.  I kinda suspected that, but then for all I knew,
it might set up things differently .. in ways that might resurface at a
later point in time.

> > So, as far as I am concerned, your patch fixes the problem.
> 
> Good. So that makes it three verified cases of fixing the bug.

Glad I could help.  

Being able to run the framebuffer console at my display's native
resolution made a world of difference and giving your patch a go was
the least I could do.

:-)

> > Now, since I have run into unrelated problems with the newer 2.6.20
> > kernels I would much rather stick with 2.6.18 for now.
> > 
> > Are you aware of any intervening patches to mach64_ct.c that I could
> > apply so as to bring the 2.6.18 code up to the more current level and
> > then make your recommended changes, or is there more to it than just
> > patching this particular program?
> 
> The changes to mach64_ct.c were due to my patch that fixed resume from 
> suspend-to-ram. There were also other patches applied at the same time 
> but none were critical in any sense. You can stick with 2.6.18 + the 
> mdelay() fix.

2.6.20 has some major problems with my pcmcia CD burner and I really do
not have the time to report/research them at this point.  And w/o the
CD burner I cannot back up my system.

So this is really excellent news.

Thank you very much for your help.

Thanks,
cga

Re: [Linux-fbdev-users] atyfb - system hangs at bootup prior to enabling framebuffer console -- linux 2.6.18

[Ville <sy...@sc...>]

On Tue, Feb 20, 2007 at 02:43:53AM -0500, cga2000 wrote:
> 
> Regarding atyfb, I did have the time to notice two rather disturbing
> things, though.
> 
> First of all since I was wasting a lot of time rebooting into my sarge
> system or my fully-fledged, non-streamlined custom 2.6 kernel to bypass
> the hang that the patch will address (*) ..  I eventually figured I
> should try to change the video=atyfb:1400x1050 to a vga= specification
> on the fly by editing the grub "kernel" statement and much to my suprise
> and though I got both the atyfb and then the vesafb messages on the
> console it appears that atyfb "won" so to speak:  although I had
> specified vga=791 I was clearly switched to the 1400x1050 mode (rather
> than 1024x768).

I always disable vesafb from my kernels. I don't trust it to play nice 
with hw specific fbdev drivers. I think if you want to force vesafb you 
need pass video=vesafb to the kernel.

> Then, since the "debian way" of installing new kernels automatically
> updates your /boot/grub/menu.lst .. you have to remember to go and edit
> it and add the "video=atyfb:1400x1050" manually every time you install a
> new kernel.  Now the weird thing is that at one point I accidentally
> added the "atyfb" bit to the "title" statement instead of the "kernel"
> statement.  And yet atyfb guessed my "intentions" and automagically
> switched me to 1400x1050. 
> 
> So basically in both cases I was either telling the kernel/atyfb two
> different things or not telling it anything at all and yet it appears to
> have detected the native resolution of my display and enabled the
> 1400x1050 mode automatically.
> 
> Am I correct in assuming the above .. I mean .. is this how it works ..
> Is this new with the current kernels & new versions of atyfb?

Yes, atyfb will automatically use the panel's native resolution.

-- 
Ville Syrjälä
sy...@sc...
http://www.sci.fi/~syrjala/

Re: [Linux-fbdev-users] atyfb - system hangs at bootup prior to enabling framebuffer console -- linux 2.6.18

[Ville <sy...@sc...>]

On Sat, Feb 24, 2007 at 02:35:57PM -0500, cga2000 wrote:
> On Sat, Feb 17, 2007 at 08:19:12AM EST, Ville Syrjälä wrote:
> > On Fri, Feb 16, 2007 at 06:37:31PM -0500, cga2000 wrote:
> > > More than 50% of the time my laptop hangs when booting with 
> > > 
> > > ... video=atyfb:1400x1050.
> > > 
> > > I have seen similar occurrences reported here and there with recent 2.6
> > > kernels but nothing very clear as to whether this is a known problem or
> > > whether a patch or workaround has already been provided.
> > 
> > I was just able to reproduce the problem by switching from drivers/ide 
> > to libata. In my case the laptop would hang on every boot. Apparently 
> > using libata changed the timing enough to trigger the bug.
> > 
> > Try this patch:
> > 
> > ---
> >  drivers/video/aty/mach64_ct.c |    9 +++------
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> > 
> > Index: linux-2.6.20/drivers/video/aty/mach64_ct.c
> > ===================================================================
> > --- linux-2.6.20.orig/drivers/video/aty/mach64_ct.c
> > +++ linux-2.6.20/drivers/video/aty/mach64_ct.c
> > @@ -598,7 +598,6 @@ static void aty_resume_pll_ct(const stru
> >  	struct atyfb_par *par = info->par;
> >  
> >  	if (par->mclk_per != par->xclk_per) {
> > -		int i;
> >  		/*
> >  		* This disables the sclk, crashes the computer as reported:
> >  		* aty_st_pll_ct(SPLL_CNTL2, 3, info);
> > @@ -609,12 +608,10 @@ static void aty_resume_pll_ct(const stru
> >  		aty_st_pll_ct(SCLK_FB_DIV, pll->ct.sclk_fb_div, par);
> >  		aty_st_pll_ct(SPLL_CNTL2, pll->ct.spll_cntl2, par);
> >  		/*
> > -		 * The sclk has been started. However, I believe the first clock
> > -		 * ticks it generates are not very stable. Hope this primitive loop
> > -		 * helps for Rage Mobilities that sometimes crash when
> > -		 * we switch to sclk. (Daniel Mantione, 13-05-2003)
> > +		 * The sclk has been started. Wait for the PLL to lock. 5 ms
> > +		 * should be enough according to mach64 programmers guide.
> >  		 */
> > -		for (i=0;i<=0x1ffff;i++);
> > +		mdelay(5);
> >  	}
> >  
> >  	aty_st_pll_ct(PLL_REF_DIV, pll->ct.pll_ref_div, par);
> 
> I managed to make some progress on this issue.
> 
> 1. I tried to apply the patch to the 2.6.18 kernel and but it failed.
> 
> 2. I took a look at the source and it looks like there was at least one
>    intervening patch between 2.6.18 and 2.6.20. The .. par->mclk_per !=
>    .. test appears to have been reversed: 
> 
>    '.. mclk_per == par->xclk_per) .. instead of '.. != par->xclk_per' 
>                 ^                                   ^

The test has been reversed because in 2.6.18 the busy loop is in the 
'else' branch and in 2.6.20 it's in the 'if' branch.

> 3. I downloaded kernels 2.6.20 and 2.6.20.1 but patching failed on both
>    hunks.

IIRC I made the patch against 2.6.20 so it shouldn't have failed. Maybe 
your mail program corrupted the patch.

> 4. On the other hand, with these new versions, I was able to locate the
>    code in mach64_ct.c and manually made the changes.
>    
> 5. With your changes applied I rebooted at least a half a dozen times
>    and I never again experienced the hang.
> 
> 6. I obviously have not run the modified code for any length of time but
>    as far as I can tell the changes do not seem to cause any adverse
>    side-effects.

There should be no side effects as this code is only executed when the 
driver is initialized.

> So, as far as I am concerned, your patch fixes the problem.

Good. So that makes it three verified cases of fixing the bug.

> Now, since I have run into unrelated problems with the newer 2.6.20
> kernels I would much rather stick with 2.6.18 for now.
> 
> Are you aware of any intervening patches to mach64_ct.c that I could
> apply so as to bring the 2.6.18 code up to the more current level and
> then make your recommended changes, or is there more to it than just
> patching this particular program?

The changes to mach64_ct.c were due to my patch that fixed resume from 
suspend-to-ram. There were also other patches applied at the same time 
but none were critical in any sense. You can stick with 2.6.18 + the 
mdelay() fix.

-- 
Ville Syrjälä
sy...@sc...
http://www.sci.fi/~syrjala/

Re: [Linux-fbdev-users] atyfb - system hangs at bootup prior to enabling framebuffer console -- linux 2.6.18

[cga2000 <cg...@op...>]

On Sat, Feb 17, 2007 at 08:19:12AM EST, Ville Syrjälä wrote:
> On Fri, Feb 16, 2007 at 06:37:31PM -0500, cga2000 wrote:
> > More than 50% of the time my laptop hangs when booting with 
> > 
> > ... video=atyfb:1400x1050.
> > 
> > I have seen similar occurrences reported here and there with recent 2.6
> > kernels but nothing very clear as to whether this is a known problem or
> > whether a patch or workaround has already been provided.
> 
> I was just able to reproduce the problem by switching from drivers/ide 
> to libata. In my case the laptop would hang on every boot. Apparently 
> using libata changed the timing enough to trigger the bug.
> 
> Try this patch:
> 
> ---
>  drivers/video/aty/mach64_ct.c |    9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> Index: linux-2.6.20/drivers/video/aty/mach64_ct.c
> ===================================================================
> --- linux-2.6.20.orig/drivers/video/aty/mach64_ct.c
> +++ linux-2.6.20/drivers/video/aty/mach64_ct.c
> @@ -598,7 +598,6 @@ static void aty_resume_pll_ct(const stru
>  	struct atyfb_par *par = info->par;
>  
>  	if (par->mclk_per != par->xclk_per) {
> -		int i;
>  		/*
>  		* This disables the sclk, crashes the computer as reported:
>  		* aty_st_pll_ct(SPLL_CNTL2, 3, info);
> @@ -609,12 +608,10 @@ static void aty_resume_pll_ct(const stru
>  		aty_st_pll_ct(SCLK_FB_DIV, pll->ct.sclk_fb_div, par);
>  		aty_st_pll_ct(SPLL_CNTL2, pll->ct.spll_cntl2, par);
>  		/*
> -		 * The sclk has been started. However, I believe the first clock
> -		 * ticks it generates are not very stable. Hope this primitive loop
> -		 * helps for Rage Mobilities that sometimes crash when
> -		 * we switch to sclk. (Daniel Mantione, 13-05-2003)
> +		 * The sclk has been started. Wait for the PLL to lock. 5 ms
> +		 * should be enough according to mach64 programmers guide.
>  		 */
> -		for (i=0;i<=0x1ffff;i++);
> +		mdelay(5);
>  	}
>  
>  	aty_st_pll_ct(PLL_REF_DIV, pll->ct.pll_ref_div, par);

I managed to make some progress on this issue.

1. I tried to apply the patch to the 2.6.18 kernel and but it failed.

2. I took a look at the source and it looks like there was at least one
   intervening patch between 2.6.18 and 2.6.20. The .. par->mclk_per !=
   .. test appears to have been reversed: 

   '.. mclk_per == par->xclk_per) .. instead of '.. != par->xclk_per' 
                ^                                   ^

3. I downloaded kernels 2.6.20 and 2.6.20.1 but patching failed on both
   hunks.

4. On the other hand, with these new versions, I was able to locate the
   code in mach64_ct.c and manually made the changes.
   
5. With your changes applied I rebooted at least a half a dozen times
   and I never again experienced the hang.

6. I obviously have not run the modified code for any length of time but
   as far as I can tell the changes do not seem to cause any adverse
   side-effects.

So, as far as I am concerned, your patch fixes the problem.

Now, since I have run into unrelated problems with the newer 2.6.20
kernels I would much rather stick with 2.6.18 for now.

Are you aware of any intervening patches to mach64_ct.c that I could
apply so as to bring the 2.6.18 code up to the more current level and
then make your recommended changes, or is there more to it than just
patching this particular program?

I will take a look at the change logs but since I am not a professional
kernel maintainainer by a long way, I would greatly appreciate if you
could advise on the best course of action.

Thank you very much indeed for your help.

cga

Re: [Linux-fbdev-users] Question about cfb_copyarea

[Antonino A. D. <ad...@gm...>]

On Thu, 2007-02-22 at 12:43 +0100, Juergen Beisert wrote:
> On Thursday 22 February 2007 11:45, Antonino A. Daplas wrote:
> > > > The global 'logo_shown' is only used at the very start, to display the
> > > > boot logo if it is equal to LOGO_DRAW. It basically forces the scroll
> > > > mode to redraw and gives space in the upper part of your screen. After
> > > > that 'logo_shown' is assigned the index of the foreground console
> > > > (usually 0) and your scroll settings are now used.
> > >
> > > No, 0 is a valid index and always used in console 0. So my scroll
> > > settings in console 0 are never used.
> >
> > No, scroll_redraw is used if logo_shown = LOGO_DRAW.  After a switch, it
> > changes to logo_shown = fg_console = 0,  and this time your scroll
> > settings will be used.
> 
> So logo_shown will be set always to 0 for console 0, even if the logo is 
> disabled? What do you mean with "switch"? Switch to another console? Or 
> something else?
> 
> Maybe I missunderstand. In fbcon_scroll() I found:
> [...]
> 	if (logo_shown >= 0)
> 		goto redraw_up;

Yep, kinda weird how it goes. First, logo_shown = SHOW_LOGO. This adds
space at the top and the logo is drawn. Then logo_shown = fg_console,
which forces scroll mode to redraw.  Finally it becomes logo_shown =
DONTSHOW in fbcon_switch(), and the space above disappears and the
drivers scroll settings kick in.

Tony

Re: [Linux-fbdev-users] Question about cfb_copyarea

[Juergen B. <jue...@kr...>]

On Thursday 22 February 2007 11:45, Antonino A. Daplas wrote:
> > > The global 'logo_shown' is only used at the very start, to display the
> > > boot logo if it is equal to LOGO_DRAW. It basically forces the scroll
> > > mode to redraw and gives space in the upper part of your screen. After
> > > that 'logo_shown' is assigned the index of the foreground console
> > > (usually 0) and your scroll settings are now used.
> >
> > No, 0 is a valid index and always used in console 0. So my scroll
> > settings in console 0 are never used.
>
> No, scroll_redraw is used if logo_shown = LOGO_DRAW.  After a switch, it
> changes to logo_shown = fg_console = 0,  and this time your scroll
> settings will be used.

So logo_shown will be set always to 0 for console 0, even if the logo is 
disabled? What do you mean with "switch"? Switch to another console? Or 
something else?

Maybe I missunderstand. In fbcon_scroll() I found:
[...]
	if (logo_shown >= 0)
		goto redraw_up;
[...]
But FBCON_LOGO_* are defined to values below 0. And with logo_shown=0 always 
the mode SCROLL_REDRAW is used. I'm confused.

> > > As to why your driver freezes, I don't know.  Check if it also crashes
> > > with cfbcopyarea first.
> >
> > I tried it with cfbcopyarea, because my hardware routine isn't finished
> > yet. But all I tried, cfbcopyarea will never be called. It always ends up
> > in ops->bmove() and crashes...
>
> ops->bmove is basically a wrapper to copyarea, so it does get used. I
> don't know why it would freeze though.  Perhaps you can pinpoint where
> exactly in bmove it crashes.

I will try it.

Juergen

Re: [Linux-fbdev-users] Question about cfb_copyarea

[Antonino A. D. <ad...@gm...>]

On Thu, 2007-02-22 at 11:19 +0100, Juergen Beisert wrote:
> On Thursday 22 February 2007 00:43, Antonino A. Daplas wrote:
> > On Sat, 2007-02-10 at 15:32 +0100, Juergen Beisert wrote:
> > > Hi Petr,
> > >
> > > On Wednesday 31 January 2007 10:12, Petr Vandrovec wrote:
> > > > Take a look at updatescrollmode() in fbcon.c - you must persuade this
> > > > function to use SCROLL_*_MOVE, not SCROLL_*_REDRAW.  FBINFO_READS_FAST
> > > > should be sufficient - or you can report fast bitblt + fast panning, or
> > > > fast bitblt + slow imageblit.  If you report no panning + fast bitblt +
> > > > fast imageblit, redraw is used :-(
> > >
> > > I tried around to get fbcon to use SCROLL_MOVE. These are my current
> > > settings:
> > >
> > > info->flags	= FBINFO_DEFAULT |
> > > 		  FBINFO_HWACCEL_COPYAREA |
> > > 		  FBINFO_HWACCEL_FILLRECT |
> > > 		  FBINFO_HWACCEL_IMAGEBLIT |
> > > 		  FBINFO_READS_FAST;
> > > With this settings updatescrollmode() decides to use SCROLL_MOVE.
> > >
> > > Two things are coming up with this scroll mode (all in fbcon_scroll() ):
> > >
> > >  1) why is the variable "logo_shown" always set to 0 for console 0? When
> > > in console 0 it always ends up in "goto redraw_up;" But I have no logo on
> > > my console? For other consoles than 0 "logo_shown" is -1
> > >     (=FBCON_LOGO_CANSHOW)
> > >  2) with the settings above active on another console then 0, the whole
> > > system freezes immediately in ops->bmove() or ops->clear()????
> > >  2a) when I comment out the "logo_shown" check in fbcon_scroll() it also
> > >      freezes the whole system in console 0.
> > >
> > > Any ideas?
> >
> > The global 'logo_shown' is only used at the very start, to display the
> > boot logo if it is equal to LOGO_DRAW. It basically forces the scroll
> > mode to redraw and gives space in the upper part of your screen. After
> > that 'logo_shown' is assigned the index of the foreground console
> > (usually 0) and your scroll settings are now used.
> 
> No, 0 is a valid index and always used in console 0. So my scroll settings in 
> console 0 are never used.

No, scroll_redraw is used if logo_shown = LOGO_DRAW.  After a switch, it
changes to logo_shown = fg_console = 0,  and this time your scroll
settings will be used.

> 
> > Basically, don't touch the 'logo_shown' variable.  If you don't want the
> > tux logo, then disable it in your kernel config.
> 
> Its already disabled. I didn't use the logo in my tests.
> 

Okay.

> > As to why your driver freezes, I don't know.  Check if it also crashes
> > with cfbcopyarea first.
> 
> I tried it with cfbcopyarea, because my hardware routine isn't finished yet. 
> But all I tried, cfbcopyarea will never be called. It always ends up in 
> ops->bmove() and crashes...
> 

ops->bmove is basically a wrapper to copyarea, so it does get used. I
don't know why it would freeze though.  Perhaps you can pinpoint where
exactly in bmove it crashes.

Tony

Re: [Linux-fbdev-users] Question about cfb_copyarea

[Juergen B. <jue...@kr...>]

On Thursday 22 February 2007 00:43, Antonino A. Daplas wrote:
> On Sat, 2007-02-10 at 15:32 +0100, Juergen Beisert wrote:
> > Hi Petr,
> >
> > On Wednesday 31 January 2007 10:12, Petr Vandrovec wrote:
> > > Take a look at updatescrollmode() in fbcon.c - you must persuade this
> > > function to use SCROLL_*_MOVE, not SCROLL_*_REDRAW.  FBINFO_READS_FAST
> > > should be sufficient - or you can report fast bitblt + fast panning, or
> > > fast bitblt + slow imageblit.  If you report no panning + fast bitblt +
> > > fast imageblit, redraw is used :-(
> >
> > I tried around to get fbcon to use SCROLL_MOVE. These are my current
> > settings:
> >
> > info->flags	= FBINFO_DEFAULT |
> > 		  FBINFO_HWACCEL_COPYAREA |
> > 		  FBINFO_HWACCEL_FILLRECT |
> > 		  FBINFO_HWACCEL_IMAGEBLIT |
> > 		  FBINFO_READS_FAST;
> > With this settings updatescrollmode() decides to use SCROLL_MOVE.
> >
> > Two things are coming up with this scroll mode (all in fbcon_scroll() ):
> >
> >  1) why is the variable "logo_shown" always set to 0 for console 0? When
> > in console 0 it always ends up in "goto redraw_up;" But I have no logo on
> > my console? For other consoles than 0 "logo_shown" is -1
> >     (=FBCON_LOGO_CANSHOW)
> >  2) with the settings above active on another console then 0, the whole
> > system freezes immediately in ops->bmove() or ops->clear()????
> >  2a) when I comment out the "logo_shown" check in fbcon_scroll() it also
> >      freezes the whole system in console 0.
> >
> > Any ideas?
>
> The global 'logo_shown' is only used at the very start, to display the
> boot logo if it is equal to LOGO_DRAW. It basically forces the scroll
> mode to redraw and gives space in the upper part of your screen. After
> that 'logo_shown' is assigned the index of the foreground console
> (usually 0) and your scroll settings are now used.

No, 0 is a valid index and always used in console 0. So my scroll settings in 
console 0 are never used.

> Basically, don't touch the 'logo_shown' variable.  If you don't want the
> tux logo, then disable it in your kernel config.

Its already disabled. I didn't use the logo in my tests.

> As to why your driver freezes, I don't know.  Check if it also crashes
> with cfbcopyarea first.

I tried it with cfbcopyarea, because my hardware routine isn't finished yet. 
But all I tried, cfbcopyarea will never be called. It always ends up in 
ops->bmove() and crashes...

Juergen

Re: [Linux-fbdev-users] Question about cfb_copyarea

[Antonino A. D. <ad...@gm...>]

On Sat, 2007-02-10 at 15:32 +0100, Juergen Beisert wrote: 
> Hi Petr,
> 
> On Wednesday 31 January 2007 10:12, Petr Vandrovec wrote:
> > Take a look at updatescrollmode() in fbcon.c - you must persuade this
> > function to use SCROLL_*_MOVE, not SCROLL_*_REDRAW.  FBINFO_READS_FAST
> > should be sufficient - or you can report fast bitblt + fast panning, or
> > fast bitblt + slow imageblit.  If you report no panning + fast bitblt +
> > fast imageblit, redraw is used :-(
> 
> I tried around to get fbcon to use SCROLL_MOVE. These are my current settings:
> 
> info->flags	= FBINFO_DEFAULT |
> 		  FBINFO_HWACCEL_COPYAREA |
> 		  FBINFO_HWACCEL_FILLRECT |
> 		  FBINFO_HWACCEL_IMAGEBLIT |
> 		  FBINFO_READS_FAST;
> With this settings updatescrollmode() decides to use SCROLL_MOVE.
> 
> Two things are coming up with this scroll mode (all in fbcon_scroll() ):
> 
>  1) why is the variable "logo_shown" always set to 0 for console 0? When in
>     console 0 it always ends up in "goto redraw_up;" But I have no logo on my
>     console? For other consoles than 0 "logo_shown" is -1
>     (=FBCON_LOGO_CANSHOW)
>  2) with the settings above active on another console then 0, the whole system
>     freezes immediately in ops->bmove() or ops->clear()????
>  2a) when I comment out the "logo_shown" check in fbcon_scroll() it also
>      freezes the whole system in console 0.
> 
> Any ideas?
> 

The global 'logo_shown' is only used at the very start, to display the
boot logo if it is equal to LOGO_DRAW. It basically forces the scroll
mode to redraw and gives space in the upper part of your screen. After
that 'logo_shown' is assigned the index of the foreground console
(usually 0) and your scroll settings are now used.

Basically, don't touch the 'logo_shown' variable.  If you don't want the
tux logo, then disable it in your kernel config.

As to why your driver freezes, I don't know.  Check if it also crashes
with cfbcopyarea first.

Tony

Re: [Linux-fbdev-users] atyfb - system hangs at bootup prior to enabling framebuffer console -- linux 2.6.18

[cga2000 <cg...@op...>]

On Sat, Feb 17, 2007 at 12:14:25PM EST, cga2000 wrote:
> On Sat, Feb 17, 2007 at 08:19:12AM EST, Ville Syrjälä wrote:
> > On Fri, Feb 16, 2007 at 06:37:31PM -0500, cga2000 wrote:
> > > More than 50% of the time my laptop hangs when booting with 
> > > 
> > > ... video=atyfb:1400x1050.
> > > 
> > > I have seen similar occurrences reported here and there with recent 2.6
> > > kernels but nothing very clear as to whether this is a known problem or
> > > whether a patch or workaround has already been provided.
> > 
> > I was just able to reproduce the problem by switching from drivers/ide 
> > to libata. In my case the laptop would hang on every boot. Apparently 
> > using libata changed the timing enough to trigger the bug.
> > 
> > Try this patch:
> > 
> > ---
> >  drivers/video/aty/mach64_ct.c |    9 +++------
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> > 
> > Index: linux-2.6.20/drivers/video/aty/mach64_ct.c
> > ===================================================================
> > --- linux-2.6.20.orig/drivers/video/aty/mach64_ct.c
> > +++ linux-2.6.20/drivers/video/aty/mach64_ct.c
> > @@ -598,7 +598,6 @@ static void aty_resume_pll_ct(const stru
> >  	struct atyfb_par *par = info->par;
> >  
> >  	if (par->mclk_per != par->xclk_per) {
> > -		int i;
> >  		/*
> >  		* This disables the sclk, crashes the computer as reported:
> >  		* aty_st_pll_ct(SPLL_CNTL2, 3, info);
> > @@ -609,12 +608,10 @@ static void aty_resume_pll_ct(const stru
> >  		aty_st_pll_ct(SCLK_FB_DIV, pll->ct.sclk_fb_div, par);
> >  		aty_st_pll_ct(SPLL_CNTL2, pll->ct.spll_cntl2, par);
> >  		/*
> > -		 * The sclk has been started. However, I believe the first clock
> > -		 * ticks it generates are not very stable. Hope this primitive loop
> > -		 * helps for Rage Mobilities that sometimes crash when
> > -		 * we switch to sclk. (Daniel Mantione, 13-05-2003)
> > +		 * The sclk has been started. Wait for the PLL to lock. 5 ms
> > +		 * should be enough according to mach64 programmers guide.
> >  		 */
> > -		for (i=0;i<=0x1ffff;i++);
> > +		mdelay(5);
> >  	}
> >  
> >  	aty_st_pll_ct(PLL_REF_DIV, pll->ct.pll_ref_div, par);
> 
> Thanks.
> 
> I was planning on streamlining my new 2.6.18 kernel over the weekend so
> I should be able to report back to you by Monday.

Well I did succeed in streamlining my kernel+modules .. reducing the
size of the /usr/src/ tree from 600 Meg to about 275 .. but then it took
me two days and a night to get it to boot.  I think the problem was
partly something that I inadvertently excluded or compiled as a module
in menuconfig .. with so many options that I modified it's easy to hit
the space bar one too many times ..  and then I think I was mostly
getting confused by the "debian way" of compiling and installing new
kernels.  

In any event, it's now 2:30 in the morning .. I have a kernel that takes
about 45 minutes to compile instead of four hours and doesn't panic ..
but I haven't found the time yet to apply your patch.  The worst of it
is that I probably won't have another window of opportunity to work on
this for another two weeks or so.

It also looks like I may have to modify the patch for the 2.6.18 kernel.
I wouldn't mind giving 2.6.20 a shot but then some of the complementary
debian packages such as initrd-tools might not be in sync with the newer
version.

Regarding atyfb, I did have the time to notice two rather disturbing
things, though.

First of all since I was wasting a lot of time rebooting into my sarge
system or my fully-fledged, non-streamlined custom 2.6 kernel to bypass
the hang that the patch will address (*) ..  I eventually figured I
should try to change the video=atyfb:1400x1050 to a vga= specification
on the fly by editing the grub "kernel" statement and much to my suprise
and though I got both the atyfb and then the vesafb messages on the
console it appears that atyfb "won" so to speak:  although I had
specified vga=791 I was clearly switched to the 1400x1050 mode (rather
than 1024x768).

Then, since the "debian way" of installing new kernels automatically
updates your /boot/grub/menu.lst .. you have to remember to go and edit
it and add the "video=atyfb:1400x1050" manually every time you install a
new kernel.  Now the weird thing is that at one point I accidentally
added the "atyfb" bit to the "title" statement instead of the "kernel"
statement.  And yet atyfb guessed my "intentions" and automagically
switched me to 1400x1050. 

So basically in both cases I was either telling the kernel/atyfb two
different things or not telling it anything at all and yet it appears to
have detected the native resolution of my display and enabled the
1400x1050 mode automatically.

Am I correct in assuming the above .. I mean .. is this how it works ..
Is this new with the current kernels & new versions of atyfb?

Thanks,
cga

(*) I boot a 2.6.18 kernel and reproduce the hang .. then say, I boot it
again .. I hang again as you would expect .. So, naturally I would then
boot the 2.4.27 kernel ..  and then reboot the 2.6.18 kernel .. and this
time atyfb smoothly switches to the fb console as if nothing had
happened.  In my case (fortunately ..) it seems to be systematic. No
idea whether this may be of interest or not. 

Re: [Linux-fbdev-users] Monitor display not working in console, works in X

[Kevin N. <bea...@ya...>]

To answer my own question.  I went to install debian over yellowdog, and it=
 suggested typing install video=3Dofonly.  That seems to be the fix.  So I =
can either add video=3Dofonly to yaboot.conf file or just install debian, w=
hich is probably a better distro anyways.=0AKevin=0A=0A=0A----- Original Me=
ssage ----=0AFrom: Kevin Nowaczyk <bea...@ya...>=0ATo: linux-fbdev=
-u...@li...=0ASent: Monday, February 12, 2007 12:43:51 PM=
=0ASubject: Monitor display not working in console, works in X=0A=0A=0AI ha=
ve a revB i-mac on which I installed Yellow Dog 4.0. The install went fine.=
 I decided to run the i-mac as a linux appliance so I did not need the moni=
tor. I already have a spare monitor sitting around for other servers so I s=
oldered together a 15pin macintosh video to VGA converter cable to use. Aft=
er plugging in the monitor, it displayed fine during the BIOS start-up, and=
 through the bootloader. and even the beginning of the kernel load.  Howeve=
r, once tux appeared in the top left corner of the screen, the monitor disp=
layed 4 columns, with succesive rows in successive columns.=0A=0AI played a=
round with the XF86Config and was able to get X windows displaying perfectl=
y with the following stanza: =0A=0ASection "Monitor" =0A=0A#       DisplayS=
ize  270        200 =0A#       HorizSync    60.0 - 60.0 =0A#       VertRefr=
esh  75.0 - 117.0 =0A        Identifier   "Monitor0" =0A        ModelName  =
  "Acer" =0A        HorizSync    28.0 - 50.0 =0A        VertRefresh  56.0 -=
 76.0 =0A        Option      "DPMS" =0AEndSection=0A=0Anow the only thing t=
hat does not display correctly is the console. Does anyone know where the f=
ile is, or what must be done to tell the kernel or framebuffer how to inter=
act with the monitor in the way that X uses the XF86Config file?  I've post=
ed this question to several message board with no response and can't find a=
nything on the web, so I'm going to the framebuffer experts now.=0A=0AThank=
s, =0AKevin Nowaczyk=0A=0A=0A=0A___________________________________________=
_________________________________________=0AHave a burning question?  =0AGo=
 to www.Answers.yahoo.com and get answers from real people who know.=0A=0A=
=0A =0A____________________________________________________________________=
________________=0ANever miss an email again!=0AYahoo! Toolbar alerts you t=
he instant new Mail arrives.=0Ahttp://tools.search.yahoo.com/toolbar/featur=
es/mail/

Re: [Linux-fbdev-users] atyfb - system hangs at bootup prior to enabling framebuffer console -- linux 2.6.18

[cga2000 <cg...@op...>]

On Sat, Feb 17, 2007 at 08:19:12AM EST, Ville Syrjälä wrote:
> On Fri, Feb 16, 2007 at 06:37:31PM -0500, cga2000 wrote:
> > More than 50% of the time my laptop hangs when booting with 
> > 
> > ... video=atyfb:1400x1050.
> > 
> > I have seen similar occurrences reported here and there with recent 2.6
> > kernels but nothing very clear as to whether this is a known problem or
> > whether a patch or workaround has already been provided.
> 
> I was just able to reproduce the problem by switching from drivers/ide 
> to libata. In my case the laptop would hang on every boot. Apparently 
> using libata changed the timing enough to trigger the bug.
> 
> Try this patch:
> 
> ---
>  drivers/video/aty/mach64_ct.c |    9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> Index: linux-2.6.20/drivers/video/aty/mach64_ct.c
> ===================================================================
> --- linux-2.6.20.orig/drivers/video/aty/mach64_ct.c
> +++ linux-2.6.20/drivers/video/aty/mach64_ct.c
> @@ -598,7 +598,6 @@ static void aty_resume_pll_ct(const stru
>  	struct atyfb_par *par = info->par;
>  
>  	if (par->mclk_per != par->xclk_per) {
> -		int i;
>  		/*
>  		* This disables the sclk, crashes the computer as reported:
>  		* aty_st_pll_ct(SPLL_CNTL2, 3, info);
> @@ -609,12 +608,10 @@ static void aty_resume_pll_ct(const stru
>  		aty_st_pll_ct(SCLK_FB_DIV, pll->ct.sclk_fb_div, par);
>  		aty_st_pll_ct(SPLL_CNTL2, pll->ct.spll_cntl2, par);
>  		/*
> -		 * The sclk has been started. However, I believe the first clock
> -		 * ticks it generates are not very stable. Hope this primitive loop
> -		 * helps for Rage Mobilities that sometimes crash when
> -		 * we switch to sclk. (Daniel Mantione, 13-05-2003)
> +		 * The sclk has been started. Wait for the PLL to lock. 5 ms
> +		 * should be enough according to mach64 programmers guide.
>  		 */
> -		for (i=0;i<=0x1ffff;i++);
> +		mdelay(5);
>  	}
>  
>  	aty_st_pll_ct(PLL_REF_DIV, pll->ct.pll_ref_div, par);

Thanks.

I was planning on streamlining my new 2.6.18 kernel over the weekend so
I should be able to report back to you by Monday.

cga.

Re: [Linux-fbdev-users] atyfb - system hangs at bootup prior to enabling framebuffer console -- linux 2.6.18

[Ville <sy...@sc...>]

On Fri, Feb 16, 2007 at 06:37:31PM -0500, cga2000 wrote:
> More than 50% of the time my laptop hangs when booting with 
> 
> ... video=atyfb:1400x1050.
> 
> I have seen similar occurrences reported here and there with recent 2.6
> kernels but nothing very clear as to whether this is a known problem or
> whether a patch or workaround has already been provided.

I was just able to reproduce the problem by switching from drivers/ide 
to libata. In my case the laptop would hang on every boot. Apparently 
using libata changed the timing enough to trigger the bug.

Try this patch:

---
 drivers/video/aty/mach64_ct.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

Index: linux-2.6.20/drivers/video/aty/mach64_ct.c
===================================================================
--- linux-2.6.20.orig/drivers/video/aty/mach64_ct.c
+++ linux-2.6.20/drivers/video/aty/mach64_ct.c
@@ -598,7 +598,6 @@ static void aty_resume_pll_ct(const stru
 	struct atyfb_par *par = info->par;
 
 	if (par->mclk_per != par->xclk_per) {
-		int i;
 		/*
 		* This disables the sclk, crashes the computer as reported:
 		* aty_st_pll_ct(SPLL_CNTL2, 3, info);
@@ -609,12 +608,10 @@ static void aty_resume_pll_ct(const stru
 		aty_st_pll_ct(SCLK_FB_DIV, pll->ct.sclk_fb_div, par);
 		aty_st_pll_ct(SPLL_CNTL2, pll->ct.spll_cntl2, par);
 		/*
-		 * The sclk has been started. However, I believe the first clock
-		 * ticks it generates are not very stable. Hope this primitive loop
-		 * helps for Rage Mobilities that sometimes crash when
-		 * we switch to sclk. (Daniel Mantione, 13-05-2003)
+		 * The sclk has been started. Wait for the PLL to lock. 5 ms
+		 * should be enough according to mach64 programmers guide.
 		 */
-		for (i=0;i<=0x1ffff;i++);
+		mdelay(5);
 	}
 
 	aty_st_pll_ct(PLL_REF_DIV, pll->ct.pll_ref_div, par);
-- 
Ville Syrjälä
sy...@sc...
http://www.sci.fi/~syrjala/

[Linux-fbdev-users] atyfb - system hangs at bootup prior to enabling framebuffer console -- linux 2.6.18

[cga2000 <cg...@op...>]

More than 50% of the time my laptop hangs when booting with 

... video=atyfb:1400x1050.

I have seen similar occurrences reported here and there with recent 2.6
kernels but nothing very clear as to whether this is a known problem or
whether a patch or workaround has already been provided.

I have not been able to determine if the hang was random -- booting to
another system and then rebooting back into this debian "etch" system
appears (???) to fix the problem.

Relevant "lspci -vvv" output if it matters:

0000.01.00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA])
             Subsystem: Dell: Unknown device 009e
             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: 66 (2000ns min), Cache Line Size: 0x08 (32 bytes)
             Interrupt: pin A routed to IRQ 11
             Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
             Region 1: I/O ports at 2000 [size=256]
             Region 2: Memory at fc000000 (32-bit, non-prefetchable) [size=4K]
             Expansion ROM at <unassigned> [disabled] [size=128K]
             Capabilities: <available only to root>

I would be glad to provide additional info.

Thanks,
cga

Re: [Linux-fbdev-users] 1400x1050 linux console support with recent 2.6 linux kernels ?

[cga2000 <cg...@op...>]

On Tue, Feb 13, 2007 at 04:26:48AM EST, Ville Syrjälä wrote:

Works fine now I built mach64 support into the kernel. 

And modedb.c indeed has three 1400x1050 modes to choose from.  I'll take
a closer look tomorrow but since they don't have names/identifiers in
the code, I'm not sure how one is chosen over the others.

Not that it matters, the difference in crispness/definition of the fonts
on my display now that I'm running at the LCD's native resolution is
just unbelievable.

Thanks for your help.

cga.

Re: [Linux-fbdev-users] 1400x1050 linux console support with recent 2.6 linux kernels ?

[cga2000 <cg...@op...>]

On Tue, Feb 13, 2007 at 04:26:48AM EST, Ville Syrjälä wrote:
> On Mon, Feb 12, 2007 at 09:39:03PM -0500, cga2000 wrote:

<snip>

> > Are you talking about the linux console or "X" ..?
> 
> Console. I don't even use regular XOrg/XF86.
> 
> > My problem is getting the _linux console_ to work at 1400x1050.
> > 
> > Sorry if I was unclear.
> > 
> > Because I rebooted into that system, added a "1400x1050" mode in
> > /etc/fb.modes that I know is ok for my card/display .. did an "fbset
> > 1400x1050" .. and I just get my prompt back .. nothing happens.
> 
> Maybe you are using vesafb instead of atyfb. Do 'cat /proc/fb'.
> 
> > I'll try to add something to /etc/modules.conf to cause atyfb to load
> > at boot .. see if it makes a difference.
> 
> I've never tried modular atyfb, I just build it into the kernel. BTW 
> make sure you have the framebuffer console kernel config option enabled.

That's my problem.  Now I remember that you must have atyfb built into
the kernel for the atyfb framebuffer to work on the linux console.  I
checked the atyfb option in the .config file that ships with the default
debian kernel and sure 'nuff it's set to `m'.

As to my fbset attempt .. It's been a while and I can't find my notes ..
but I'm pretty sure it's part of vesafb and not going to do anything
spectacular where atyfb is concerned.

So I need a reconfigured 2.6 kernel and this should work.

Thanks,

cga

[Linux-fbdev-users] rivafb

[James L. <ja...@ak...>]

Why does the riva driver force the virtual resolution to be as high as
possible? If I can not choose to make the visible and the virtual screen
size the same, then one of my frame buffer animation techniques doesn't
work.

I create a bitmap memory object, the size of the screen, do my rendering
there and dump the whole thing to the display over and over again. In this
case, there's no reason to have a virtual area bigger than the visible
screen.

// drivers/video/riva/fbdev.c   approximately line 1232

        if (var->xres_virtual < var->xres)
                var->xres_virtual = var->xres;
        //if (var->yres_virtual <= var->yres)
        //        var->yres_virtual = -1;
        if (var->yres_virtual < var->yres)
              var->yres_virtual = var->yres;
        //if (rivafb_do_maximize(info, var, nom, den) < 0)
        //        return -EINVAL;

This change in the code makes it work, but the console text cursor is still
visible.

I also like to make the virtual screen exactly twice the size of the visible
screen and render in the off screen area and switch the offsets. This works
(*sort-of*) with the rivafb driver but there is some kind of sync problem.
The screen does not stay lit and provide a nice smooth animation like other
cards do. It looks noisy and blacks out sporadically.

http://www.akrobiz.com/ezfb
http://www.akrobiz.com/laserboy

James.   :o)

Re: [Linux-fbdev-users] 1400x1050 linux console support with recent 2.6 linux kernels ?

[Ville <sy...@sc...>]

On Mon, Feb 12, 2007 at 09:39:03PM -0500, cga2000 wrote:
> On Sun, Feb 11, 2007 at 10:07:38AM EST, Ville Syrjälä wrote:
> > On Fri, Feb 09, 2007 at 03:22:36PM -0500, cga2000 wrote:
> > > I have just installed debian etch on an old laptop that sports an ATI
> > > mach64 and a 1400x1050 display and I was wondering if the atyfb module
> > > that ships with recent 2.6 kernels supports this resolution.
> > > 
> > > This works beautifully with debian sarge and a 2.4.27 after you add the
> > > correct modes (?) to modedb.c .. recompile the kernel with the correct
> > > options enabled (as explained in the framebuffer console howto) .. and
> > > boot with the magical "video=atyfb:1400x1050.." parm.
> > > 
> > > I was planning on copying the modes I added to my old 2.4 modedb.c to
> > > the new one.  Not sure if this is going to work and if there are any
> > > caveats.
> > 
> > You probably don't need to add any modes. 2.6 atyfb will by default use 
> > the panel's native resolution. I'm actually writing this mail using a HP 
> > OmniBook 6000 w/ Rage Mobility and a 1400x1050 panel ;)
> 
> Are you talking about the linux console or "X" ..?

Console. I don't even use regular XOrg/XF86.

> My problem is getting the _linux console_ to work at 1400x1050.
> 
> Sorry if I was unclear.
> 
> Because I rebooted into that system, added a "1400x1050" mode in
> /etc/fb.modes that I know is ok for my card/display .. did an "fbset
> 1400x1050" .. and I just get my prompt back .. nothing happens.

Maybe you are using vesafb instead of atyfb. Do 'cat /proc/fb'.

> I'll try to add something to /etc/modules.conf to cause atyfb to load
> at boot .. see if it makes a difference.

I've never tried modular atyfb, I just build it into the kernel. BTW 
make sure you have the framebuffer console kernel config option enabled.

-- 
Ville Syrjälä
sy...@sc...
http://www.sci.fi/~syrjala/

Re: [Linux-fbdev-users] 1400x1050 linux console support with recent 2.6 linux kernels ?

[cga2000 <cg...@op...>]

On Sun, Feb 11, 2007 at 10:07:38AM EST, Ville Syrjälä wrote:
> On Fri, Feb 09, 2007 at 03:22:36PM -0500, cga2000 wrote:
> > I have just installed debian etch on an old laptop that sports an ATI
> > mach64 and a 1400x1050 display and I was wondering if the atyfb module
> > that ships with recent 2.6 kernels supports this resolution.
> > 
> > This works beautifully with debian sarge and a 2.4.27 after you add the
> > correct modes (?) to modedb.c .. recompile the kernel with the correct
> > options enabled (as explained in the framebuffer console howto) .. and
> > boot with the magical "video=atyfb:1400x1050.." parm.
> > 
> > I was planning on copying the modes I added to my old 2.4 modedb.c to
> > the new one.  Not sure if this is going to work and if there are any
> > caveats.
> 
> You probably don't need to add any modes. 2.6 atyfb will by default use 
> the panel's native resolution. I'm actually writing this mail using a HP 
> OmniBook 6000 w/ Rage Mobility and a 1400x1050 panel ;)

Are you talking about the linux console or "X" ..?

My problem is getting the _linux console_ to work at 1400x1050.

Sorry if I was unclear.

Because I rebooted into that system, added a "1400x1050" mode in
/etc/fb.modes that I know is ok for my card/display .. did an "fbset
1400x1050" .. and I just get my prompt back .. nothing happens.

I'll try to add something to /etc/modules.conf to cause atyfb to load
at boot .. see if it makes a difference.

I may also have to configure udev since at some point while fiddling I
got a message that said something like "/dev/fb0/ non such file or
directory".

Thanks,

cga

As to my other problem -- ie. my bouncing posts, I suspect that what is
happening is that I may have used a different email when I subscribed..
and I'm not sure what I should do.  Maybe try all the email addresses
that I have used in the past until I find the right one .. cancel my
current subscription .. and subscribe again under my current email
address ..  sounds like the easiest way to fix this.