I haven’t posted it yet because I’ve discovered that our latest kernel is not detecting any DVI modes besides 640x480…so we are trying to track down why, as we haven’t changed any mode related patches since the earlier kernel where DVI modes were working correctly…
regarding the S,D,U,V codes:
S - Standard mode - mode is indicated as supported by HW (screen) and it’s properties (timings) are taken from a standardised list of modes/timings
D - Detailed - mode indicated was fully specified by HW, including all timings etc
V - Vesa modes
U - Custom (USER) specified mode
those codes/flags do not have any special meaning or function, it’s just a hint what data/source was the mode created from (with this I wanted to say that as long as all other timing/res information is equal between two or more modes - flagged S/D/V/U - they all do same job regardless of this flag). the flags itself are obsolete and useless - there was even a discussion (or already even patches) on kernel devel list to remove it completely from code.
by default imx6 mxc_hdmi driver adds only modes found in CEA modelist (and those are flagged S). if a mode is not found in CEA list (timing / resolutions do not match), its pixelclock will not match supported values for clk regeneration - hdmi audio clk. that means that sound routed via hdmi soc will be off key.
(implication: other modes are fine if different sound device than hdmi-soc is used).
oh and the “broken” screen after on/off cycle on hdmi is caused by kernel itself. although it can rebuild modelist, it lacks the necessary logic to re-adapt parameters if the modelist changed (different modes, or even reordered modelist).
it also ignores screen params changes which happen by other ways than direct mode change (for instance changes between VTs with different resolutions). as a consequence it will break audio (over hdmi) too, Double/Tripple buffering as well in such cases.
this one specific case happened because new modelist shifted index (or otherwise reordered modelist).
((so nothing to do with xbmc imx6 changes))
Thanks for that inside from kernel perspective. Still I would try to avoid “double” entries, that cause different effects. Therefore as said - a more intelligent approach to preprocess Modelines and merge them is needed. The patch I proposed only cares for Systems, where not a single S: mode is available.
I would do it as follows (to also work on older, but currently in use kernels):
- Query modes (easy by splitting what …/fb/modes presents) <- Already there
- Sort them order by resolution, S: D: U: <- Super easy (Starts with + some string vectors)
- Merge them
This is a more critical process:
- Select all S: modes (skip duplicates - rare case)
- Merge all D: modes not yet available
- Merge all U: modes not yet available
- if still empty -> add V: modes
- If newer kernels know about interlaced or non interlaced, special handle them (resolution info can take care)
- Care when user reboots and those modes are gone(!)
fritsch,
if monitor provides Detailed timings, the same mode is also parsed as Standard in previous EDID block. so we have D and S mode - if the Detailed specs do follow general standards, they are the same. in that case parsing D modes makes no sense.
if the hw is very specific and detailed timing do not match standard, we end up with two modes, matching resolution (x/y, most likely also horizontal freq), but the D will have final pixel clock not supported by clk_generator (for sound).
so practically we have two modes the same (XxY-Z), one of them no hdmi sound.
-
all that combined makes D modes not worth parsing at all. as again, if there is D, there is S too - and during xbmc parsing we kick one out (because we target res-list with unique records at the level of XxY-Z).
-
the rest is easy, /modes file parsed and vector sorted after line split is by coincidence exactly as needed (S, U, V)
-
and check for duplicity was already done by popcornmix for RPI (so lets borrow that)
here is what we do:
github.com
then few lines later call to FindMatchingResolution() (c)popcornmix .
-
we even skip V resolutions completely as on imx6, its hdmi driver etc, there practically can’t be parsed or used VESA mode.
-
DVI modes are all parsed as U
(but again, this won’t affect/fix situations user reported at the beginning)
Oki - so let’s get that integrated in: i.MX: allow other modes to be set as resolution. by samnazarko · Pull Request #6929 · xbmc/xbmc · GitHub
I am having similar problems to the original poster. I lost track of the techy conversation above, so will detail my findings and let you guys work out if it has already been fixed:
Raspberry PI B+, latest OSMC (17th April).
Default TV resolution is 1080p at 60Hz, which is also my preferred resolution.
If I reboot the PI with my TV turned on, then the list of resolutions available is large and includes my TV’s 3D modes.
DESKTOP in this case gives me 1080p at 60Hz.
If I reboot the PI with my TV turned off, then I get a much smaller list of resolutions and no 3D modes.
DESKTOP in this case gives me 640p at 60Hz.
1080p at 60Hz is available in this list.
In either case, the resolution which matches DESKTOP appears as a separate item in the list of modes as well. HOWEVER, if I select it then I get 59.94 Hz instead of 60Hz. This only happens for the mode which matches DESKTOP - all other modes default to 50 or 60 Hz as expected. If I select the 59.94 Hz mode but manually change the refresh rate back to 60, the interface automatically switches the resolution back to DESKTOP.
So the main problem is that I am unable to make my preferred resolution ‘stick’, because the interface just changes it back to DESKTOP if I try to set it explicitly, and DESKTOP is a different resolution depending on whether the TV was on or off when the PI was rebooted.
I should add that I never had this problem on RaspBMC, and I don’t recall seeing the DESKTOP option in the resolution list then either.
Hope some of that is useful!
Kind Regards,
Dave
I’m also having similar problems. I have the Vero connected via HDMI through an AV Onkyo receiver to a Panasonic plasma TV. The TV is not full hd, so in the Vero I have selected the resolution 720p-50Hz. The Vero is running all the time, but I usually switch on and off the receiver and the TV, and change the input signal on the receiver, and works OK most of the time.
But sometimes (almost one time each day), when I connect the receiver and the TV and change the input to show the Vero, the screen looks absolutely distorted. The TV shows a message saying that it’s receiving a VGA signal, even when the Vero is connected via HDMI. In this situation, the Vero is completely functional and responsive, but it’s almost impossible to distinguish what’s in the screen. I’ve tried switching off and on both the TV and the receiver, but nothing changes. The only solution is to restart the Vero.
Any idea of the problem?
Thanks in advance.
Hi
I think I’m narrowing in on the problem and should be able to get something that can be tested this week.
Sam
Ok, Sam. Thanks for your answer. I’ll wait some news.
Same problem here.
In my case -
Vero
Pioneer AV receiver
Pioneer TV
The Vero is connected via HDMI through the receiver to the TV.
Vero is always on, but its video output goes haywire almost every single time I turn the TV+receiver on/off. The only solution is to power down the Vero and then power back up.
Please help Sam - this was all very well and fine when we were working with an experimental little gizmo that costs $18. Not so much with a “product” that we paid $200 for…
Update: and if I pick 720p from the resolution menu, this completely solves the problem. But neither one of the 1080p (the top one or the bottom one) works.
Experiencing same issues with samsung 4k tv screen goes black when i turn it back on vero lights still on.
Sorry for the delay. 
The missing DVI mode list was recently fixed in our kernel (not in release yet) and I’ve finally got a chance to come back and look at this. Here are both my TV and DVI monitor modelists:
1680x1050 DVI monitor:
S:1280x1024p-60
S:1152x864p-75
V:1280x1024p-75
V:1024x768p-75
V:1024x768p-60
V:800x600p-75
V:800x600p-60
V:640x480p-75
V:640x480p-60
U:720x400p-70
D:1680x1050p-59
V:640x480p-60
TV:
S:1920x1080p-30
S:1920x1080p-25
S:1920x1080p-24
S:720x576p-50
S:720x480p-60
S:1280x720p-50
S:1280x720p-60
S:1920x1080p-50
S:1920x1080p-60
V:640x480p-60
D:1920x1080p-60
V:640x480p-60
This is apparently not always the case. Please see above my modelist dumps from my TV and my DVI monitor. In the case of the TV the D mode is a duplicate of one of the S modes but for the DVI monitor there is no duplicate of the D mode, which also happens to be the native res of the screen.
I believe (but am not sure) that our latest internal test build of Kodi has these latest modelist scanning/merging patches and as a result of this my DVI monitor cannot run in its native resolution.
Our kernel correctly detects and sets up 1680x1050@60Hz DVI during boot (splash screen) however when Kodi loads it switches to 1152x864 as 1680x1050 is not available in Kodi’s resolution list.
So is there any way these patches can be updated to not assume that there are always duplicates of D modes ? In any case should the D mode not have priority over any duplicate modes if it is more specific/detailed timing ?
That one: D:1680x1050p-59 will be missing. Though I wonder anyways. Is that is most likely 59.94 hz, that IMX cannot output anyways?
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.
On previous Kodi builds with our own mode patches this mode was definitely working fine - or I can disable Kodi’s write access to /sys/class/graphics/fb0 so that it cannot change the mode and Kodi will run fine in the mode as set up by the Kernel.
It’s possible that the Kernel is just rounding and configuring 59 or 60Hz of course, I don’t have a way to measure the precise refresh rate being sent. (I think this monitor supports both 59 and 60Hz - both are reported in Windows) BTW the monitor OSD reports 60Hz not 59Hz - but it too might be rounding.
All that appears to be needed is for Kodi to be modified to consider D modes again.
To get some outside perspective, here is what tvservice on my Pi 2 reports for the same monitor:
osmc@rpi2:~$ tvservice -s
state 0x120016 [DVI DMT (57) RGB full 16:10], 1680x1050 @ 60.00Hz, progressive
osmc@rpi2:~$ tvservice -m DMT
Group DMT has 10 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 6: 640x480 @ 75Hz 4:3, clock:31MHz progressive
mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
mode 11: 800x600 @ 75Hz 4:3, clock:49MHz progressive
mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
mode 18: 1024x768 @ 75Hz 4:3, clock:78MHz progressive
mode 21: 1152x864 @ 75Hz 4:3, clock:108MHz progressive
mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive
mode 36: 1280x1024 @ 75Hz 5:4, clock:135MHz progressive
(prefer) mode 57: 1680x1050 @ 60Hz 16:10, clock:119MHz progressive
If you really need it, just remove the cases here and skip the continue completely: [IMX] probe & push all resolutions we can use · fritsch/xbmc@4533885 · GitHub e.g. remove 301 including 303 and test no your setup - we filter out duplettes anyways, so it does not harm. the only problem with that approach now is, that D modes would be scanned first
@mk01 what do you think about @DBMandrake’s DVI monitor?
With those changes 1680x1050 now works on the DVI monitor and is the default Kodi resolution.
It doesn’t seem to have made any difference to the modes on my TV - despite the D mode now having priority when merging modes, (from what you say) it still starts up in S:1920x1080p-60 instead of D:1920x1080p-60.
Let’s try it differently. E.g. saving the D: modes in that first iteration in String Array and after adding the rest, add those additional, while checking if they are duplicate or not.
Can you implemented that? Or should I do this?
EDIT: Feel free to use: Ubuntu Pastebin (not compile tested) to fix it up and PR it upstream - when opening the PR, don’t forget to show your modes, like in the post before
Updated: Ubuntu Pastebin (safe is better)
I see some progress here! Now the signal is fixed in a single reboot, hopefully in the 1.0 this is fixed so that it doesn’t get broken at all. Nice work guys!