From: Antonino A. Daplas <hidden> Date: 2005-02-14 23:40:58
On Tuesday 15 February 2005 01:55, Frans Pop wrote:
Hello Tony,
Thanks for your reaction.
On Monday 14 February 2005 17:59, Antonino A. Daplas wrote:
quoted
The above timings are screwed. This is 1024x768 at 85Hz INTERLACED.
The fb_find_mode() function picked up this mode when you specified
1024x768@75, since there is no such mode in the mode database.
And the atyfb driver accepted the mode without differentiating between
interlaced and non-interlaced.
Right. I tried with 1024x768@70 and that gives some improvement.
For a very, very short time I see the Linux logo and some boot messages
flash on the display, but then the monitor still goes into suspend.
It really is just a flash, but I think I see some of the atyfb debug
messages. That would indicate that the suspend is activated somewhere near
the end of console initialization (maybe at the "switching to colour frame
buffer device 128x48"?). But again, this is based on an impression.
So it seems there are two bugs:
- missing/incorrect default mode settings for sparc in the driver;
- incorrect activation of suspend.
Try editing drivers/video/console/fbcon.c, look for the function
fbcon_startup(). After the line 'ops->currcon = -1;', insert this line:
ops->blank_state = -1;
Also, try changing the graphics state such as doing an
fbset -depth 16 or the like.
What happens if you switch consoles?
You can also try commenting out .fb_blank = atyfb_blank from
static struct fb_ops atyfb_ops and disable CONFIG_PM from your kernel
config.
quoted
PS: There was also a massive atyfb update between 2.6.10-rc1 and rc2.
Here's the changelog:
From: Frans Pop <hidden> Date: 2005-02-15 06:22:15
Hi Tony,
I've tried your suggestions and the one about using fbset resulted in a
breakthrough. 'fbset -depth' gave no results, but comparing the output of
'fbset -i' from a working kernel and a new one gave me something to try.
From 2.6.8 kernel (working framebuffer):
mode "1152x900-66"
# D: 93.870 MHz, H: 61.433 kHz, V: 65.564 Hz
geometry 1152 900 1152 1792 8
timings 10653 190 58 31 2 128 4
hsync high
csync high
accel true
rgba 8/0,8/0,8/0,0/0
endmode
Frame buffer device information:
Name : ATY Mach64
Address : 0xe1800000
Size : 2088960
Type : PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep : 8
YPanStep : 1
YWrapStep : 0
LineLength : 1152
MMIO Address: 0xfffffc00
MMIO Size : 2048
Accelerator : ATI Mach64GT
<end>
From 2.6.10-rc2 (not working):
mode "1024x768-70"
# D: 74.778 MHz, H: 56.308 kHz, V: 69.862 Hz
geometry 1024 768 1024 2016 8
timings 13373 144 24 29 3 136 6
accel true
rgba 8/0,8/0,8/0,0/0
endmode
Frame buffer device information:
Name : ATY Mach64
Address : 0xe1800000
Size : 2088960
Type : PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep : 8
YPanStep : 1
YWrapStep : 0
LineLength : 1024
MMIO Address: 0xe17ff800
MMIO Size : 2048
Accelerator : ATI Mach64GT
<end>
The significant difference is in the settings for hsync and csync. After
setting both 'high' (hsync alone did nothing) from a SSH terminal the
monitor turned on :-D
I hope this will be enough of a clue for those who know the driver code to
work out a patch.
These values also tell that the old default mode was 1152x900-66,
resulting in a 144x56 textconsole. My personal opinion is that that is
very high for a default mode. The 1024x768-70 (resulting in 128x48) I've
been using now (or maybe even something a bit lower) seems more
reasonable to me.
For completeness sake I've included the answers to your questions below.
Cheers,
Frans
On Tuesday 15 February 2005 00:40, Antonino A. Daplas wrote:
Try editing drivers/video/console/fbcon.c, look for the function
fbcon_startup(). After the line 'ops->currcon = -1;', insert this line:
ops->blank_state = -1;
Hmm. Results in a compilation error when I tried that in -rc2: no such
variable in that structure.
I checked 2.6.11-rc3-bk2 and noticed it was added there, so I tested this
suggestion with that version. No difference.
Also, try changing the graphics state such as doing an
fbset -depth 16 or the like.
I tried that from my ssh terminal and only -depth 8 was accepted.
Both 16 and 24 gave the same result:
# fbset -depth 16 -fb /dev/fb0
ioctl FBIOPUT_VSCREENINFO: Invalid argument
What happens if you switch consoles?
Nothing at all. Hitting keys does nothing either, also not after leaving
the system alone for a long time.
You can also try commenting out .fb_blank = atyfb_blank from
static struct fb_ops atyfb_ops and disable CONFIG_PM from your kernel
config.
The first suggestion makes no difference.
As to the CONFIG_PM: there is no such setting in my .config for sparc64
(i386 does have it). I do have CONFIG_FB_PM2, but that is not set.
These values also tell that the old default mode was 1152x900-66,
resulting in a 144x56 textconsole. My personal opinion is that that is
very high for a default mode. The 1024x768-70 (resulting in 128x48) I've
been using now (or maybe even something a bit lower) seems more
reasonable to me.
1152x900 is the default Sun mode.
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
From: Antonino A. Daplas <hidden> Date: 2005-02-15 12:10:21
On Tuesday 15 February 2005 14:22, Frans Pop wrote:
Hi Tony,
I've tried your suggestions and the one about using fbset resulted in a
breakthrough. 'fbset -depth' gave no results, but comparing the output of
'fbset -i' from a working kernel and a new one gave me something to try.
Okay. It seems that in the working kernel, the default mode, 1152x900, was
taken from the prom (since there is no 1152x900 in the mode database) if you
did not specify any boot mode option.
In the non-working version, without the boot mode option, the default_var
was used (which is only 640x480) or taken from the mode database if you
specified a boot mode. Unfortunately, none of the entries in the mode
database nor the default var has the composite sync set to high, which
causes your display to go out of sync. If I'm going to guess, the 2.6.10
version failed to get the default mode from the prom.
Can you verify if this is the case? Insert a bunch of printk's in and around this
line "if (node == pcp->prom_node) {" in atyfb_setup_sparc(). For the 2.6.8
kernel, this line is in atyfb_init().
As a workaround, a boot option can be added for csync, hsync and vsync.
Tony
From: "David S. Miller" <davem@davemloft.net> Date: 2005-02-15 16:49:58
On Tue, 15 Feb 2005 20:10:21 +0800
"Antonino A. Daplas" [off-list ref] wrote:
Okay. It seems that in the working kernel, the default mode, 1152x900, was
taken from the prom (since there is no 1152x900 in the mode database) if you
did not specify any boot mode option.
In the non-working version, without the boot mode option, the default_var
was used (which is only 640x480) or taken from the mode database if you
specified a boot mode.
I think the bug is in the changes made to the fb_find_mode() calls
in the !CONFIG_PPC case. That looked suspicious to me the first time
I scanned the atyfb driver diffs in 2.6.11
First of all, a file global declared as "static char *mode" is asking for
all sorts of trouble. It's very easy to use such a simple name as
a function local variable, thus making the global one invisible.
I reviewed the driver and there are no cases of local variables named
"mode" right now, but this is still asking for trouble in the future.
It should be thus renamed.
Now let's get back to the fb_find_mode() call in aty_init(). The old
code for the non-CONFIG_PPC case did this:
#ifdef __sparc__
if (mode_option) {
if (!fb_find_mode(...))
var = default_var;
} else
var = default_var;
#else
if (!fb_find_mode(...))
var = default_var;
#endif
The new code calls fb_find_mode() always, this is wrong for Sparc's
desired behavior:
if (!fb_find_mode(...))
var = default_var;
On sparc, when "mode" is NULL, we should always use default_var as
setup by PROM probed values.
Here is the fix:
===== drivers/video/aty/atyfb_base.c 1.82 vs edited =====
@@ -2511,7 +2511,15 @@}}else#endif /* !CONFIG_PPC */-if(!fb_find_mode(&var,info,mode,NULL,0,&defmode,8))+if(+#if defined(CONFIG_SPARC32) || defined(CONFIG_SPARC64)+/* On Sparc, unless the user gave a specific mode+*specification,usethePROMprobedvaluesin+*default_var.+*/+!mode||+#endif+!fb_find_mode(&var,info,mode,NULL,0,&defmode,8))var=default_var;if(noaccel)
From: Frans Pop <hidden> Date: 2005-02-16 02:27:38
On Tuesday 15 February 2005 13:10, Antonino A. Daplas wrote:
Can you verify if this is the case? Insert a bunch of printk's in and
around this line "if (node == pcp->prom_node) {" in
atyfb_setup_sparc(). For the 2.6.8 kernel, this line is in
atyfb_init().
Tested that and output is identical for both. That condition you cite is
true for both kernels and the resolutions are retrieved from prom:
atyfb (fjp): crtc.vxres 1152
atyfb (fjp): crtc.vyres 900
As a workaround, a boot option can be added for csync, hsync and vsync.
Hmm. I looked for the syntax for that, but can't find it.
I tried
video=atyfb:1024x768@70,csync:1
and
video=atyfb:1024x768@70,csync:high
but both failed miserably.
(I have checked that csync is sufficient to activate the monitor.)
What I get is boot messages 'vclk out of range' and 'not enough video RAM'
and I end up with 640x480-60 with both hsync and _v_sync set high, but
not csync (and a monitor in suspend of course).
From: Frans Pop <hidden> Date: 2005-02-16 02:27:51
On Tuesday 15 February 2005 17:49, David S. Miller wrote:
On sparc, when "mode" is NULL, we should always use default_var as
setup by PROM probed values.
Here is the fix:
Excellent!
Tested the patch with 2.6.11-rc3-bk2 and AFAICT it completely restores the
old behavior. I guess that solves the regression since 2.6.10-rc2.
Please let me know if this patch will be submitted for inclusion as is so
I can also submit it for inclusion in the Debian 2.6.10 kernel.
From my experiences in tracing and testing this, I have a couple of
questions I'd like to put before you and the lists. (I should add that my
experience with sparcs is still very limited.)
I would like to set a lower default resolution as my monitor barely
supports 1152x900@66. I tried two things:
- # eeprom output-device=screen:r1024x768x70
This seems to be completely ignored during boot; resolution is still
1152x900.
- boot with parameter 'video=atyfb:1024x768@70'
This does work, but csync is not set to high and so the monitor again
goes into suspend; after 'fbset -csync high' the monitor turns on.
Is csync something that needs to be set by the user or should the driver
take care of that also at frequencies other then 1152x900?
The second question concerns the use of Stop-A.
With the console at 1152x900@66, if I press Stop-A, I get the openprom
prompt. The screen has the last display before pressing Stop-A with a
white square inside it containing the openprom display (filling about 75%
of the screen).
If I do the same at 1024x768@70, I get a garbled display (no readable text
from the openprom). I can still press go to return to linux though and
the display is restored after clearing it.
Can/should this be fixed or should the conclusion be that resolutions
other than 1152x900@66 are just not supported?
Cheers,
Frans Pop
From: "David S. Miller" <davem@davemloft.net> Date: 2005-02-16 03:20:18
On Wed, 16 Feb 2005 03:27:51 +0100
Frans Pop [off-list ref] wrote:
Excellent!
Tested the patch with 2.6.11-rc3-bk2 and AFAICT it completely restores the
old behavior. I guess that solves the regression since 2.6.10-rc2.
Please let me know if this patch will be submitted for inclusion as is so
I can also submit it for inclusion in the Debian 2.6.10 kernel.
I applied it and will push upstream.
I would like to set a lower default resolution as my monitor barely
supports 1152x900@66. I tried two things:
- # eeprom output-device=screen:r1024x768x70
This seems to be completely ignored during boot; resolution is still
1152x900.
The PROM console driver will only accept certain settings. I believe
the allowable settings is documented in the Sun Framebuffer Handbook
or something like that.
- boot with parameter 'video=atyfb:1024x768@70'
This does work, but csync is not set to high and so the monitor again
goes into suspend; after 'fbset -csync high' the monitor turns on.
Is csync something that needs to be set by the user or should the driver
take care of that also at frequencies other then 1152x900?
Unfortunately, the user needs to specify this. I, at one point, even
convinced the XFREE86 mach64 maintainer to enable CSYNC by default
and that broke things for some users and thus the default had to be
changed back to off.
Therefore the kernel fb driver shouldn't turn CSYNC on by default either.
The second question concerns the use of Stop-A.
If you tell the kernel to use a different resolution than the PROM had,
stop-a is not going to work.
From: Antonino A. Daplas <hidden> Date: 2005-02-16 11:27:57
On Wednesday 16 February 2005 10:27, Frans Pop wrote:
On Tuesday 15 February 2005 13:10, Antonino A. Daplas wrote:
quoted
Can you verify if this is the case? Insert a bunch of printk's in and
around this line "if (node == pcp->prom_node) {" in
atyfb_setup_sparc(). For the 2.6.8 kernel, this line is in
atyfb_init().
Tested that and output is identical for both. That condition you cite is
true for both kernels and the resolutions are retrieved from prom:
atyfb (fjp): crtc.vxres 1152
atyfb (fjp): crtc.vyres 900
quoted
As a workaround, a boot option can be added for csync, hsync and vsync.
Hmm. I looked for the syntax for that, but can't find it.
I tried
video=atyfb:1024x768@70,csync:1
and
video=atyfb:1024x768@70,csync:high
but both failed miserably.
(I have checked that csync is sufficient to activate the monitor.)
Nope, those are proposed options. If nobody disagrees, I can easily add
this for atyfb.
Tony
From: Antonino A. Daplas <hidden> Date: 2005-02-16 11:30:14
On Wednesday 16 February 2005 11:20, David S. Miller wrote:
On Wed, 16 Feb 2005 03:27:51 +0100
Frans Pop [off-list ref] wrote:
quoted
Excellent!
Tested the patch with 2.6.11-rc3-bk2 and AFAICT it completely restores
the old behavior. I guess that solves the regression since 2.6.10-rc2.
Please let me know if this patch will be submitted for inclusion as is so
I can also submit it for inclusion in the Debian 2.6.10 kernel.
I applied it and will push upstream.
Great, I was about to push this upstream. Thanks.
Tony
From: Antonino A. Daplas <hidden> Date: 2005-02-16 23:02:57
On Thursday 17 February 2005 06:10, Frans Pop wrote:
On Wednesday 16 February 2005 16:51, David S. Miller wrote:
quoted
On Wed, 16 Feb 2005 19:27:57 +0800 Antonino A. Daplas wrote:
quoted
Nope, those are proposed options. If nobody disagrees, I can easily
add this for atyfb.
Please do.
BTW, for Sparc we may wish to inherit the CSYNC setting from
default_var.
Sounds like a nice idea.
If you have a patch that you would like to have tested, feel free to mail
me.
Try this patch and let me know.
video=atyfb:comp_sync:<n>,vert_sync:<n>,hor_sync:<n>
n = 0 (low), 1 (high)
Tony
diff -Nru a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
@@ -3701,6 +3731,12 @@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(vert_sync,int,0)+MODULE_PARM_DESC(vert_sync,"Set vertical sync signal to low (0) or high (1)");+module_param(hor_sync,int,0)+MODULE_PARM_DESC(hor_sync,"Set horizontal 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
@@ -3701,6 +3731,12 @@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(vert_sync,int,0)+MODULE_PARM_DESC(vert_sync,"Set vertical sync signal to low (0) or high (1)");+module_param(hor_sync,int,0)+MODULE_PARM_DESC(hor_sync,"Set horizontal 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
From: Frans Pop <hidden> Date: 2005-02-17 14:16:05
On Thursday 17 February 2005 00:24, Antonino A. Daplas wrote:
quoted
Try this patch and let me know.
video=atyfb:comp_sync:<n>,vert_sync:<n>,hor_sync:<n>
n = 0 (low), 1 (high)
I've tested with the following combinations:
- append="video=atyfb:comp_sync:1,1024x768@70"
Works perfectly: csync is high and good display.
- append="video=atyfb:comp_sync:1,hor_sync:1,vert_sync:0,1024x768@70"
csync is high, but for some reason not hsync; display is good.
- append="video=atyfb:1024x768@70,comp_sync:1"
Same results as first test.
The sync settings were checked with 'fbset -i'.
BTW, the mode string should always be the last parameter, ie;
video=atyfb:comp_sync:1,1024x768@70
Hmmm. Wonder why you say that (considering the result of my last test).
Should these new options also be documented in Documentation/fb/?
Cheers,
Frans
From: Antonino A. Daplas <hidden> Date: 2005-02-17 21:30:59
On Thursday 17 February 2005 22:16, Frans Pop wrote:
On Thursday 17 February 2005 00:24, Antonino A. Daplas wrote:
quoted
quoted
Try this patch and let me know.
video=atyfb:comp_sync:<n>,vert_sync:<n>,hor_sync:<n>
n = 0 (low), 1 (high)
I've tested with the following combinations:
- append="video=atyfb:comp_sync:1,1024x768@70"
Works perfectly: csync is high and good display.
- append="video=atyfb:comp_sync:1,hor_sync:1,vert_sync:0,1024x768@70"
csync is high, but for some reason not hsync; display is good.
Okay, it seems that overriding the vsync and hsync settings is useless in
atyfb as it has its own algo to do that:
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'll trim the patch for csync only.
- append="video=atyfb:1024x768@70,comp_sync:1"
Same results as first test.
The sync settings were checked with 'fbset -i'.
quoted
BTW, the mode string should always be the last parameter, ie;
video=atyfb:comp_sync:1,1024x768@70
Hmmm. Wonder why you say that (considering the result of my last test).
My mistake then. Thanks for verifying.
Should these new options also be documented in Documentation/fb/?
I'll add this and fix a few buglets when I push upstream.
Tony
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click