hdmi_mode setting

[clausmuus]

Hi,

at the actual version of the vompclinet it is necessary to set up the hdmi_mode in the config.txt file. Otherwise the TV disconected from the RPI ( "no signal" message will be shown) if a TV stream starts.
It seems, that older versions of the vompclient don't has this problem. Also if I stop the vompclient (actual version), most times the TV shows the "no signal" message or switch to a other program.
Do you have any idea, what is the reason for this. Especially the first problem is bad, because than no video will be shown, until a working configuration was found, and this differed for several TVs, so that I can not setup a default value.

Claus

[MartenR]

I have absolutely no idea. Can you please figure out which change causes this behaviour....
But propably we have to ask the firmware guys, what is going on there. I personally do not have this problem, so please try to contact the firmware people at raspberry pi forum and point me to the thread...

(Maybe there is still the problem of the power supply, I personally use 2.1 A, since I had problems with a 1 A source, the HDMI connection got lost before occasionally)

Marten

[JTe]

There was a gpu firmware update on October 5. Did you update your system after that and could that firmware update have effect to your problem?

[clausmuus]

Hi,

no, the new firmware don't helps.

@Marten,
only a idea: Did the vompclient try to change the TV output to the resolution of the selected video (or any other resolution), on selection of a TV channel? Did you request the available video formats for this?
I have made some further test. It is also enough to select the resolution by the tvservice tool before starting the vompclient to make it works. It is not necessary to select it in the config.txt. If I select a resulution after the vompclient start, I get no video out.
Since it is possible to select video resolution at runtime, maybe it's a possible way, to select the resolution of the selected TV channel, and let the TV make the deinterlacen? I know, you have already a solution for this, but maybe this reduct the CPU usage and makes the quality better? In any case, this must be disengageable if a TV don't support the needed resolution.

Claus

[MartenR]

only a idea: Did the vompclient try to change the TV output to the resolution of the selected video (or any other resolution), on selection of a TV channel? Did you request the available video formats for this?

The code for this should be deactivated.

Did you request the available video formats for this?

The deactivated code does this. (Was never activated in git).

Since it is possible to select video resolution at runtime, maybe it's a possible way, to select the resolution of the selected TV channel, and let the TV make the deinterlacen?

For SD I would not recommend this, the OSD would look terrible. For HD I already tried this, but I was unable to reinitialize the OSD objects in this case, so a gave up on this for now.
With the no video out, the video mode, which is chosen on bootup, what kind of mode is it a CEA mode?
Does it support HDCP, may be for some stupid reason encryption is  needed???

Marten

[clausmuus]

Hi,

the automatically chosen mode is the 1080p@60Hz. But if I select this in the config.txt file, I have no problem. Only if it's chosen automatically I have the problem.
If i don't select a mode in the config.txt, I can get a list of all available modes with the tvservice command. If I select a mode in the config.txt, I get only this one mode as available by the tvservice tool. That is the reason, why I ask, if you make a automatic mode switch, if more modes available. But since I know, that also all modes available, if I select a mode by the tvservice tool, I no longer think, that this is the problem.
I have no information about the HDCP stuff.
Today evening, I will check the exact automatically selected mode.

Claus

[sirwio]

I have similar experience with a Samsung TV. Testing supported modes using the 'tvservice -m CEA' command yield that both HDMI_CEA_1080p60 and HDMI_CEA_1080p50 were supported, among others, and that 1080p60 was the native mode that is also chosen automatically.

Playing video when in automatic mode did however result in a black screen. Tried forcing the mode to 1080p60 but that did not work either but setting it to 1080p50 give picture. This differs a bit from the results of clausmuus where the native mode appears to work in his case whereas in my case I had to force 1080p50.

[MartenR]

Ok, please go to the raspberry pi forum, we need to talk with the firmware people. (Post the thread, I will then join into the discussion)
This is out of scope what is accessible by my code.
We have to ask them what is going on.... (Also test before if the same is true for the hello_video sample)

I think also the behaviour of the tvservice command is different then before. I did not have problems since I set a specific mode in config.txt.

Edit: I can reproduce this problem. I have post on raspberry pi forum
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=19334&p=191832#p191832

Marten

[MartenR]

@clausmuus

Can you look at the thread? Maybe your MLD is a quick way to look into the problem for dom?
Especially without setting up a vdr??

[MartenR]

Should be fixed with an automatic video mode change triggered by vomp and removal of one layer.
Please test it, I do not know, if my algorithm works on every monitor or tv.

Marten

[davep]

Is this expected behaviour?

Code Select Expand


12:21:34.893190 [debug]  1993 Video - Setting aspect to 0
12:21:34.893804 [notice] 1993 Video - Found native mode 1280x720 60 Hz i: 0
12:21:34.894017 [notice] 1993 Video - Found native mode 1280x720 50 Hz i: 0
12:21:34.894141 [notice] 1993 Video - Found close to optimum mode 1920x1080 50 Hz i: 1
12:21:34.894262 [notice] 1993 Video - Found optimum mode 1920x1080 50 Hz i: 0
12:21:34.894431 [notice] 1993 Video - Switch to optimum mode


It seems strange to upscale SD video to 1080p only for the TV to downscale it again.

Actually I see in the latest patch that the native mode is ignored:

Code Select Expand


+               //Now first determine native resolution
+               int native_width=1920;
+               int native_height=1080;
+               for (int i=0;i<all_my_modes;i++) {
+                       if (all_supp_modes[i].native) {
+                               mymode=all_supp_modes+i;
+                               Log::getInstance()->log("Video", Log::NOTICE, "Found native mode %dx%d %d Hz i: %d",
+                                               mymode->width,mymode->height,mymode->frame_rate,mymode->scan_mode);
+                       }
+
+               }


Native_width and native_height are never set to the values for the native mode.

[MartenR]

@davep
Well spotted, please add this into the if case:

Code Select Expand

native_width=mymode->width;
native_height=mymode->height;
I cannot put it into git in the moment, I am in a debugging session currently.
Will come with next commit.

Marten

[sirwio]

I can confirm that the implemented changes works with a vompclient connected to a Samsung UE46ES5505.

No need to force a specific hdmi mode any more.

[clausmuus]

Me too

Claus

[clausmuus]

Hi,

now I have a new (small) problem. If I stop the vompclient, I get not the console back. Also if I made a reboot, I will see nothing until the vompclinet starts again.
Is it possible to reactivate the console if the vompclient stops (e.g. killed by SIG TERM) or at minimum, is it possible to do this by a command line command?

Claus