[mythtv-users] Vertical scaling in HD shows

[DaveD]

Michael T. Dean wrote:
> On 03/30/2008 01:19 AM, DaveD wrote:
>   
>> Video aspect override: Off
>> Zoom: Off
>> Video Playback Profile: Normal
>> Vertical and Horizontal scaling: 0
>> Scan displacement (X and Y): 0
>> Video Aspect Override: Off
>>
>> In Appearance->Screen Settings I have tried setting Monitor Aspect Ratio 
>> to 16:10 and 16:9
>>     
>
> Try setting "Xinerama screen" to "All" and the other values there, with 
> "Monitor Aspect Ratio" set to "16:10".
>   
No change.  Myth still fills the screen vertically.  Thought I might 
include this from the mythfrontend output:
2008-03-30 19:06:42.112 Total desktop dim: 1920x1200, with 1 screen[s].
2008-03-30 19:06:42.113 Connected to database 'mythconverg' at host: 
192.168.0.5
2008-03-30 19:06:42.114 Using all screens (currently 1)
2008-03-30 19:06:42.115 Total width = 1920, height = 1200
>> ... Xine and mplayer work as 
>> expected/desired.  It's as if Myth is trying to be "too smart" for its 
>> own good.
>>     
>> ...should I submit a bug report?
>>     
>
> No.  It's a configuration issue.  We just have to figure out which one.
>
> If the above doesn't get it, what's the output of:  xdpyinfo
>   
468 lines.   I tried to pick some that I thought might be relevant.  Let 
me know if there's something missing that you were referring to.  Is 
Myth using the dpi to try and render accurately while the other players 
just blast bits on the screen?  I noticed a different H/V DPI in 
xdpyinfo's output.

BTW, I should probably mention I'm running version 0.21 on FC7 X86_64 on 
an Athlon 3200+ with the Nvidia legacy drivers and an FX5200.  I might 
also reiterate that SD shows are scaled accurately to fill the screen 
vertically with black bars left and right.  The exact same system used 
to have a 19" CRT monitor  that left appropriate black bars at top and 
bottom of HD shows.  The vertical distortion only showed up when I got 
the new monitor.  When I got it I was running a 0.21 trunk version, 
prior to the 0.21 release version, but I don't remember which one 
(ATRPMS-bleeding trunk).  It had the same problem.  I had hoped it would 
go away with the release of 0.21 but no such luck.

Here's some output from xdpyinfo:

name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    10300000
X.Org version: 1.3.0
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x2600022, revert to PointerRoot
number of extensions:    33
    BIG-REQUESTS
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    GLX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    NV-CONTROL
    NV-GLX
    RANDR
    RECORD
    RENDER
    SECURITY
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XAccessControlExtension
    XC-APPGROUP
    XC-MISC
    XFIXES
    XFree86-Bigfont
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
    XVideo-MotionCompensation
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1920x1200 pixels (524x321 millimeters)
  resolution:    93x95 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0xda
  depth of root window:    24 planes
  ... and on, and on (lot of "visual"s)....

Thanks for your help!

DaveD.