Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Sep 1997 19:08:22 -0700
From:      Amancio Hasty <hasty@rah.star-gate.com>
To:        "Michael G Petry" <petry@DITTO.NetMasters.com>
Cc:        Randall Hopper <rhh@ct.picker.com>, Kenneth Merry <ken@plutotech.com>, multimedia@FreeBSD.ORG
Subject:   Re: Matrox Millenium with 8M and BT848 
Message-ID:  <199709300208.TAA07712@rah.star-gate.com>
In-Reply-To: Your message of "Mon, 29 Sep 1997 21:51:14 EDT." <199709300151.VAA19806@netwolf.NetMasters.Com> 

next in thread | previous in thread | raw e-mail | index | archive | help
I don't have the +256 shift problem with my Matrox Millenium 4MB VRAM
at 1280x1024 24bpps:


I am running XFree86 3.3.1

{hasty} xdpyinfo
name of display:    :0.0
version number:    11.0
vendor string:    The XFree86 Project, Inc
vendor release number:    3310
maximum request size:  4194300 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    2
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 24, bits_per_pixel 24, scanline_pad 32
keycode range:    minimum 8, maximum 134
focus:  window 0x80000e, revert to Parent
number of extensions:    19
    BIG-REQUESTS
    DOUBLE-BUFFER
    DPMS
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RECORD
    SECURITY
    SHAPE
    SYNC
    XC-APPGROUP
    XC-MISC
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
default screen number:    0
number of screens:    1
screen #0:
  dimensions:    1280x1024 pixels (433x347 millimeters)
  resolution:    75x75 dots per inch
  depths (1):    24
  root window id:    0x26
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x23
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store YES, save-unders YES
  largest cursor:    1280x1024
  current input event mask:    0x58003d
    KeyPressMask             ButtonPressMask          ButtonReleaseMask  
    EnterWindowMask          LeaveWindowMask          SubstructureNotifyM
    SubstructureRedirectMask PropertyChangeMask       
  number of visuals:    1
  default visual id:  0x22
  visual:
    visual id:    0x22
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits

I would ask the XFree86 whats up with this problem because if
they have problem like a hardware bug or limitation they 
can correct it based up on the model of the chipset.

	Cheers,
	Amancio



>From The Desk Of "Michael G Petry" :
> 
> >      I gather the video block on the Millenium @ 1280 looks fine (solid,
> > rectangular, correct colors); it just not in the window frame.  It's off to
> > the left.  And only does this in 1280x1024, not 1024x768.
> 
> Yep.  That's it.
> 
> >      A few questions that'll help nail down the problem.  
> > 
> > 1) With the "+ 256" you added, is the video inside the window frame no
> >    matter how high or low the TV window is on your screen (e.g. try
> >    "-geometry +100+0" and "-geometry +100+800" -- do both these look OK?)?
> 
> Both look ok.  I can move the windo around the window and it tracks just fine
.
> 
> > 2) Please add this line after the line you patched:
> > 
> >         printf( "geometry = X %4d, Y %4d, Bpp %d\n", g.x, g.y, Bpp );
> > 
> >    and try "-geometry +0+700".  Does it print something very close to "X 1,
> >    Y 780, Bpp 4" (the location of the video window relative to the root
> >    window)?  
> 
> petry@netwolf[94]$ ./fxtv -geometry +0+700
> geometry = X    5, Y  781, Bpp 4
> 
> > 
> >    For calibration, does -geometry +0+0 give you an Fxtv window in the
> >    upper-left corner of the desktop and print out something very close to
> >    "X 1, Y 80, Bpp 4"?
> 
> petry@netwolf[95]$ ./fxtv -geometry +0+0
> geometry = X    5, Y   81, Bpp 4
> 
> > 3) See if this makes any difference:
> > 
> >     --- xutil.c.ORIG        Mon Sep 29 18:21:43 1997
> >     +++ xutil.c     Mon Sep 29 18:21:51 1997
> >     @@ -735 +735 @@
> >     -    XUTILGetVisualBpp( display, vi, &Bpp, NULL );
> >     +    XUTILGetVisualBpp( display, vi, NULL, &Bpp );
> 
> No difference.
> 
> > DGA pitch is right, or you wouldn't see a solid rectangular video block.
> > Could be that XTranslateCoordinates doesn't work correctly on Milleniums
> > for 1280x1024x24bpp.
> > 
> > BTW, please try this on XFree 3.3.1.  
> 
> XFree86 Version 3.3.1 / X Window System
> (protocol Version 11, revision 0, vendor release 6300)
> Release Date: August 4 1997
> 	.
> 	.
> (--) SVGA: PCI: Matrox MGA 2064W rev 1, Memory @ 0xe0800000, 0xe0000000
> (--) SVGA: Linear framebuffer at 0xE0000000
> (--) SVGA: MMIO registers at 0xE0800000
> 
> > 
> > Hey Amancio.  You've got a Millenium, right?  Do you see this too (or can
> > you run at 1280x1024x24bpp)?
> 
> It feels like there may be a 1024 byte offset from the beginning of the linea
r 
> frame buffer.  When I first go the board and ran in 1600x1200 mode the video 
> was shifted
> both horizontally and vertically (I guess pitch was wrong). I'll try it agai 
> and
> let you know if it gives anything interesting.
> 
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709300208.TAA07712>