From owner-freebsd-multimedia Fri Jan 30 17:39:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17660 for freebsd-multimedia-outgoing; Fri, 30 Jan 1998 17:39:08 -0800 (PST) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17654 for ; Fri, 30 Jan 1998 17:39:06 -0800 (PST) (envelope-from dwhite@gdi.uoregon.edu) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.7/8.8.8) with SMTP id RAA03034; Fri, 30 Jan 1998 17:39:04 -0800 (PST) (envelope-from dwhite@gdi.uoregon.edu) Date: Fri, 30 Jan 1998 17:39:04 -0800 (PST) From: Doug White Reply-To: Doug White To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: fxtv & XFree3.3.1 = bad vidmodes In-Reply-To: <19980130072541.26179@ct.picker.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-multimedia" On Fri, 30 Jan 1998, Randall Hopper wrote: > |Are these known problems with newer XFrees, or do I need an upgrade? > > Well, this may be an XFree bug with the VidMode extension in the ATI Mach64 > server. It could also be something haveing to do with KDE > ignoring/overriding a client request for setting its window geometry which > is resulting in the video window being moved from where fxtv told it to go. > > To test, position the window somewhere on your desktop where it's got room > to expand to full size (640x480) without bumping into the edges of your > desktop. Zoom the window. The upper-left corner of the fxtv window should > not have moved relative to the other clients on your desktop. If it has, > this sounds like a KDE/Window Manager issue. If not, this sounds it might > be an XFree86 Mach64 server VidMode extension bug. A quick check shows that the window isn't moving. What's funny is that the same thing happened under fvwm, so I wonder if the X server isn't relaying the position component of the geometry change. The video mode change and the window resize are going through. > If it looks like an XFree bug, if you want to play with the code this for a > minute and narrow down who the culpit is (so hopefully we can get a bug > report filed with the appropriate folks), all the magic for > zooming/unzooming is in tvscreen.c::TVSCREENSetZoomState. It's small and > pretty easy to follow. Hm, okay, I think I can follow you here. > One other quick thing to try. If you look at > tvscreen.c::STVSCREENSwitchToMode (which is a wrapper around the mode > switch calls), you'll see that it has to different ways to support > switching between video modes. If version >= 0.8, it switching straight to > the mode. If < 0.8, it cycles through the modes in between > one-step-at-a-time until it gets to the right one. Try alternatively > changing the condition of this if to "0" and "1" (to try both methods) and > see if that makes any difference. I'll try widdling that if(). > |fxtv 0.45 > > I don't remember if anything was put into 0.46 that might help you, but you > might just try it. The port is an easy build: http://multiverse.com/~rhh/fxtv I'll try rebuilding fxtv first. Thanks for the help! Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major