| Priority | medium |
|---|---|
| Bug ID | 77009 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | 24P playback video signal loss with latest DRI patches |
| Severity | normal |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | socalfisher@gmail.com |
| Hardware | x86-64 (AMD64) |
| Status | NEW |
| Version | unspecified |
| Component | DRM/Radeon |
| Product | DRI |
Created attachment 96854 [details] xrandr verbose and dmesg +/- problem This patch [https://bugs.freedesktop.org/show_bug.cgi?id=76564] appears to have broken my 24P playback which has been fine until now. My set is a Sony KDL 40NX711 NTSC set, PC A4-3400 - HDMI to set for vid/audio stereo out speakers. Using Openelec- gotham nightlies (this patch is now comitted to OE-nightlies): Playing 29.97i/59.94 plays fine enough (a few skips- why I am testing this patch), 23.976 playback breaks the TV display- it starts to buzz then says "no signal", I press stop and the menu/screen resumes at ~30P like normal. "xrandr --output HDMI-0 --mode 1920x1080 --rate 23.98" - does the same thing, lcd loses video signal and buzzes. I am attaching the dmesg/xrandr --verbose logs w/ drm.debug=0xe both working w/o patch and broken w/patch.
| What | Removed | Added |
|---|---|---|
| Attachment #96854 mime type | text/plain | application/binary |
| What | Removed | Added |
|---|---|---|
| CC | deathsimple@vodafone.de |
Good:
1920x1080 (0x59) 74.2MHz +HSync +VSync
h: width 1920 start 2558 end 2602 total 2750 skew 0 clock 27.=
0KHz
v: height 1080 start 1084 end 1089 total 1125 clock 24.=
0Hz
Bad:
1920x1080 (0x59) 74.176MHz +HSync +VSync
h: width 1920 start 2558 end 2602 total 2750 skew 0 clock 26.9=
7KHz
v: height 1080 start 1084 end 1089 total 1125 clock 23.9=
8Hz
It actually looks like the 23.98 fps mode was rounded to 24fps before and n=
ever
really worked correctly.
Are you sure my patch is the only difference in the system? Cause my patch
shouldn't have that effect.
Can you build a kernel separately and check that this is really the root ca=
use
of it?
Thanks in advance,
Christian.
Hi Christian. Thanks for your help. They are not 100% the same. I hope that I am not misleading you. My, aplogies in advance, if it works out to be so. xorg3.15, Kernel 3.13.7 vs. 3.14 Precompiled Openelec builds: working: xorg 3.15, Kernel 3.13.7, no patch http://xbmcnightlybuilds.com/openelec-generic-x86_64-r18022-g4473271-download/ Not working: xorg 3.15, Kernel 3.14, patch http://saraev.ca/OpenELEC-Generic.x86_64-devel-20140330151700-r18049-g02739c3.tar Tonight I will make a new build environment to test PURELY the patch/un-patch. I am a bit new to building kernel Dri/Drm modules. But I should be able to figure it out. HUMM: clock 24.0Hz good clock 23.98Hz bad It might be that my LCD does not like 23.98? Thanks. I will post back with the results.
Created attachment 96900 [d= etails] [review] Possible fix.
(In reply to comment #2= ) > Hi Christian. Thanks for your help. They are no= t 100% the same. I hope > that I am not misleading you. My, aplogies in advance, if it works ou= t to > be so. No problem at all. It's still quite likely that my patch is the source of t= he problem. > xorg3.15, Kernel 3.13.7 vs. 3.14 We should just make sure that it is indeed the only change in the system an= d we don't have an issue like two patches affecting each other or something like that. Beeing based on kernel 3.13.7 vs. 3.14 for the two versions sounds like we should make that sure first. > Tonight I will make a new build environment to t= est PURELY the > patch/un-patch. I am a bit new to building kernel Dri/Drm modules. B= ut I > should be able to figure it out. Let me know if you need any help. > It might be that my LCD does not like 23.98? Th= anks. I will post back with > the results. Might be, but I would rather guess that the PLL isn't stable enough any more with my changes. When the values get higher you usually get better matching results, but the electrical signal also gets more unstable. Your LCD is probably just a bit picky what signal it gets as input. I've attached a patch that artifically limits the dividers and so might pro= duce better results. Please try it and report back if that changes anything.
Thanks for the patch. As of this am, I now have local Openelec 4.0 code that builds now and is affected. Building it took overnight on an i5- full OS/OE/XMBC/Kernel... It will take some build time, so over this weekend I will try to collect all of the data. +/- patches.
Hi, I also have issues with OE 3.95.x and Radeon 6320 (AMD E-450). On my device, issues happened with all fractional frequencies (23.9x, 29.9x, 59.9x hz) The test-version which Peter Fruehberger posted and which contains your preliminary patch changed the behaviour. With that new patch fractionalmodes (23.976, ... , ... ) are now working fine, but with 25hz I have a problem. (Peter supposes that it's actually 50i and I believe this too, but I'm just a user and I can only report the frequency that I select in the XBMC-settings) When I set the rate to 25Hz, the picture begins to shiver up and down a few millimeters. When I don't acknowledge the new rate, XBMC switches back to the old rate, and the picture is immediately stable as ever. This effect used to happen with all fractional rates in OE 3.95.x, while 25Hz worked fine. With the mentioned test-version it is gone on the fractional rates, but now it happens on 25Hz (or 50i, as Peter says). As instructed, I booted OE with the kernel-parameter drm.debug=0xe and took dmesg and Xorg.0.log immediately after switching to 25hz and falling back. This is my first post on this site, I hope I don't mess it ;)
Created attachment 96914 [details]
dmesg after switching to 25hz and back to 24hz
Created attachment 96915 [details]
Xorg.0.log after switching to 25hz and back to 24hz
(In reply to comment #7= ) > Created attachment 96914 [details] > dmesg after switching to 25hz and back to 24hz Those logs doesn't contain a mode switch, are you sure you actually grabed = the right log? Please also try changing the mode directly from the command line with xrand= r.
Created attachment 96962 [details]
xrandr 1920x1080x23.98 working 76564 removed
OK. I finally got the patch removed and rebuilt (thanks to Peter's tips).
Xrandr 23.98 now works as expected. No blank screen:
[ 99.956862] [drm:radeon_compute_pll_avivo], 14818, pll dividers - fb: 32.6
ref: 2, post 11
With the patch "linux-996-drm-radeon-rework-finding-display-PLL-numbers.patch"
it failed. I will upload this patch, that I removed from the source folder. I
tried the 3 line patch x2, when it was present but I am not sure it took (built
to fast to see on the screen). So I will add the 3 changes to non-working
patch and rebuild, next. and dmesg it for pll vals.
Created attachment 96963 [details]
patch that breaks by 23.98 playback
file removed -> built then ok.
Created attachment 96966 [details]
fixed with patch dmesg
It works really great, now. No 23.976 skips, no blank screen any more. Also
29.97ix1080 has 50% less skips (there were few anyhow)! So the patch is an
improvement (vdpau 1080i deinterlacing has some skips that I have been trying
to kill). It is really hard/impossible to see any more.
Thanks so much. Garrett
[ 122.397869] [drm:radeon_compute_pll_avivo], 148340 - 14830, pll dividers -
fb: 148.3 ref: 10, post 10
I will try this new OE build on my new Zotac AQ01. It was skippy on 23.976
before.
Created attachment 96968 [details]
the combined full patch needed to fix it
This final patch works well on my system.
I added your "max patch" to the original 76564 patch, OE kept skipping it on
build if 2 patches for that file existed..
Editing patches/diff files is tricky stuff (fixing @@ hunk counters really had
me for a bit there).
Let me know if you need anything else.
I have enclosed a new Xorg.0.log and dmesg - their timestamp on the system matches the time when I changed the rate in xbmc. When it comes to changing on the command-line, I am not sure if I do this correctly - is xrandr -s 1920x1080 -r 25 correct? If I try this in putty, I see a black screen for a moment, then xbmc reappears and asks me if I want to keep the changed rate. The output from xrandr for 1920x1080 is as follows: HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 160mm x 90mm 1920x1080 60.00 + 50.00 59.94 30.00 25.00 24.00* 29.97 23.98 Garrett wrote that he managed to include both your fixes in his build. I'm not that big into modifying the source, but I saw that fritsch has just included radeon-fixes into the current master of OE, and I am just building from scratch. I will report when the build is finished and I had the possibility to test. Regards, Detlev
Created attachment 97003 [details]
dmesg after switching to 25hz and back to 24hz, 2nd attempt
Created attachment 97004 [details]
Xorg.0.log after switching to 25hz and back to 24hz, 2nd attempt
Created attachment 97006 [details]
v3 patch merged with this max patch dmesg
I realized that the last patch I uploaded was v2 modded. Here is dmesg with
the newer v3 patch and this max patch (merged/applied as one patch). It works
fine thus far, no blank screen.
Test condition:
xrandr --output HDMI-0 --mode 1920x1080 --rate 23.98
dmesg > /var/log/dmesg
[ 31.834325] [drm:radeon_compute_pll_avivo] *ERROR* 14830, pll dividers - fb:
148.3 ref: 10, post 10
*ERROR* Uuuu..O but it played fine. I missed that. ? back to v2? I guess.
(In reply to comment #= 15) > Created attachment 97003 [details] > dmesg after switching to 25hz and back to 24hz, 2nd attempt Please take a look at the logs before you upload them. This log again only contains unrelated page flip messages. Not sure what's going wrong here, but without a mode set in the log I can't really help here.
| What | Removed | Added |
|---|---|---|
| Attachment #97003 is obsolete | 1 |