Menu
▾
▴
linux-fbdev-devel
|
From: Fredrik N. <no...@no...> - 2003-01-19 12:55:17
|
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,
|
|
From: Antonino D. <ad...@po...> - 2003-01-19 16:35:23
|
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
|
|
From: Fredrik N. <no...@no...> - 2003-01-19 16:55:07
|
s=F6n 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 in= terlace ModeLine "768x576" 16.0 768 848 902 1022 576 580 585 625 -hsync -vsync in= terlace (PAL and NTSC respectively.) For some reason, rivafb will not render any of these modes properly a.t.m. Fredrik |
|
From: Antonino D. <ad...@po...> - 2003-01-19 17:00:00
|
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 |
|
From: Fredrik N. <no...@no...> - 2003-01-19 17:38:33
|
> 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
|
|
From: James S. <jsi...@in...> - 2003-01-24 19:41:02
|
> 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. |
Thanks for helping keep SourceForge clean.
X