https://bugs.freedesktop.org/show_bug.cgi?id=77009
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 --> https://bugs.freedesktop.org/attachment.cgi?id=96854&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #96854|text/plain |application/binary mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=77009
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |deathsimple@vodafone.de
--- Comment #1 from Christian König 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.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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #2 from Garrett socalfisher@gmail.com --- 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-downloa...
Not working: xorg 3.15, Kernel 3.14, patch http://saraev.ca/OpenELEC-Generic.x86_64-devel-20140330151700-r18049-g02739c...
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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #3 from Christian König deathsimple@vodafone.de --- Created attachment 96900 --> https://bugs.freedesktop.org/attachment.cgi?id=96900&action=edit Possible fix.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #4 from Christian König deathsimple@vodafone.de --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #5 from Garrett socalfisher@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #6 from Rackow, Detlev detlev.rackow@googlemail.com --- 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 ;)
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #7 from Rackow, Detlev detlev.rackow@googlemail.com --- Created attachment 96914 --> https://bugs.freedesktop.org/attachment.cgi?id=96914&action=edit dmesg after switching to 25hz and back to 24hz
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #8 from Rackow, Detlev detlev.rackow@googlemail.com --- Created attachment 96915 --> https://bugs.freedesktop.org/attachment.cgi?id=96915&action=edit Xorg.0.log after switching to 25hz and back to 24hz
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #9 from Christian König deathsimple@vodafone.de --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #10 from Garrett socalfisher@gmail.com --- Created attachment 96962 --> https://bugs.freedesktop.org/attachment.cgi?id=96962&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #11 from Garrett socalfisher@gmail.com --- Created attachment 96963 --> https://bugs.freedesktop.org/attachment.cgi?id=96963&action=edit patch that breaks by 23.98 playback
file removed -> built then ok.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #12 from Garrett socalfisher@gmail.com --- Created attachment 96966 --> https://bugs.freedesktop.org/attachment.cgi?id=96966&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #13 from Garrett socalfisher@gmail.com --- Created attachment 96968 --> https://bugs.freedesktop.org/attachment.cgi?id=96968&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #14 from Rackow, Detlev detlev.rackow@googlemail.com --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #15 from Rackow, Detlev detlev.rackow@googlemail.com --- Created attachment 97003 --> https://bugs.freedesktop.org/attachment.cgi?id=97003&action=edit dmesg after switching to 25hz and back to 24hz, 2nd attempt
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #16 from Rackow, Detlev detlev.rackow@googlemail.com --- Created attachment 97004 --> https://bugs.freedesktop.org/attachment.cgi?id=97004&action=edit Xorg.0.log after switching to 25hz and back to 24hz, 2nd attempt
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #17 from Garrett socalfisher@gmail.com --- Created attachment 97006 --> https://bugs.freedesktop.org/attachment.cgi?id=97006&action=edit 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
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #18 from Garrett socalfisher@gmail.com --- *ERROR* Uuuu..O but it played fine. I missed that. ? back to v2? I guess.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #19 from Christian König deathsimple@vodafone.de --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #97003|0 |1 is obsolete| |
https://bugs.freedesktop.org/show_bug.cgi?id=77009
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #96914|0 |1 is obsolete| |
https://bugs.freedesktop.org/show_bug.cgi?id=77009
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #96915|0 |1 is obsolete| |
https://bugs.freedesktop.org/show_bug.cgi?id=77009
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #97004|0 |1 is obsolete| |
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #20 from Christian König deathsimple@vodafone.de --- (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...
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #21 from Garrett socalfisher@gmail.com --- Created attachment 97043 --> https://bugs.freedesktop.org/attachment.cgi?id=97043&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #22 from Garrett socalfisher@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #23 from Christian König deathsimple@vodafone.de --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #24 from Christian König deathsimple@vodafone.de --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #25 from Manp manp_82@hotmail.com --- (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
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #26 from Peter Frühberger fritsch@xbmc.org --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #27 from Garrett socalfisher@gmail.com --- (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
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #28 from Christian König deathsimple@vodafone.de --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #29 from Garrett socalfisher@gmail.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #30 from Christian König deathsimple@vodafone.de --- (In reply to comment #29)
(In reply to comment #28)
- Run a setup program each time a hardware change is detected. (EDID or GPU)
- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=77009
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
https://bugs.freedesktop.org/show_bug.cgi?id=77009
--- Comment #31 from Manp manp_82@hotmail.com --- (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
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org