Description of Problem: Have been able to do limited video capture / windows on savage displays. An application such as motv works OK if you specify motv -remote -noscale -c /dev/video0 but fails if either of those two options are omitted. Version-Release number of selected component (if applicable): RedHat 7.2, XFree86-4.1.0-15, kernel-2.4.9-31 RedHat Rawhide, XFree86-4.2.0-6.47, kernel-2.4.18-0.4 How Reproducible: Set up system with savage display card and video for linux compatible video capture card. Our system has three of each, and multihead appears to be part (but not all) of the problem. Steps to Reproduce: 1. motv -c /dev/video0 OR 2. motv -remote -c /dev/video0 OR 3. motv -noscale -c /dev/video0 Actual Results: #1, #3 - video image appears on left display (within window). Moving the window to another screen - video still on left display in same relative position as window is in the other display. Window is black. #2 - video image replaced by a bright blue/green streaked image (within window). Moving the window to another screen - image changes color / streaks slightly but remains within the window as expected. Expected Results: Video image appears properly in all positions on display. Additional Information:
This is quite a highly special setup, so it is not possible for us to be able to reproduce your configuration as hardware is not available. We provide but do not officially support dualhead/Xinerama setups at this point in time. What you are describing, sounds to me like you're seeing the effects of an overlay window being turned on, but not in the foreground. I recommend contacting the Savage driver author directly for this problem, as he will have much more chance of reproducing and/or troubleshooting this setup, and possibly finding a fix if there is indeed a bug occuring here. I will leave this bug here, and update it when new drivers become available upstream for testing. Also, if you can reproduce this problem with a much simpler setup of some kind, it could help a lot as well.
Any change on this since reporting? Tim Roberts <timr> is the driver maintainer if you'd like to contact him directly, which is the fastest path to a resolution if the problem persists.
Closing bug report due to inactivity.