From owner-freebsd-multimedia Fri Jan 30 04:26:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA19688 for freebsd-multimedia-outgoing; Fri, 30 Jan 1998 04:26:56 -0800 (PST) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id EAA19683 for ; Fri, 30 Jan 1998 04:26:54 -0800 (PST) (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 30 Jan 1998 7:25:51 -0500 (EST) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA08258; Fri, 30 Jan 98 07:25:50 EST Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id HAA11523; Fri, 30 Jan 1998 07:25:41 -0500 Message-Id: <19980130072541.26179@ct.picker.com> Date: Fri, 30 Jan 1998 07:25:41 -0500 From: Randall Hopper To: Doug White Cc: multimedia@FreeBSD.ORG Subject: Re: fxtv & XFree3.3.1 = bad vidmodes References: <19980129094906.04518@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Doug White on Thu, Jan 29, 1998 at 10:04:37PM -0800 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-multimedia" Doug White: |Randall Hopper: |> on-the-fly video mode switching and viewport setting |> so that full screen video really is "full screen". | |While you're mentioning that particular feature, upgrading to Xfree86 |3.3.1 seems to have broken it on my machine. It was working okay with |3.2. Or was it when I upgraded fxtv..? | |1. When entering fullscreen mode, the window is off-center; I have to |hunt for it. |2. WHen exiting fullscreen mode, the display is scrambled, like the clock |is out of sync. Switching modes and back remedies the problem. | |I didn't change window managers then, but I am on kde now and was on fvwm. | |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. Mode switching and viewporting setting has worked well for me with the S3V server, and the S3 Virge/VX support in the SVGA server in 3.3.1. 3.2A and before had some bugs, but the XFree folks were good about fixing them when I reported them. 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. Just glancing at it you'll see it avoids even using the VidMode extension calls (XF86VidMode...) if the VidMode extension version is < 0.8 (!s->vmode_ext_supported). After that, it stops any running capture. Then for zooming, it figures out where to put the window. It sets the size to max video, and doesn't move the upper-left corner of the window unless the resize would put part of the window off of the desktop. Then it'll shift the window up and to the left. Next it changes the video window geometry (TVSCREENSetVideoWinGeom). And then we do the video mode switching and viewport setting in the if at the bottom. You might put some printfs in and see if the x,y,width,height numbers being passed to XFree look like what you're seeing on-screen. 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. |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 Randall