28 replies to this topic

[malakudi]

So, what does "multi" saves to /proc/stb interface and what does VU+ drivers do? Ignore it?

[Rob van der Does]

So:
1- autoresolution has nothing to do with it; it's an extra and optional setting.

(part of) the autoresolution plugin has been ported to e2, that's why I called it 'autoresolution' functionality (even though it only handles refreshrate and aspectratio).

Hmm, not sure why you would call that autoresolution?
What you're talking about is only about the detection of 50Hz/60Hz and setting the output accordingly.

What the VideoMode plugin actually did was overruling the aspect set by any drivers; that has now been omitted.
The 'VU bug' was that the aspect was only set for the current video mode (at boot time and that is the resolution of bootlogo.mvi) so if your chosen video was 1080i the aspect was not set: that resulted in 'JUSTSALE' being set, irrespective of the policy set in AV-settings
In the new code the aspect is set on any video source resolution change, detected in the new code. So this has nothing to do with autoresolution as the mode is not being changed; it only allows the driver to actually set the aspectratio i.a.w. the setting made by the user related to the videocontents (as one would expect this to behave).

2- all VU's using OE-A images no longer suffer from the named bugs.

Can I carefully conclude that VU could thank the OE-alliance team for masking out how the VU drivers do perform?

I don't even think you have to be careful: actually I think it's the users that will be grateful that this mishap in previous code has now overcome.

[pieterg]

It has nothing to do with 'autoresolution', that's why I kept using the word autoresolution between quotes.
And I explained I called it 'autoresolution' because it is two thirds of the functionality of the autoresolution plugin, ported into e2.

[littlesat]

it only allows the driver to actually set the aspectratio i.a.w. the setting made by the user related to the videocontents (as one would expect this to behave).

With ET (and as far I know also DMM and XP) the driver is indeed doing this for you for free...  I never got aspect ratio issues with my ET9000 since the fix in their drivers in the 2nd or 3rd month the ET box was released.

 

For the VU it seems enigma2 should analyse the content and after a configurable while the driver should be forced to the correct uitput configuration....

 

So in short all this was done to work-a-round the VU drivers... and the non VU boxes this is also unnecessarily done.

 

That was why I stated enbeded in enigma2 is not always recommended....

[Rob van der Does]

So, what does "multi" saves to /proc/stb interface and what does VU+ drivers do? Ignore it?

There are settings in all drivers
/proc/stb/video/videomode50hz
/proc/stb/video/videomode60hz
these contain the mode that is compatible for that mode, i.e. if you choose res 1080i:
/proc/stb/video/videomode50hz would contain "1080i50'
/proc/stb/video/videomode60hz would contain "1080i'
the driver should use these modes if the driver detects 50Hz or 60Hz, irrespective of your chosen res. But: 720p does not support multi, next res that does is SD i.e.SCART. ET drivers 'might' support this but VU never has.

 

So these values are read and set the main driver to the res inside the relevant proc, i.e. if source is 1080i 50 it reads /proc/stb/video/videomode50hz and sets maindriver to that mode:

 

if path.exists('/proc/stb/video/videomode_%shz' % new_rate) and config_rate == 'multi':
f = open("/proc/stb/video/videomode_%shz" % new_rate, "r")
multi_videomode = f.read().replace('\n','')
print 'multi_videomode:',multi_videomode
f.close()
if multi_videomode and (current_mode != multi_videomode):
write_mode = multi_videomode
else:
write_mode = config_mode+new_rate
 

And of course: it does NOT HARM any other box.

 

 

That was why I stated enbeded in enigma2 is not always recommended....

Hmm, it looks like you didn't understand my explanation or read the code yourself?
And you don't realize that this is a safe way of working for ALL boxes? Look at the enormous amount of hardware supported by the OE: it works for all.

So not relying on an old DM-plugin does have it's advantages .....

And in the end ALL users of ALL hardware will be happy with 2 bugs less ....

And the beauty is of course, that the new coding is open source, so it can be used by all. Even by the illegally closed source VTi & BH-iamages!


Oh, I almost forgot: as the embedded, optional to use AutoResolution function is basic (try to match in and out) and hence limited, users can still use the AutoResolution plugin to have full control. The embedded AR will then automatically be disabled.

[pieterg]

And of course: it does NOT HARM any other box.

It does not harm, but it could cause two mode switches instead of one.

And I hope you can understand the point I was making; it is a userspace workaround for a lacking driver feature.

[littlesat]

That was exactly the point I meant... Double switching on boxes that do not require it... And that was also why I meant that is might be better to let it be a plugin... So you only install it on boxes that need it... So for the boxes that do not need it you do not get a double switch...

But still everyone is free to do what they want....

Edited by littlesat, 1 November 2013 - 18:43.

[Rob van der Does]

Did you actually experience any disadvantage?

 

Anyway: I sincerely hope you'll give PLi-users an image with 2 bugs less.

[Rob van der Does]

Did you actually experience any disadvantage?

I bet you didn't.
I just did extensive testing on the ET9200 and not a single 'switching twice' issue. So apparently this is a theoretical issue (if any at all)


So this still applies:

Anyway: I sincerely hope you'll give PLi-users an image with 2 bugs less.