[ltp] A20p (r128 mobility 3M) XF86 4.1 S/Video -> SCART TV success

[Tod Harter]

Forgive me if I reveal a certain degree of Ignorance about rebuilding X. =
The=20
one or two times I've had a reason to try to do so were miserable failure=
s...=20
Wish me luck on this attempt!

On Tuesday 04 February 2003 06:52 am, Vivek wrote:
> Ok, here are the instructions I slapped together before:
> The patch is against debianised xfree86 4.1, but _should_ apply to
> vanilla 4.1 or 4.2 - if not, send me your r128_driver.c and I'll
> run up a new patch for you.
>
> Incidentally - it could be argued that the BIOS is as much to blame as =
the
> driver: It contains many modelines, but only one dot clock.
>
> Theproblem with the driver is that it _silently_ throws your modes
> away. The patched version tells you which modes are being rejected,
> and lists all the modes it knows about.
>
> #######################################################################=
####
>#
>
> The file you want to patch is
>
>   xc/programs/Xserver/hw/xfree86/drivers/ati/r128_driver.c
>
> ( The patch is against a debianised r128_driver.c but it seems to apply
>   cleanly to a non-debianised r128_driver.c : no conflicts here )
>
> The only file you need to replace after rebuilding is r128_drv.o, which
> should live somewhere like:
>
>   /usr/X11R6/lib/modules/drivers/
>
> Once you have the new r128_drv.o running (restart X completely - depend=
ing
> on your settings, you may have to restart xdm or gdm or whatever, as th=
ey
> may not restart X when you log out - they don't by default).
>
> You MUST be in a sufficiently low res mode, or the TV will just sit the=
re.
> 720x576 works for me.
>
> Next you need atitvout:
>
>    http://www.stud.uni-hamburg.de/users/lennart/projects/atitvout/
>    (I just used the debian package)
>
> Now:
>
>    sudo atitvout -f t
>
> kicks the S/Video output to the tv into life ( I used an S/Video ->
> SCART cable )
>
>    sudo atitvout -f l
>
> kicks the display back to LCD. The laptop is capable of simultaneous
> display.
>
> If you change modes, you MUST reissue the atitvout command to get TV
> output back, changing modes kills the S/Video output.
>
> If you want your video player app to use the screen properly, get
> it to use the Xv or GL extension to get a fullscreen window:
>
>   'xine -V Xv -f -g -p azumanga_daioh.avi' # for example
>            ^^^^^^^^
> otherwise it won't use the right size display.
> ( If you're using Xine, set the config level to the highest level of
>   expertise and choose all the resize_stream options as well. )
>
> I think that's everything.
>
> #######################################################################=
##
> # gory details
> #######################################################################=
##
>
> For the record, below are the modelines the card will _actually_ suppor=
t.
> Any other resolution will be bounced by the driver (XF86 4.1), and in f=
act
> the only data used by the driver are the displayed resolution numbers
> (eg 1400 and 1050) and (with my patch) the dotclock. Without my patch,
> the dotclock you supply is ignored.
>
> NOTE: the first two modes have dc values < 12.5 MHz, and are unusable.
> You _might_ be able to get them going by bumping the dc value higher:
> I have assumed that the laptop wants everything @ 60 Hz because the
> only out-of-the-box mode that worked was 1400x1050, which was at 60Hz.
>
> NOTE: after switching resolutions (xvidtune -next), the display may be
> scrambled: hitting the lid-closed-cutout-switch ( or closing and
> reopening the lid ) fixes this for me.
>
> The relationship between the modeline numbers is as follows:
>
>  "label@refresh" dc hdisp hsstart hsstop htotal vdisp vsstart vsstop vt=
otal
>
>  (dc * 1000000) / (htotal * vtotal) =3D refresh
>  hdisp and vdisp _must_ match an entry in the VBIOS, or your mode will =
be
>  rejected.
>
>  Where dc is in MHz, and refresh is in Hz.
>
> CAVEAT: I am not a video driver hacker or anything, I just found a plac=
e
> in the code where user data was silently discarded, and then an error
> returned based on the new (magic) data, without ever telling anyone why=
=2E
> I _could_ be completely wrong, but it seems to work, and it's not
> black magic or rocket surgery or anything.
>
> (--) R128(0): VBIOS mode: "320x350@60" 10.19 320 368 375 464 350 351 35=
4
> 366 (--) R128(0): VBIOS mode: "320x400@60" 11.58 320 368 375 464 400 40=
1
> 404 416 (--) R128(0): VBIOS mode: "320x400@60" 15.18 320 368 382 608 40=
0
> 400 403 416 (--) R128(0): VBIOS mode: "320x480@60" 18.09 320 368 382 60=
8
> 480 480 483 496 (--) R128(0): VBIOS mode: "400x600@60" 25.43 400 448 46=
2
> 688 600 600 603 616 (--) R128(0): VBIOS mode: "512x384@60" 19.20 512 56=
0
> 574 800 384 384 387 400 (--) R128(0): VBIOS mode: "640x350@60" 20.38 64=
0
> 688 702 928 350 350 353 366 (--) R128(0): VBIOS mode: "640x400@60" 23.1=
6
> 640 688 702 928 400 400 403 416 (--) R128(0): VBIOS mode: "640x475@60"
> 27.34 640 688 702 928 475 475 478 491 (--) R128(0): VBIOS mode:
> "640x480@60" 27.62 640 688 702 928 480 480 483 496 (--) R128(0): VBIOS
> mode: "720x480@60" 30.00 720 768 782 1008 480 480 483 496 (--) R128(0):
> VBIOS mode: "720x576@60" 35.80 720 768 782 1008 576 576 579 592 (--)
> R128(0): VBIOS mode: "800x600@60" 40.21 800 848 862 1088 600 600 603 61=
6
> (--) R128(0): VBIOS mode: "848x480@60" 33.81 848 896 910 1136 480 480 4=
83
> 496 (--) R128(0): VBIOS mode: "1024x768@60" 61.72 1024 1072 1086 1312 7=
68
> 769 772 784 (--) R128(0): VBIOS mode: "1280x1024@60" 97.84 1280 1328 13=
42
> 1568 1024 1025 1028 1040 (--) R128(0): VBIOS mode: "1400x1050@60" 108.0=
0
> 1400 1448 1462 1688 1050 1050 1053 1066

--=20
Tod G. Harter
Giant Electronic Brain