Linux Bug in CEGLNativeTypeIMX::ProbeResolutions
#1
Hi,

I actually tried to file a bug report, but I am having trouble with login into http://trac.kodi.tv/.

The problem: I just updated from Kodi 15.2.3 to 16, and the 1280x720 resolution is not working anymore.
Note: Kodi is running on ArchLinux on a Cubox-i (imx6 SoC) and connects to an 720p TV via HDMI.

The frame buffer device supports the following resolutions:
Quote:cat /sys/class/graphics/fb0/modes
S:720x576p-50
S:720x480p-60
S:1920x1080i-50
S:1920x1080i-60
V:640x480p-60
D:1280x720p-50
D:1280x720p-60
V:640x480p-60

Kodi ignores the 1280x720 resolutions though. Extract from the log file:
Quote:13:32:14 T:1947570176 NOTICE: Found resolution 1920 x 1080 for display 0 with 1920 x 1080i @ 50.000000 Hz
13:32:14 T:1947570176 NOTICE: Found resolution 1920 x 1080 for display 0 with 1920 x 1080i @ 60.000000 Hz
13:32:14 T:1947570176 NOTICE: Found resolution 720 x 480 for display 0 with 720 x 480 @ 60.000000 Hz
13:32:14 T:1947570176 NOTICE: Found resolution 720 x 576 for display 0 with 720 x 576 @ 50.000000 Hz
13:32:14 T:1947570176 NOTICE: Found resolution 640 x 480 for display 0 with 640 x 480 @ 60.000000 Hz
13:32:14 T:1947570176 NOTICE: Checking resolution 19
13:32:15 T:1947570176 DEBUG: SetNativeResolution: S:720x576p-50


I had a look at the imx specific source code and found the following in the file xbmc/windowing/egl/EGLNativeTypeIMX.cpp
Quote: if(!StringUtils::StartsWith(probe_str[i], "S:") && !StringUtils::StartsWith(probe_str[i], "U:") &&
!StringUtils::StartsWith(probe_str[i], "V:"))
continue;

The 1280x720 resolution is neither category "S", nor "U", nor "V". It is category "D" (see framebuffer modes above), which is ignored. Hence, kodi ignores the 1280 resolution and switches to one of the resolutions that are non-native on my TV.

What was the reason for ignoring category "D"?
Probably this happened unintentionally...
Reply
#2
See the discussion here: https://github.com/xbmc/xbmc/pull/7139 I was convinced to not enumerate D modes by mk01.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#3
it is fine with new kernel tree
Reply
#4
Hm, I had a quick look at the "DVI monitor" discussion threads.
The issue there was about priority: V before D, etc, right? My problem is that the D category is completely filtered.

@mk01: are you saying, that it is safe to add category D again, assuming that a recent kernel (version?) is used ?
Reply
#5
The problem was not priority, but:
mk01 Wrote:... remember imx6 can't play 59hz, but you will parse into xbmc with refresh 59hz. imx6 on setting this mode will internally setup 60hz. dbmandrake already confirmed, that the screen is distorted.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#6
I had a look at the osmc.tv discussion again, and I am interpreting things differently regarding this entire D:1680x1050p-59 discussion:
Quote:DBMandrake wrote:
It can display it just fine - the kernel sets up this mode at boot time correctly for the splash screen or console login (if I disable kodi) but Kodi will change to a different mode because it doesn't see it as a valid mode.
[...]
All that appears to be needed is for Kodi to be modified to consider D modes again.
[...]
With those changes 1680x1050 now works on the DVI monitor and is the default Kodi resolution.
It seems to me that the D mode should not be ignored. But it is ignored by Kodi at the moment.

Of course, I can always patch and rebuild Kodi myself, but that's annoying.
Reply
#7
It's not about annoying or not, it was about technical limitations at the time when this code was written. Technical limitations that are still in many distros with too old kernel out there. The "D:" modes are not in there cause distortion the guy you just cited confirmed .... IMX is maintained by exactly one guy currently and I don't want to cause regressions.

Send a PullRequest that enables it and if mk01 wants, he can push it.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#8
@fritsch : I can understand your concerns regarding modifying code maintained by someone else.

I'll proceed with the pull request and see how things turn out.


Thanks for taking the time though!
Reply

Logout Mark Read Team Forum Stats Members Help
Bug in CEGLNativeTypeIMX::ProbeResolutions0