Rv670 Running latest drm-next + ddx - only just tested this case so don't know if it's a regression somewhere or not. Filing as kms as ums doesn't offer a DIN mode > 1024x768, so doesn't have the problem. If I start X with 1280x1024 res the TV s-video DIN also gets a 1280x1024 cloned mode (Although it only actually displays 1280x768). mplayer -fs will softlock - SysRq works but I can find no messages. Doesn't happen if - DIN is turned off. XV_VSYNC is 0 Monitor is 1280x1024 and DIN is 1024x768.
Does it still happen if you force the DIN to a lower res like 1024x768 or 800x600 or something smaller?
(In reply to comment #1) > Does it still happen if you force the DIN to a lower res like 1024x768 or > 800x600 or something smaller? > No, it's OK if DIN is <= 1024x768.
Created attachment 30349 [details] [review] limit default tv modes This patch should take care of it.
(In reply to comment #3) > Created an attachment (id=30349) [details] > limit default tv modes > > This patch should take care of it. > Well it seems to, but because I've been testing this bug without turning the TV on I've only just noticed there has been a separate tv-out regression caused by 5a9bcacc0a56f0d9577494e834519480018a6cc3 Since this commit tv-out is displaying garbage (though it is related to what should be there) This bug is not related to that regression - if I reset to before that commit tv-out works OK and this bug still exists.
Created attachment 30401 [details] [review] fix tv-out this patch should fix tv-out
Created attachment 30402 [details] [review] set active devices early You may need this patch as well.
(In reply to comment #6) Thanks, just been testing with all three patches and tv-out and this bug are fixed. TV with fbcon and X limited to 1024x768 and mplayer -fs is working. One minor thing I noticed, if DIN is turned off in X the fbcon TV is also off on VT switch/quit X. However it is possible to get it to output to TV by doing a VT switch, then VT back to X, after that fbcon outputs to TV again on further VT switches or quitting X. I've also found an xserver issue sort of exposed by this change - it seems that starting X with clones of a different size causes it to segfault after one is disabled and something tries to change gamma. This happens in ums as well.
(In reply to comment #7) > > I've also found an xserver issue sort of exposed by this change - it seems that > starting X with clones of a different size causes it to segfault after one is > disabled and something tries to change gamma. This happens in ums as well. > Can you open a new bug for this and attach the backtrace?
(In reply to comment #8) > Can you open a new bug for this and attach the backtrace? Filed under radeon - http://bugs.freedesktop.org/show_bug.cgi?id=24532
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.