Bug 31799 - xrandr transform not supported?
Summary: xrandr transform not supported?
Status: RESOLVED DUPLICATE of bug 80678
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-20 18:17 UTC by Thomas Orgis
Modified: 2016-02-25 09:29 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Thomas Orgis 2010-11-20 18:17:48 UTC
I'm currently testing this on ubuntu maverick, both stock radeon driver and a fresh build from git. The use-case is scaling/transforming the output image for fitting the picture size and keystone of a (dumb) video beamer connected to the VGA output of the computer.
Hardware is a 780G onboard video chip set.

Simple observation: xrandr --transform  (or the simplified xrandr --scale) does not have any effect. There is no obvious error message about this feature not being supported (xrandr complains about too small framebuffer size, but it does so also on a laptop with intel vidoe, where the transformation works fine nonetheless).

xrandr --verbose does show the transformation matrix, but apparently xrandr --transform doesn't change it (always 1,0,0,0,1,0,0,0,1). I am posting this as bug report as I have a really hard time getting information about the state of transformations with the radeon driver -- so if it's not supported at all, it would be documented at least here... and of course, I'd rather see it implemented;-)
Comment 1 Alex Deucher 2010-11-29 11:52:24 UTC
Transforms should work.  Rotation, which uses transforms, works fine.  This might be a bug in exa or the xserver.  With the following patch:

--- a/src/r600_exa.c
+++ b/src/r600_exa.c
@@ -1231,6 +1231,8 @@ static Bool R600PrepareComposite(int op, PicturePtr pSrcPicture,
     shader_config_t vs_conf, ps_conf;
     struct r600_accel_object src_obj, mask_obj, dst_obj;
 
+    return FALSE;
+
     if (pDst->drawable.bitsPerPixel < 8 || pSrc->drawable.bitsPerPixel < 8)
        return FALSE;
 

All transforms will be done by software.  I get the same results with hardware or software.  Unfortunately, I don't have an intel system to compare with.
Comment 2 Thomas Orgis 2010-12-01 12:47:40 UTC
Well then, this is confusing. That change in r600_exa.c does not change anything in the behaviour I observe. Fact is, that

xrandr --output VGA-0 --rotate inverted

does work properly, while

xrandr --output VGA-0 --fb 1024x768 --transform 1.5,0,-280,0,1.5,0,0,0,1

does exactly nothing with the screen configuration. So we have to assume that somehow the Xorg in ubuntu is broken? Can you confirm that such a more elaborate transformation does work on r600? My actual intention was to use this for more fancy matrices like

xrandr --output VGA-0 --fb 1024x768 --transform 1.5,-0.005,-280,0,1.5,0,0,-0.00005,1

...which does scale down and applies keystone correction. Well, this stuff does work with the fglrx driver, though I observed nasty interpolation quality -- it looks better on the intel-powered laptop, by far.

Anyhow: If you can confirm that this is working with your setup, then this bug can be closed, the issue blamed on ubuntu. I will resort now to using the PCI Matrox G450 card for movies and scale down the image via non-fullscreen playback; live with the slight keystone effect and rather enjoy the tear-free video experience that sadly cannot be matched by either radeon driver since the introducton of textured video...
Comment 3 Felix Blanke 2010-12-01 17:21:10 UTC
Hi,

I'm using an evergreen (r700?) card with a 1.9.2 xorg-server and your transformation works for me (well it screws up my screens but thats just because my screens are allready rotated etc.).

If that change from Alex do the transformation in software and even with that change transformation isn't working for you it really seems to be an ubuntu/xorg whatever issue.
Comment 4 Alex Deucher 2010-12-02 23:07:53 UTC
Should be fixed in f074762fff4253a457cb48519bb33a2e2c90f8b9, however, it appears EXA or the xserver does the transform wrong at least on some xservers.
Comment 5 Vitaliy Filippov 2011-09-19 11:09:17 UTC
Hi all!
For me, on Dell 1535 notebook with RV620 (ATI Mobility Radeon HD3450), xrandr scaling does not work on LVDS output. Am I doing something wrong or does it apply to this bug?
xrandr --output LVDS --size 1920x1080 --fbmm 1920x1080 --scale 1.25x1.2 --panning 1920x1080
Changes screen size to 1920x1080, but the picture isn't scaled - only top-left 1440x900 (native res) is displayed. Transform matrix remains (1,1,1) diagonal. No errors.

Also, I can't manage to get scaling working on attached projector (VGA-0) (although this is more probably my fault - can you point to it?). I tried the following command:
xrandr --output VGA-0 --mode 1920x1080 --fbmm 1440x900 --same-as LVDS --scale 0.75x0.8 --output LVDS --size 1440x900 

I just get:
X Error of failed request:  BadMatch (invalid parameter attribute)
  Major opcode of failed request:  149 (RANDR)
  Minor opcode of failed request:  29 (RRSetPanning)
  Serial number of failed request: 32
  Current serial number in output stream: 32
Comment 6 Christopher M. Penalver 2016-02-25 05:19:11 UTC
Thomas Orgis, Ubuntu Maverick reached EOL on April 10, 2012. For more on this, please see https://wiki.ubuntu.com/Releases .

If this is reproducible on a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal:
ubuntu-bug xorg

Also, please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.
Comment 7 Michel Dänzer 2016-02-25 09:29:42 UTC
Actually, I finally fixed this recently, but forgot updating this report.

*** This bug has been marked as a duplicate of bug 80678 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.