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.
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.97KHz v: height 1080 start 1084 end 1089 total 1125 clock 23.98Hz It actually looks like the 23.98 fps mode was rounded to 24fps before and never 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 cause 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 [details] [review] Possible fix.
(In reply to comment #2) > 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. No problem at all. It's still quite likely that my patch is the source of the 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 and 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 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. Let me know if you need any help. > It might be that my LCD does not like 23.98? Thanks. 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 produce 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 xrandr.
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.
(In reply to comment #17) > 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. Garrett, please stop trying to merge the patches. Since the initial change is already upsteram we are going to need to fix it in a separate patch anyway. > > 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 My fix limited the reference divider so that "post_div * ref_div <= 100". Could you try to raise the 100 to see at which point your TV says the signal isn't valid any more? With a limit of 500 you should be at the same point as before, so I suggest to try values of 200, 300, 400 first. Then if 200 works but 300 doesn't (for example) try 250, and so on...
Created attachment 97043 [details] 368 and others dmesg >Garrett, please stop trying to merge the patches. Since the initial change is >already upsteram we are going to need to fix it in a separate patch anyway. Sorry. New to this FOSS stuff. OE is a complete OS download with local code not pulling from mainline kernels (from what I can tell). It was tricky for me to patch it. I am trying to be transparent so others can reproduce my results easily. >My fix limited the reference divider so that "post_div * ref_div <= 100". Could >you try to raise the 100 to see at which point your TV says the signal isn't >valid any more? >With a limit of 500 you should be at the same point as before, so I suggest to >try values of 200, 300, 400 first. Then if 200 works but 300 doesn't (for >example) try 250, and so on... Thanks for the tips. OK- I built many. 368 is the closest I got. I have to head to the office. I uploaded all dmesg, tests. What I don't understand is the pll numbers go up and down, despite having the higher max vals. This concerns me.. Hope it helps. I assume you do not want to run all pc's at max. Else tolerances at the hardware/silica/chipset level may result in similar results to my sys. But at least now I can tune my sys. :) 368 is much higher than 100. LMK if you need more. TIA.
Christian, I managed to add only your patch solo: https://bugs.freedesktop.org/attachment.cgi?id=96900&action=edit It works great. The mistake I made was ctrl-c/v from browser. Bad chars I assume. White-space chrs? I am trying to understand the plls. I read the org. bug report 76564. I assumed increasing the max would allow higher pll vals. But it does go down with some. Does that make sense? from this patch applied to v2: [ 38.548302] [drm:drm_mode_debug_printmodeline], Modeline 32:"" 0 74176 1920 2558 2602 2750 1080 1084 1089 1125 0x0 0x5 38.568903] [drm:radeon_compute_pll_avivo], 148340 - 14830, pll dividers - fb: 148.3 ref: 10, post 10 [ 38.581485] [drm:drm_crtc_helper_set_mode], [ENCODER:17:TMDS-17] set [MODE:32:] [ 38.581490] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 00000008, active_devices 00000008 Is this correct? from Modeline 32: 74176 * 2 = 148352 (LCD wants?) ~= 148300 (GPU makes?). Ideally we need 148350 (GPU)? Your patch does wonders for this A4-3400. I am trying to understand it better. Here your max is 100. ref: 10, post 10 >>>> 10 * 10 = 100 max.
(In reply to comment #21) > Created attachment 97043 [details] > 368 and others dmesg > > >Garrett, please stop trying to merge the patches. Since the initial change is >already upsteram we are going to need to fix it in a separate patch anyway. > > Sorry. New to this FOSS stuff. OE is a complete OS download with local > code not pulling from mainline kernels (from what I can tell). It was > tricky for me to patch it. I am trying to be transparent so others can > reproduce my results easily. No problem at all and keeping it reproducible is indeed a good intention. I just wanted to avoid that you spend time on unnecessary stuff. > What I don't understand is the pll numbers go > up and down, despite having the higher max vals. This concerns me.. Well that is simple to explain. Assum that you have a feedback to ref divider ratio of 100/11. This ratio can't be reduced any more without lossing precission. Now we also assume to the ref divider maximum is 10, so after limiting the ref divider to 10 we end up with a ratio of 90/10. Now 90 to 10 can be reduced easily to 9/1. So in the end we end up with a far lower ration because of the reference divider limit. > Hope it helps. Yeah, your numbers indeed helped a bit, thanks.
(In reply to comment #22) > I am trying to understand the plls. Well how deep are you interested in getting into this? PLLs can be complicated, but are also one of the very basic building blocks of electronics. > I read the org. bug report 76564. I > assumed increasing the max would allow higher pll vals. But it does go down > with some. Does that make sense? More or less yes. See your numbers for example, without the limit patch you had the params like this: 148340 - 14834, pll dividers - fb: 741.7 ref: 50, post 10 This means with a feedback divider of 741.7, a referenz divider of 50 and a post divider of 10 you have an exact match for the frequency. There is just the little problem that as the divider numbers get higher the signal gets more unstable. So in reality you don't get 148.340 MHz, but instead something that fluctuates between 148.339 MHz and 148.341 MHz (for example). The overall match for the average frequency is still better than with lower numbers, but your TV/Monitor can't deal with such high fluctuations in it. > Your patch does wonders for this A4-3400. I am trying to understand it > better. > > Here your max is 100. ref: 10, post 10 >>>> 10 * 10 = 100 max. Yes correct.
(In reply to comment #0) i seem to be facing the issue described here: software setup is openelec r18117 using the GPU integrated inside my A8-3870K the video play fine, TV reports 24p, xbmc-xrandr reports 23,976 http://sprunge.us/cGOc http://sprunge.us/VMjU same setup but with GPU integrated in the APU disabled and using a discrete HD6450, TV shows no signal http://sprunge.us/JBgc http://sprunge.us/UXMV
Both your logs are of April 1st, so don't contain the possible fix. The fix (to keep the divs low) was commited two days ago into OpenELEC git. Since then no official builds have been made. Furthermore the logs are useless without drm.debug=0xe I think you got your builds from xbmcnightly.com and they did not do full rebuilds.
(In reply to comment #24) > (In reply to comment #22) > > I am trying to understand the plls. > > Well how deep are you interested in getting into this? PLLs can be > complicated, but are also one of the very basic building blocks of > electronics. > No need to dig too deep. I work with embedded firmware. PLL clocks/timing are fine (I understand basics). In reference to video this is new stuff. I sincerely appreciate your time educating me. > > I read the org. bug report 76564. I > > assumed increasing the max would allow higher pll vals. But it does go down > > with some. Does that make sense? > > More or less yes. See your numbers for example, without the limit patch you > had the params like this: > > 148340 - 14834, pll dividers - fb: 741.7 ref: 50, post 10 > > This means with a feedback divider of 741.7, a referenz divider of 50 and a > post divider of 10 you have an exact match for the frequency. > > There is just the little problem that as the divider numbers get higher the > signal gets more unstable. So in reality you don't get 148.340 MHz, but > instead something that fluctuates between 148.339 MHz and 148.341 MHz (for > example). "the signal gets more unstable" So it is the gpu that varies its freq. at higher divs (multipliers) and my set is not tolerant of signal freq. fluctuations to keep data in sync? If I understand this correctly- This is like in a micro-controller where deviations in baud rate (a pll generated clock) leads to serial transmission errors when > 5% deviation, for example. In micro-controllers: high multipliers * internal pll = less stable freq >> less stable baud rate. > > The overall match for the average frequency is still better than with lower > numbers, but your TV/Monitor can't deal with such high fluctuations in it. > > > Your patch does wonders for this A4-3400. I am trying to understand it > > better. > > > > Here your max is 100. ref: 10, post 10 >>>> 10 * 10 = 100 max. > > Yes correct. Thanks for explaining this so clearly. Garrett
(In reply to comment #27) > "the signal gets more unstable" > > So it is the gpu that varies its freq. at higher divs (multipliers) and my > set is not tolerant of signal freq. fluctuations to keep data in sync? Yes. > If I understand this correctly- This is like in a micro-controller where > deviations in baud rate (a pll generated clock) leads to serial transmission > errors when > 5% deviation, for example. In micro-controllers: high > multipliers * internal pll = less stable freq >> less stable baud rate. Yes that's exactly the same problem just a completely different use case. Depending on the details of their electrical implementation all PLLs behave more or less like this. The trick is to know how to find the right numbers without violating the contrains.
(In reply to comment #28) > Depending on the details of their electrical implementation all PLLs behave > more or less like this. The trick is to know how to find the right numbers > without violating the contrains. yup.. This is a fun one to deal with in the embedded environment (love that scope.). I consider this bug fixed. I am not sure if I am supposed to mark it ok or something. Else I will leave it. I thought about the pll thing. I don't know the HDMI message layer at all. I am not sure it is public knowledge anyhow. To get higher divs, I was thinking a potential algo could go (MUCH easier said than done, I know): 1) Run a setup program each time a hardware change is detected. (EDID or GPU) 2) Test LCD/Panel at various popular refresh rates. a) crank up the pll with your new algo. >> *test* if tv accepted it. (requires a knowledge of protocol to check display state, or have user answer ok with a timeout in case it is not readable) >> save the new div setting (maybe the 10% lower ones to be safe) to a config with a table for that hardware/refresh. 3) on reboot load new optimized saved PLL dividers from the table. And on each refresh rate change use the table. But that said. It does not really matter for me to make it closer. Your new algo with your "arbitrary" 100 limit works well on my hardware. I tested 368 and it looked great, too. 368 vs 100 on 24P made vary little difference too me.
(In reply to comment #29) > (In reply to comment #28) > 1) Run a setup program each time a hardware change is detected. (EDID or GPU) > 2) Test LCD/Panel at various popular refresh rates. > a) crank up the pll with your new algo. > >> *test* if tv accepted it. (requires a knowledge of protocol to > check display state, or have user answer ok with a timeout in case it is not > readable) Well, that's way to much user interaction for this topic cause there is no way to ask a TV if the picture looks ok other than asking the user. I'm going to supmit the patch to drm-fixes (with a bit higher limit) so it should end up in 3.15 together with the patch that created the problem in the first place.
(In reply to comment #26) > Both your logs are of April 1st, so don't contain the possible fix. > > The fix (to keep the divs low) was commited two days ago into OpenELEC git. > Since then no official builds have been made. > > Furthermore the logs are useless without drm.debug=0xe > > I think you got your builds from xbmcnightly.com and they did not do full > rebuilds. thanks for your answer and please forgive me for providing improper logs. i'm using Openelec 4.0 final right now and the issue appear to be somewhat different. using the HD6450 i now get video signal but i get severe jerkiness with any 23.98 content. xbmc-xrandr reports 23.97608 but the video stutters heavily at what appears to be regular times. exactly the same thing used to happen with the SUMO GPU integrated inside the A8-3870K APU. as of OpenELEC r18022 any 23.98 content played on the SUMO GPU resulted in exactly the same stutters while xbmc-xradr still report 23.97608. r18117 fixed the stutters on the APU and video played perfectly smooth. right now Openelec r18022 is the last version out of the ones i tested that gives me perfectly smooth 23.98 content playback on the HD6450. using Openelec 4.0 final on the integrated SUMO GPU inside the A8-3870k result in perfectly smooth video playback of the same files white xbmc-xrandr report 23.97608. basically between Openelec r18022 and 4.0 final i get exactly the opposite behavior between the HD6450 and the SUMO GPU. i'll try to provide (hopefully useful) logs (if you could point me in the right direction in this regard it will be much appreciated) in the near future if you think what i tried to explain above makes any sense. thanks
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.