atyfb h/vsync polarity

atyfb h/vsync polarity

[Raphael Assenat]

Hi,
I am a Linux Sparc64 user, and recently I decided to switch from 2.4
kernel series to 2.6 series. Everything worked well, but I had trouble
getting the framebuffer console to work.

In openboot, my monitor worked perfectly. But as soon as Linux
configured the framebuffer, my monitor would loose sync. I compared the
output given by fbset on the working configuration (2.4 kernel) and the
non-working configuration (2.6.12 kernel). Every setting was identical,
except that the output on 2.4 had 'hsync high'. I tried 'fbset -hsync
high', but the screen still did not sync, and fbset still did not report
'hsync high', as if the setting was ignored.

After digging a little bit, I found this in
drivers/video/aty/atyfb_base.c:

if(vdisplay < 400) {
		h_sync_pol = 1;
		v_sync_pol = 0;
} else if(vdisplay < 480) {
		h_sync_pol = 0;
		v_sync_pol = 1;
} else if(vdisplay < 768) {
		h_sync_pol = 0;
		v_sync_pol = 0;
} else {
		h_sync_pol = 1;
		v_sync_pol = 1;
}

So no mater what sync polarity we ask for, the driver overrides them. I commented
the code above in my build, and the framebuffer console finally works.

It seems strange to me that the driver ignores the sync polarity we request,
but I'm sure the above code exists for a good reason so I would not suggest to
simply remove it as a fix. Can anyone explain why this code is
necessary?

The fact that this cause problems for me is probably due to my particular video setup:
Ultra10 vga -> passive VGA csync on hsync pin to sync on green adapter -> 
passive VGA to 13W3 adapter -> GDM-17E11 SGI monitor (requires sync-on-green).

IMHO, the driver should preserve the settings from openboot, not only the 
resoltion and sync frequencies, but also the sync polarities. 

Regards,
Raphael Assenat



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: atyfb h/vsync polarity

[Alexander Kern]

Am Mittwoch, 22. Juni 2005 16:08 schrieb Raphael Assenat:
> Hi,
> I am a Linux Sparc64 user, and recently I decided to switch from 2.4
> kernel series to 2.6 series. Everything worked well, but I had trouble
> getting the framebuffer console to work.
>
> In openboot, my monitor worked perfectly. But as soon as Linux
> configured the framebuffer, my monitor would loose sync. I compared the
> output given by fbset on the working configuration (2.4 kernel) and the
> non-working configuration (2.6.12 kernel). Every setting was identical,
> except that the output on 2.4 had 'hsync high'. I tried 'fbset -hsync
> high', but the screen still did not sync, and fbset still did not report
> 'hsync high', as if the setting was ignored.
>
> After digging a little bit, I found this in
> drivers/video/aty/atyfb_base.c:
>
> if(vdisplay < 400) {
> 		h_sync_pol = 1;
> 		v_sync_pol = 0;
> } else if(vdisplay < 480) {
> 		h_sync_pol = 0;
> 		v_sync_pol = 1;
> } else if(vdisplay < 768) {
> 		h_sync_pol = 0;
> 		v_sync_pol = 0;
> } else {
> 		h_sync_pol = 1;
> 		v_sync_pol = 1;
> }
>
> So no mater what sync polarity we ask for, the driver overrides them. I
> commented the code above in my build, and the framebuffer console finally
> works.
>
> It seems strange to me that the driver ignores the sync polarity we
> request, but I'm sure the above code exists for a good reason so I would
> not suggest to simply remove it as a fix. Can anyone explain why this code
> is
> necessary?
this behaviour is from XFree code and more VGA like.
>
> The fact that this cause problems for me is probably due to my particular
> video setup: Ultra10 vga -> passive VGA csync on hsync pin to sync on green
> adapter -> passive VGA to 13W3 adapter -> GDM-17E11 SGI monitor (requires
> sync-on-green).
>
Anyway, SPARC has own rules, This error was always disputed on the list, 
Here is a patch.

From: "Antonino A. Daplas" <adaplas@hotpop.com>

