On older versions and current 6.12-branch of xf86-video-ati one can set the position and at least the horizontal size of the tv-out using xrandr: ---8<--------- xrandr --output S-Video --set tv_horizontal_size <-5..5> xrandr --output S-video --set tv_vertical_position <-5..5> xrandr --output S-video --set tv_horizontal_position <-5..5> --->8--------- whereas this functionality is not (yet?) available on current master.
Reassigning to the driver.
master is the same as 6.12.x when using UMS. KMS is missing these attributes.
(In reply to comment #2) > master is the same as 6.12.x when using UMS. KMS is missing these attributes. Hi, I was wondering if there was any progress on this? I recently installed XUbuntu 11.10 on an another (old) laptop with a radeon-9700-mobility ("ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP)" (ChipID = 0x4e50)), but these options still appear to be missing? Also it seems that the only available output resolution is 800x600, and adding a modeline does not work the way one would expect: for smaller resolutions (e.g. 640x480) you get a 'sub picture' in the top-left corner, with garbage to the right and bottom. The contents are displayed in the sub-picture, the rest of the screen does not update. For larger resolutions (e.g. 1024x768) the image appears cropped. xrandr --props reports: ---8<--------- S-video connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm tv standard: ntsc supported: ntsc pal pal-m pal-60 ntsc-j scart-pal pal-cn secam load detection: 1 (0x00000001) range: (0,1) 800x600 59.9 + --->8--------- Driver version is compiled for 1.10.2.902, module version = 6.14.99 Xorg version is X.Org X Server 1.10.4
No one has added the options to KMS yet. Also, the driver currently only supports 800x600 for TV out on those asics. Forcing other modes won't work.
Airlied kindly took a moment to craft a patch (airlied/scratch/0001-drm-radeon-kms-implement-legacy-tv-properties-for-ho.patch) which I've now tested. I've applied the patch to both kernel 3.2.5 and 3.2.9 (there were some warnings about hunk/offsets in both cases), with identical results: The controls show up in the output of 'xrandr --props': ---8<--------- S-video connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm tv vertical position: 0 (0x00000000) range: (-5,5) tv horizontal position: 5 (0x00000005) range: (-5,5) tv horizontal size: 0 (0x00000000) range: (-5,5) tv standard: pal supported: ntsc pal pal-m pal-60 ntsc-j scart-pal pal-cn secam load detection: 1 (0x00000001) range: (0,1) 800x600 59.9*+ --->8--------- However they do not (yet?) appear (fully) functional. That is although it is possible to modify the values (and see these modifications show up in the output, as evidenced by the 'tv horizontal position' in the about snippet of output having value '5'), they don't appear to have any real effect on the output as of yet. Even though the output on the television does briefly 'blink' as if something was changed, the image stays in the same position on screen. I've tried to debug this a little bit, and it seems to me as if radeon_connector_set_property does not get called for these properties. I can see it get called for 'tv standard', but not for 'tv horizontal position'. I have not (yet) been able to identify what might cause this.
Created attachment 58286 [details] [review] initial patch for reference
Created attachment 58288 [details] [review] second attempt at patch second attempt.
Created attachment 58290 [details] [review] v3 maybe
These properties should also only be exposed on pre-avivo hardware as there is no implementation for avivo+ hw.
Created attachment 58291 [details] [review] v4 adjust values back
Created attachment 58292 [details] [review] v5: more control
(In reply to comment #11) > Created attachment 58292 [details] [review] [review] > v5: more control Ok, I finally got around to doing a quick test: - The increased accuracy for horizontal positioning seems to be working great - The vertical position and horizontal size still use the 'steps of 10', it would be great if these could be positioned more accurately too. - There seems to be some discrepancy between NTSC and PAL modes (I only tested these two): the horizontal position adjust in the PAL case wasn't able to shift the image as far left as in the NTSC case. In fact setting the value to '0' (lowest value) it was still too far to the right. - The same seemed true for the vertical size too (cannot move up the image far enough) - The horizontal size control is ineffective/not working. - Is it possible to have a vertical size control too? Final remarks: It's a bit unintuitive to have 50 as a center, as you have to do remember to subtract or add the desired offset from 50. If there is a way to make the negative values work that would also be nice. Also everytime xrandr is invoked the image on the TV set 'flickers', as if the tv needs to re-adjust to the signal or something, even if nothing was changed (e.g. invalid parameter, etc). Would it possible to a) not take an action/reinit tvout if nothing changed b) reduce the amount of 'flicker' even when something does change? Perhaps waiting for vblank or something? (I'm just throwing some ideas).
(In reply to comment #12) > (In reply to comment #11) > > Created attachment 58292 [details] [review] [review] [review] > > v5: more control > > Ok, I finally got around to doing a quick test: > > - The increased accuracy for horizontal positioning seems to be working great > - The vertical position and horizontal size still use the 'steps of 10', it > would be great if these could be positioned more accurately too. > - There seems to be some discrepancy between NTSC and PAL modes (I only tested > these two): the horizontal position adjust in the PAL case wasn't able to shift > the image as far left as in the NTSC case. In fact setting the value to '0' > (lowest value) it was still too far to the right. > - The same seemed true for the vertical size too (cannot move up the image far > enough) > - The horizontal size control is ineffective/not working. > - Is it possible to have a vertical size control too? > > Final remarks: It's a bit unintuitive to have 50 as a center, as you have to do > remember to subtract or add the desired offset from 50. If there is a way to > make the negative values work that would also be nice. > Also everytime xrandr is invoked the image on the TV set 'flickers', as if the > tv needs to re-adjust to the signal or something, even if nothing was changed > (e.g. invalid parameter, etc). > Would it possible to > a) not take an action/reinit tvout if nothing changed > b) reduce the amount of 'flicker' even when something does change? Perhaps > waiting for vblank or something? (I'm just throwing some ideas). I was playing with this some more and I discovered the following things: Actually it is possible to make the 'tv horizontal size' work, for this it is required to reset the tv-standard after you specify a new size (assuming the standard is currently set to 'ntsc'): ---8<--------- xrandr --output S-video --set 'tv horizontal size' 0 # nothing seems to happen xrandr --output S-video --set 'tv standard' ntsc # at this point the horizontal size changes. --->8--------- Switching between tv standards probably also works. Here the value '0' appears to be the 'smallest' size, and '10' the largest. There does not appear to be much scaling applied to the actual signal, this seems to mostly control much of how much of the videobuffer is output to the screen. That is: - set h-size to 0 (minimum value) - position the image such that the start of the image is flush with the left of the screen. For me this is a value of '35' - set h-size to 10 (maximum value) - Result: the image moves slightly to the right (~10 hpos units (in patch v5), now a hpos value of 25 positions the image correctly), and a significantl portion of the desktop is now off-screen to the right. However with both hsize=0 and hsize=10 there is a portion of the desktop which is off-screen to the right. Also with the (for my tv correct) hpos setting of 35 and 25 (depending on hsize=0 or 10), the signal appears to go off the tv-screen to the right. With hsize=0 and hpos<=15 I can see the right edge of the signal, but even then still a portion of the desktop is not visible. With hsize=10 no setting of hpos allows to see the right edge of the signal. Similarly to the signal seemingly not containing the full desktop in the horizontal direction, also a tiny portion is missing in the vertical direction (but this is just a few pixels). This can be observed by setting 'tv vertical position' to 0. In this case the image on screen ends well before reaching the bottom of the tv, but still the last few pixels are not visible. Also initially I remarked that it was not possible to move the image up far enough in PAL mode. However also in NTSC mode this might be the case: In ntsc: - vpos = 0: sets the image flush with the top of the tv screen, there is plenty of room on the screen below the image. - vpos = 10: moves the image down, and it is now (almost) exactly flush with the bottom of the tv set. there is plenty or room on the screen above the image. In pal: - vpos = 0: the image is almost at the top of the tv screen (slightly futher down compared to NTSC). However the bottom of the image is already at the bottom of the screen (at the same position as where the bottom of the image was with mode=ntsc, vpos=10). - vpos = 10: the image moves down the same amount as it did in ntsc mode, however at the bottom of the image is now off-screen. I don't know if it is supposed to be possible to move the image off the top of the tv, i.e. to have an offscreen area of the image on the top like with hpos. Finally I also noticed quite a difference in color vibrance and brightness between NTSC and PAL, the latter being much better. I wonder if this is just due to the different signal or not.
Any updates on this? I never received a response to my last comment, and this is still not present in kernel v3.6.0 either.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/105.
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.