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
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" <redacted>
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 <redacted>
Acked-by: Alexander Kern <redacted>
Signed-off-by: Andrew Morton <redacted>
---
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_id492&op=click
On Thu, Jun 23, 2005 at 11:25:10AM +0200, Alexander Kern wrote:
Am Mittwoch, 22. Juni 2005 16:08 schrieb Raphael Assenat:
quoted
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_id492&op=click
On Thu, Jun 23, 2005 at 11:25:10AM +0200, Alexander Kern wrote:
Am Mittwoch, 22. Juni 2005 16:08 schrieb Raphael Assenat:
quoted
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!
quoted
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
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
Am Freitag, 22. Juli 2005 06:06 schrieb Antonino A. Daplas:
On Wednesday 22 June 2005 22:08, Raphael Assenat wrote:
quoted
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 <redacted>
--
Best Wishes
Mit freundlichen Grüßen
Alex Kern