Some SPARC-based displays need the composite sync set to high.  Since none
of the entries in the default db has the composite sync set to high, using
fb_find_mode() will produce a blank display.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Acked-by: Alexander Kern <alex.kern@gmx.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/drivers/video/aty/atyfb_base.c |   13 +++++++++++++
 1 files changed, 13 insertions(+)

diff -puN 
drivers/video/aty/atyfb_base.c~atyfb-add-boot-module-option-to-override-composite-sync 
drivers/video/aty/atyfb_base.c
--- 
25/drivers/video/aty/atyfb_base.c~atyfb-add-boot-module-option-to-override-composite-sync   2005-03-31 
03:06:50.000000000 -0800
+++ 25-akpm/drivers/video/aty/atyfb_base.c      2005-03-31 03:09:07.000000000 
-0800
@@ -307,6 +307,7 @@ static int vram;
 static int pll;
 static int mclk;
 static int xclk;
+static int comp_sync __initdata = -1;
 static char *mode;
 
 #ifdef CONFIG_PPC
@@ -2527,6 +2528,13 @@ static int __init aty_init(struct fb_inf
        else
                var.accel_flags |= FB_ACCELF_TEXT;
 
+       if (comp_sync != -1) {
+               if (!comp_sync)
+                       var.sync &= ~FB_SYNC_COMP_HIGH_ACT;
+               else
+                       var.sync |= FB_SYNC_COMP_HIGH_ACT;
+       }
+
        if (var.yres == var.yres_virtual) {
                u32 videoram = (info->fix.smem_len - (PAGE_SIZE << 2));
                var.yres_virtual = ((videoram * 8) / var.bits_per_pixel) / 
var.xres_virtual;
@@ -3612,6 +3620,8 @@ static int __init atyfb_setup(char *opti
                        mclk = simple_strtoul(this_opt + 5, NULL, 0);
                else if (!strncmp(this_opt, "xclk:", 5))
                        xclk = simple_strtoul(this_opt+5, NULL, 0);
+               else if (!strncmp(this_opt, "comp_sync:", 10))
+                       comp_sync = simple_strtoul(this_opt+10, NULL, 0);
 #ifdef CONFIG_PPC
                else if (!strncmp(this_opt, "vmode:", 6)) {
                        unsigned int vmode =
@@ -3701,6 +3711,9 @@ module_param(mclk, int, 0);
 MODULE_PARM_DESC(mclk, "int: override memory clock");
 module_param(xclk, int, 0);
 MODULE_PARM_DESC(xclk, "int: override accelerated engine clock");
+module_param(comp_sync, int, 0);
+MODULE_PARM_DESC(comp_sync,
+                "Set composite sync signal to low (0) or high (1)");
 module_param(mode, charp, 0);
 MODULE_PARM_DESC(mode, "Specify resolution as \"<xres>x<yres>[-<bpp>]
[@<refresh>]\" ");
 #ifdef CONFIG_MTRR
_

> IMHO, the driver should preserve the settings from openboot, not only the
> resoltion and sync frequencies, but also the sync polarities.
>
> Regards,
> Raphael Assenat

Best Wishes
Mit freundlichen Grüßen

Alex Kern


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

Re: atyfb h/vsync polarity

[Ville Syrjälä]

On Thu, Jun 23, 2005 at 11:25:10AM +0200, Alexander Kern wrote:
> Am Mittwoch, 22. Juni 2005 16:08 schrieb Raphael Assenat:
> > Hi,
> > I am a Linux Sparc64 user, and recently I decided to switch from 2.4
> > kernel series to 2.6 series. Everything worked well, but I had trouble
> > getting the framebuffer console to work.
> >
> > In openboot, my monitor worked perfectly. But as soon as Linux
> > configured the framebuffer, my monitor would loose sync. I compared the
> > output given by fbset on the working configuration (2.4 kernel) and the
> > non-working configuration (2.6.12 kernel). Every setting was identical,
> > except that the output on 2.4 had 'hsync high'. I tried 'fbset -hsync
> > high', but the screen still did not sync, and fbset still did not report
> > 'hsync high', as if the setting was ignored.
> >
> > After digging a little bit, I found this in
> > drivers/video/aty/atyfb_base.c:
> >
> > if(vdisplay < 400) {
> > 		h_sync_pol = 1;
> > 		v_sync_pol = 0;
> > } else if(vdisplay < 480) {
> > 		h_sync_pol = 0;
> > 		v_sync_pol = 1;
> > } else if(vdisplay < 768) {
> > 		h_sync_pol = 0;
> > 		v_sync_pol = 0;
> > } else {
> > 		h_sync_pol = 1;
> > 		v_sync_pol = 1;
> > }
> >
> > So no mater what sync polarity we ask for, the driver overrides them. I
> > commented the code above in my build, and the framebuffer console finally
> > works.
> >
> > It seems strange to me that the driver ignores the sync polarity we
> > request, but I'm sure the above code exists for a good reason so I would
> > not suggest to simply remove it as a fix. Can anyone explain why this code
> > is
> > necessary?
> this behaviour is from XFree code and more VGA like.

I don't think this sort of code really belongs in atyfb. If someone wants 
to follow this rule he can simply use modelines with the appropriate sync 
polarities.

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


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

Re: atyfb h/vsync polarity

[Raphael Assenat]

On Thu, Jun 23, 2005 at 11:25:10AM +0200, Alexander Kern wrote:
> Am Mittwoch, 22. Juni 2005 16:08 schrieb Raphael Assenat:
> > It seems strange to me that the driver ignores the sync polarity we
> > request, but I'm sure the above code exists for a good reason so I would
> > not suggest to simply remove it as a fix. Can anyone explain why this code
> > is
> > necessary?
> this behaviour is from XFree code and more VGA like.
But I dont like the idea that the driver thinking it knows better than me
what sync polarities I should use. I have a setup where I absolutely need hsync to
be high, but the driver prevents me from doing it!

> >
> > The fact that this cause problems for me is probably due to my particular
> > video setup: Ultra10 vga -> passive VGA csync on hsync pin to sync on green
> > adapter -> passive VGA to 13W3 adapter -> GDM-17E11 SGI monitor (requires
> > sync-on-green).
> >
> Anyway, SPARC has own rules, This error was always disputed on the list, 
> Here is a patch.
[patch removed]

This patch seem to be already in 2.6.12n and it does not fix my problem.
The problem on my machine is not with Csync being inactive (it is
active). I need Csync *and* high hsync polarity. H and V sync polarity  still matters, 
even if V and H sync are combined to form csync.

Regards,
Raphael Assenat



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: atyfb h/vsync polarity

[Antonino A. Daplas]

On Wednesday 22 June 2005 22:08, Raphael Assenat wrote:
> Hi,
> I am a Linux Sparc64 user, and recently I decided to switch from 2.4
> kernel series to 2.6 series. Everything worked well, but I had trouble
> getting the framebuffer console to work.
>
> In openboot, my monitor worked perfectly. But as soon as Linux
> configured the framebuffer, my monitor would loose sync. I compared the
> output given by fbset on the working configuration (2.4 kernel) and the
> non-working configuration (2.6.12 kernel). Every setting was identical,
> except that the output on 2.4 had 'hsync high'. I tried 'fbset -hsync
> high', but the screen still did not sync, and fbset still did not report
> 'hsync high', as if the setting was ignored.
>
> After digging a little bit, I found this in
> drivers/video/aty/atyfb_base.c:
>
> if(vdisplay < 400) {
> 		h_sync_pol = 1;
> 		v_sync_pol = 0;
> } else if(vdisplay < 480) {
> 		h_sync_pol = 0;
> 		v_sync_pol = 1;
> } else if(vdisplay < 768) {
> 		h_sync_pol = 0;
> 		v_sync_pol = 0;
> } else {
> 		h_sync_pol = 1;
> 		v_sync_pol = 1;
> }
>

I also believe that the above code is not needed.  The appropriate
sync signals are already correctly set (hopefully) from the entries
in the mode database, kernel or user.

Also, if I remember the VGA standards correctly, hsync and vsync
should be high if vyres > 400.

Tony



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

[PATCH] Re: atyfb h/vsync polarity

[Alexander Kern]

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

Am Freitag, 22. Juli 2005 06:06 schrieb Antonino A. Daplas:
> On Wednesday 22 June 2005 22:08, Raphael Assenat wrote:
> > Hi,
> > I am a Linux Sparc64 user, and recently I decided to switch from 2.4
> > kernel series to 2.6 series. Everything worked well, but I had trouble
> > getting the framebuffer console to work.
> >
> > In openboot, my monitor worked perfectly. But as soon as Linux
> > configured the framebuffer, my monitor would loose sync. I compared the
> > output given by fbset on the working configuration (2.4 kernel) and the
> > non-working configuration (2.6.12 kernel). Every setting was identical,
> > except that the output on 2.4 had 'hsync high'. I tried 'fbset -hsync
> > high', but the screen still did not sync, and fbset still did not report
> > 'hsync high', as if the setting was ignored.
> >
> > After digging a little bit, I found this in
> > drivers/video/aty/atyfb_base.c:
> >
> > if(vdisplay < 400) {
> > 		h_sync_pol = 1;
> > 		v_sync_pol = 0;
> > } else if(vdisplay < 480) {
> > 		h_sync_pol = 0;
> > 		v_sync_pol = 1;
> > } else if(vdisplay < 768) {
> > 		h_sync_pol = 0;
> > 		v_sync_pol = 0;
> > } else {
> > 		h_sync_pol = 1;
> > 		v_sync_pol = 1;
> > }
>
> I also believe that the above code is not needed.  The appropriate
> sync signals are already correctly set (hopefully) from the entries
> in the mode database, kernel or user.
>
> Also, if I remember the VGA standards correctly, hsync and vsync
> should be high if vyres > 400.
>
> Tony

Signed-off-by: Alexander Kern <alex.kern@gmx.de>

-- 

Best Wishes
Mit freundlichen Grüßen

Alex Kern

[-- Attachment #2: remove-unneeded-code.patch --]
[-- Type: text/x-diff, Size: 533 bytes --]

--- linux-2.6.12/drivers/video/aty/atyfb_base.c.orig	2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.12/drivers/video/aty/atyfb_base.c	2005-07-31 01:01:47.000000000 +0200
@@ -911,20 +911,6 @@
 		vdisplay  = par->lcd_height;
 #endif
 
-	if(vdisplay < 400) {
-		h_sync_pol = 1;
-		v_sync_pol = 0;
-	} else if(vdisplay < 480) {
-		h_sync_pol = 0;
-		v_sync_pol = 1;
-	} else if(vdisplay < 768) {
-		h_sync_pol = 0;
-		v_sync_pol = 0;
-	} else {
-		h_sync_pol = 1;
-		v_sync_pol = 1;
-	}
-
 	v_disp--;
 	v_sync_strt--;
 	v_sync_end--;

Re: [PATCH] Re: atyfb h/vsync polarity

[Andrew Morton]

> --- linux-2.6.12/drivers/video/aty/atyfb_base.c.orig	2005-06-17 21:48:29.000000000 +0200
> +++ linux-2.6.12/drivers/video/aty/atyfb_base.c	2005-07-31 01:01:47.000000000 +0200
> @@ -911,20 +911,6 @@
>  		vdisplay  = par->lcd_height;
>  #endif
>  
> -	if(vdisplay < 400) {
> -		h_sync_pol = 1;
> -		v_sync_pol = 0;
> -	} else if(vdisplay < 480) {
> -		h_sync_pol = 0;
> -		v_sync_pol = 1;
> -	} else if(vdisplay < 768) {
> -		h_sync_pol = 0;
> -		v_sync_pol = 0;
> -	} else {
> -		h_sync_pol = 1;
> -		v_sync_pol = 1;
> -	}
> -
>  	v_disp--;
>  	v_sync_strt--;
>  	v_sync_end--;
> 

I'll duck this one for now.  Tony, please resend when it's had approproate
testing at your end.

Alex, please include a nice changelog with your patches?  Someone has to
write one for this patch now.



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: [PATCH] Re: atyfb h/vsync polarity

[Antonino A. Daplas]

Andrew Morton wrote:

> 
> I'll duck this one for now.  Tony, please resend when it's had approproate
> testing at your end.

Ok.  Although I believe that what the patch is doing is correct.  But I'll
resend it post 2.6.13.

Tony


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click