[PATCH] rivafb sync polarity problem?

STALE8624d

6 messages, 3 authors, 2003-01-24 · open the first message on its own page

[PATCH] rivafb sync polarity problem?

From: Fredrik Noring <hidden>
Date: 2003-01-19 12:54:46

Hi,

It seems the mode below doesn't work with rivafb in Linux 2.4.21-pre2,
the RGB (TV) screen fail to sync properly. (The equivalent modeline in
XFree86 4.2 works.)

    mode "768x288"
        geometry   768 288   768 288   32
        timings    62500   120 80   20 2   54 2
        hsync low
        vsync low
    endmode

I suspect it may have something to do with the sync polarity, as it
does not seem to be implemented fully in the rivafb driver? (Then again,
it seems the polarity always is forced low by the driver, I'm not sure.)

Looking at http://web.inter.nl.net/hcc/S.Weijgers/FreeVGA/vga/extreg.htm
and reading XFree86 source code indicate it should be fairly simple to
solve this, given that the correct bits are set/cleared of course. :)

The patch below tries to set the proper polarity. The mode still doesn't
work though, since misc_output already is 0xEB by default. I don't know
if the patch is wrong or which additional problems the rivafb driver
might have with the mode.

Any ideas?

Thanks

	Fredrik
--- linux-2.4.21-pre2.old/drivers/video/riva/fbdev.c	2002-08-03 02:39:45.000000000 +0200
+++ linux-2.4.21-pre2.new/drivers/video/riva/fbdev.c	2003-01-19 13:21:46.000000000 +0100
@@ -920,6 +920,15 @@
 	newmode.ext.width = width;
 	newmode.ext.height = height;
 
+	if(video_mode->sync & FB_SYNC_HOR_HIGH_ACT)
+		newmode.misc_output &= ~0x40;
+	else
+		newmode.misc_output |= 0x40;
+	if(video_mode->sync & FB_SYNC_VERT_HIGH_ACT)
+		newmode.misc_output &= ~0x80;
+	else
+		newmode.misc_output |= 0x80;
+	
 	rinfo->riva.CalcStateExt(&rinfo->riva, &newmode.ext, bpp, width,
 				  hDisplaySize, hDisplay, hStart, hEnd,
 				  hTotal, height, vDisplay, vStart, vEnd,



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: [PATCH] rivafb sync polarity problem?

From: Antonino Daplas <hidden>
Date: 2003-01-19 16:35:22

On Sun, 2003-01-19 at 20:55, Fredrik Noring wrote:
Hi,

It seems the mode below doesn't work with rivafb in Linux 2.4.21-pre2,
the RGB (TV) screen fail to sync properly. (The equivalent modeline in
XFree86 4.2 works.)

    mode "768x288"
        geometry   768 288   768 288   32
        timings    62500   120 80   20 2   54 2
                     ^^^^^ 

The dotclock should be in picoseconds.  The above will translate to
roughly 16MHz only.

picoseconds = 1/Hz * 1E12

Tony



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: [PATCH] rivafb sync polarity problem?

From: Fredrik Noring <hidden>
Date: 2003-01-19 16:54:35

sön 2003-01-19 klockan 17.25 skrev Antonino Daplas:
The dotclock should be in picoseconds.  The above will translate to
roughly 16MHz only.
Yep. The corresponding modeline in XFree86 4.2 is:

  Modeline "768x288" 16.0 768 848 902 1022 288 290 292 312 -hsync -vsync

It's a mode designed for regular PAL TV output (through RGB-SCART) and
it works excellent with XFree86 4.2. The corresponding modeline for NTSC
looks like this:

  Modeline "768x240" 16.0 768 848 902 1022 240 243 244 261 -hsync -vsync

Hopefully, rivafb will support interlace some day and then these
modelines will also work:

  ModeLine "768x485" 16.0 768 848 902 1022 485 491 496 525 -hsync -vsync interlace
  ModeLine "768x576" 16.0 768 848 902 1022 576 580 585 625 -hsync -vsync interlace

(PAL and NTSC respectively.)

For some reason, rivafb will not render any of these modes properly a.t.m.

	Fredrik




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: [PATCH] rivafb sync polarity problem?

From: Antonino Daplas <hidden>
Date: 2003-01-19 16:59:59

On Sun, 2003-01-19 at 20:55, Fredrik Noring wrote:
Hi,

It seems the mode below doesn't work with rivafb in Linux 2.4.21-pre2,
the RGB (TV) screen fail to sync properly. (The equivalent modeline in
XFree86 4.2 works.)

    mode "768x288"
        geometry   768 288   768 288   32
        timings    62500   120 80   20 2   54 2
        hsync low
        vsync low
    endmode
Ooops :-)  Sorry, I did not notice you were using 288 for your yres, so
62500 is just right.

How bad is the sync problem?  It's possible that your horizontal timings
is not divisible by 8?  Ie., your hsync_len is 54, but when it's written
to the register, it's just 48.  You might want to recalculate the
numbers so you use 54 or 56.

Tony



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: [PATCH] rivafb sync polarity problem?

From: Fredrik Noring <hidden>
Date: 2003-01-19 17:38:01

How bad is the sync problem?  
Well, I must say it's pretty bad. It's a digital kind of TV - so
either you'll get a stable nice looking image, or you'll get the
blue "no-signal" screen. I get the blue screen.

But there is a strange mode in the TV where I can see the RGB signal
from the computer using the sync from the RF-input. Using this, at
least it seems the frequencies are reasonably correct.
It's possible that your horizontal timings is not divisible by 8?  
Ie., your hsync_len is 54, but when it's written to the register, 
it's just 48.  You might want to recalculate the numbers so you 
use 54 or 56.
I've tried the two variants below but neither work unfortunately.

    mode "768x288"
        geometry   768 288   768 288   32
    #   timings    62500   126 80   20 2   48 2
        timings    62500   118 80   20 2   56 2
        hsync low
        vsync low
    endmode

Thanks,

	Fredrik




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: [PATCH] rivafb sync polarity problem?

From: James Simmons <hidden>
Date: 2003-01-24 19:40:30

The patch below tries to set the proper polarity. The mode still doesn't
work though, since misc_output already is 0xEB by default. I don't know
if the patch is wrong or which additional problems the rivafb driver
might have with the mode.
Applied. I'm about to test these new patches.




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help