[mythtv] NVidia Shield screen resolution

Mark Spieth mark at digivation.com.au
Wed Aug 1 22:27:44 UTC 2018

On 8/2/2018 7:17 AM, Peter Bennett wrote:
> On 07/30/2018 11:17 PM, Mark Spieth wrote:
>> On 31/07/18 08:52, Peter Bennett wrote:
>>> On 07/29/2018 06:58 PM, Mark Spieth wrote:
>>>> On 30 July 2018 08:29:31 GMT+10:00, Peter Bennett 
>>>> <pb.mythtv at gmail.com> wrote:
>>>>> On 07/29/2018 06:14 PM, Mark Spieth wrote:
>>>>>> Is this also with video playback or UI only?
>>>>> It is both. In the Setup->Appearance I tried changing the GUI size to
>>>>> 1280x720. That should have used one third of the width and height, 
>>>>> but
>>>>> actually used two thirds of the width and height.
>>>>>> Is it different with media codec vs GLES?
>>>>> No - media codec is also using OpenGL for output, the same as used by
>>>>> software decoding. It may be different with a surface but there is no
>>>>> code to use a surface at this time.
>>>>>> CPU definitely takes a hit for a 4K screen though.
>>>>>> Will do some research on this.
>>>> Smells like a qt or platform gl problem. Need to check qt source 
>>>> for 1920 restrictions.
>>> FWIW 4K video works fine with Qt on Linux. Also I tested the 4K 
>>> video with Kodi on Shield and it is playing with the full 4K 
>>> resolution on my monitor, so it is possible to do it. I did scan 
>>> carefully through the Kodi manifest but I could find nothing that 
>>> might help me.
>> Here is something to look at.
>> in qt source qtbase/src/plugins/platforms/android/androidjnimain.cpp
>> there are 2 functions
>> createSurface and setSurfaceGeometry. This is the lowest level before 
>> android and applies to qt's gl surface it allocates at start.
>> instrument with some __android_log_print to see what height and width 
>> are being used. These will appear in logcat.
>> Make changes and then makelibs.sh without clean. Wont take as long as 
>> clean and you dont need to export any diffs either.
>> Changes are preserved. since git is used for baselining you can git 
>> diff to get your patches too.
>> Note this is the file that launches main() in mythtv. see 
>> startapplication which launches a thread which then runs main(). This 
>> is called from the java initial code (some in qt and 1 overridden in 
>> our android_package_source tree.
>> Not sure when I can test this but may give you some hints as to where 
>> the 4k is going.
>> All parts of our android app is using gl for rendering.
>> You can also go for gdb and break in these functions if you are extra 
>> adventurous.
>> HTH
>> Mark
> This is what I get logged
> androidjnimain.cpp setDisplayMetrics wP=1920 hP=1080 dWP=1920 dHP=1080 
> xdpi=213.000000 ydpi=213.000000 sD=2.000000 d=2.000000
> qandroidplatformintegration.cpp setDefaultDisplayMetrics gw=1920 
> gh=1080 sw=229 sh=129 scrW=1920 scrH=1080
> androidjnimain.cpp setSurfaceGeometry x=0 y=0 w=1920 h=1080
> setDisplayMetrics parameters logged are
>         widthPixels, heightPixels,
>         desktopWidthPixels, desktopHeightPixels,
>         xdpi, ydpi,
>         scaledDensity, density);
> Those last two parameters of setDisplayMetrics look like a possible cause
> scaledDensity=2 and density=2. Documentation says scaledDensity is for 
> fonts and density is logical density.
> QtLayout.onSizeChanged (java)
>  calls android.view.Display.getMetrics()
>  calls QtNative.setApplicationDisplayMetrics()
>    calls setDisplayMetrics (c++)
> /public void getMetrics (DisplayMetrics outMetrics)//
> //
> //Gets display metrics that describe the size and density of this 
> display. The size returned by this method does not necessarily 
> represent the actual raw size (native resolution) of the display.//
> //2.//*It may be scaled to provide compatibility with older 
> applications that were originally designed for smaller displays.
> */How do we explain to android this is not an older application like 
> that? Will each android device do its own thing here?
> /DisplayMetrics.density//
> //The logical density of the display. This is a scaling factor for the 
> Density Independent Pixel unit, where one DIP is one pixel on an 
> approximately 160 dpi screen (for example a 240x320, 1.5"x2" screen), 
> providing the baseline of the system's display. Thus on a 160dpi 
> screen this density value will be 1; on a 120 dpi screen it would be 
> .75; etc. //
> /
> Maybe we should use getRealMetrics instead of getMetrics I can try that.
> Otherwise multiply screen height and width by density.
> Either way involves changing some QT code ???
I'm not afraid of changing QT code (as evidenced by the patches) and nor 
should anyone else be.
Looking at updating QT5.11.1 ATM to see if that will help but probably not.
getMetrics is interesting. This I think is used in myth too for API 
compatibility originally. I was targeting 4.2 + because I had some 
devices using that including my projector on 4.4 and tv on 4.4 which 
will never get any updates.

If that is where the numbers HD are coming from, then replace it with 
getRealMetrics and see.
Ill investigate the impacts today some time as I find time.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20180802/8779bd67/attachment.html>

More information about the mythtv-dev mailing list