Xv / XVideo accelerated video width is limited by / depending on the screen resolution on S3 Savage, but only if the laptop LCD is the primary screen
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xserver-xorg-video-savage (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Binary package hint: xserver-
This bug exists at least since 10.04 lucid, maybe earlier (have not tested it before).
I am using the S3 savage driver for a S3 Savage/MX card on an HP XE3-GC laptop. When playing videos (no matter which player as long as the Xv acceleration is used), I encounter the following problem: whenever the LCD is the primary screen (with its hardware resolution of 1024x768), the video "input" width processed by Xv is limited by the ratio of the actual resolution divided by the LCD hardware width (1024). If I set the resolution to 800x600 for example (to be able to use the TV output in full screen mode), I only can see 800/1024 = 0,78 of the real video width, no matter if the video is displayed in a small player window or enlarged to full screen. On the right of the video display, the remaining width is filled with a black (or sometimes blue) bar. Using s3switch to change the output to TV keeps this limitation, which makes watching video on a TV or projector a pain!
If the CRT (external VGA out) is the main display (e.g. by using the laptop in its docking station), I can change the resolution to whatever I want and still have the full video width. Because of distances, however, I could not yet check if the output transition CRT --> TV keeps this full width also for the video output.
In any case, the xvinfo program does not show any limitation - but this limitation should only concern the OUTPUT resolution anyway, not the "source" width of the video being processed.
description: | updated |
description: | updated |
tags: | added: patch |
affects: | xserver-xorg-video-s3 (Ubuntu) → xserver-xorg-video-savage (Ubuntu) |
Hello,
now I resolved the problem myself on source code level. The relevant parts are two sections in savage_video.c and savage_streams.c, where scaling factors explicitly for LCD usage are calculated. The problem was mainly that only the drawing starting point was modified by the scaling factor, but not the size-defining end of the drawing rectangle. Additionally I had to remove a 7-pixel offset which seems had been added for a very specific case I could not reproduce.
See the appropriate patch files attached to this comment. They resolve this issue completely and are tested on all available resolutions on my HP XE3-GC machines with Savage/MX 8MB, max. hardware LCD resolution 1024x768.