[Question] getprop in a confined app?

pparent

Hi,

In order to adapt properly the scaling of my app I would need to do

/usr/bin/getprop ro.sf.lcd_density

The problem is that if I do that inside a confined app I get

aa-exec[6536]: ./launcher.sh: 12: /usr/bin/getprop: Permission denied

But if I copy the binary /usr/bin/getprop inside my app install repo in /opt/click.ubuntu.com/ and call it then it works well. The thing is I want to make something clean, and not dumping a binary from the phone inside my app, not even knowing if it will work for every phone.

Is there a way to do without copying the getprop binary in my app install dir? Otherwise is there a way to download the getprop binary from official ubports build sources? Where does this binary come from?

Thank's a lot in advance!

lduboeuf

@pparent
I doubt a confined app can access Android properties.
For the "where does it came from" :
https://gitlab.com/ubports/development/core/packaging/libhybris/-/blob/ubports/latest/debian/control?ref_type=heads#L153

pparent

@lduboeuf said in [Question] getprop in a confined app?:

I doubt a confined app can access Android properties.

I can garanty you that if it embeeds a local copy of /usr/bin/getprop then it can.

pparent

@lduboeuf said in [Question] getprop in a confined app?:

For the "where does it came from" :
https://gitlab.com/ubports/development/core/packaging/libhybris/-/blob/ubports/latest/debian/control?ref_type=heads#L153

Thank's but it there a way to download the compiled version in a similar fashion that it would be doable with lauanchpad in official Canonical Ubuntu ?

pparent

This is outdated:

https://launchpad.net/ubuntu/xenial/+package/libhybris-utils

pparent

said in [Question] getprop in a confined app?:

libhybris-utils

Ok I've found

apt download libhybris-utils:arm64

Inside the clickable containre allows to download the deb package, then you can extract from it the getprop binary.

kugiigi

Can't you get the density somewhere else? For example in QML, you use Screen.

pparent

@kugiigi

Well I've tried with density from qt, but it does not seem to give coherent results across devices.

gpatel-fr

@pparent said in [Question] getprop in a confined app?:

coherent results !

well, concerning Fairphone specs, not sure if coherence is an appropriate word. For example, on the Fairphone site and so everywhere on the web, you can read that FP5 screen is 6.46 inches; that is, about 16.4 cm unless they have special dutch inches.
I have a Fairphone 5 and it is no more than 16 cm in total, including the somewhat 10mm of margins in the height direction, so real meaningful screen height is more about 15cm, that is, what you could imply from the mentioned density on third party sites, so 5.88 inches (2700 / 459 = 5.88). BTW getprop returns 480 dpi on my FP5.
It's difficult to square up all these numbers and I wonder if the FP4 is any better.

pparent

@gpatel-fr

Here are the datas I have for vollaphone 22 and vollaphone x23

                          Official PPI    Qt density      getprop density
    Vollaphone  22        410	            252	            480
    Vollaphone X23        282	            216	            320

Getprop seems always official value rounded up to the closest possible value for android (that seem to be only a handfull of values), but seem quite coherent in proportion, contrary to qt density.

gpatel-fr

@pparent

Sorry for the delay, it has taken some time for running a basic QT program on UT without any prior experience.

yes you are right about Android rounding values, however it's not possible that QT takes values from Android since for QT it runs on a standard Linux system.

about the 'bad' values in QScreen, I have found that the 'name' property is 'XWAYLAND0', so QT is connecting to the X server part of Mir to get at the screen properties. I have found this comment in QT sources (qtbase/src/3rdparty/wayland/protocols/xdg-output/xdg-output-unstable-v1.xml)

   <event name="logical_size">
      <description summary="size of the output in the global compositor space">
        The logical_size event describes the size of the output in the 
        global compositor space.
    
        Most regular Wayland clients should not pay attention to the
        logical size and would rather rely on xdg_shell interfaces.
  
        Some clients such as Xwayland, however, need this to configure
        their surfaces in the global compositor space as the compositor
        may apply a different scale from what is advertised by the output
        scaling property (to achieve fractional scaling, for example).

for sure I don't understand the implications well enough to qualify this result as an 'Ubuntu touch bug', but some sort of rescaling in the Lomiri touch code could explain that the physical size of my FP5 is all over the place according to QScreen (21.4cm instead of 16cm)

pparent

@gpatel-fr

Well anyway I think the best thing to do would be that every port register the real DPI value of their screen, and then the value is accessible to the app via an environment variable. It would allow non-Qt app to scale correctly as easily as possible.

kugiigi

@gpatel-fr There's a known bug with the FP5's detected screen size. This is why Morph and webapps loads desktop version of sites. If I remember correctly, the porter said that it's an issue with the firmware itself or kinda Fairphone's fault. I think he has a solution but he needs to find a general solution that won't affect other devices.

@pparent I'm curious what exactly you are using because on my apps using Screen.pixelDensity works fine except as I mentioned above, the FP5. I don't have Volla phones though so not sure there

pparent

@kugiigi

Can you give the exact code of a program that will return the dpi?

Note that I'm trying to scale a non-Qt application, so I can use a secondary qt utility to get the screen density, but nothing more.

What I have tried that does not give good results is:

#include <QGuiApplication>
#include <QScreen>
#include <QDebug>
#include <iostream>
using namespace std;

int main(int argc, char *argv[]) {
    QGuiApplication app(argc, argv);

    QScreen *screen = QGuiApplication::primaryScreen();
    qreal dpi =  screen->logicalDotsPerInch();  // Moyenne approximative
    cout << dpi <<endl;

    return 0;
}

kugiigi

@pparent I don't know exactly how you use the value for scaling but here is what I use in my app for things that I want to be based on physical measurement instead of being affected by scaling i.e. gestures

https://gitlab.com/kugiigi1/sapot-browser/-/blob/ubports/xenial/src/app/webbrowser/morph-browser.cpp#L105

pparent

@kugiigi said in [Question] getprop in a confined app?:

@pparent I don't know exactly how you use the value for scaling but here is what I use in my app for things that I want to be based on physical measurement instead of being affected by scaling i.e. gestures

https://gitlab.com/kugiigi1/sapot-browser/-/blob/ubports/xenial/src/app/webbrowser/morph-browser.cpp#L105

Ok thank you I will try it.

gpatel-fr

@kugiigi said in [Question] getprop in a confined app?:

based on physical measurement

I think that this physicalDotsPerInch thingy could be affected by the idea that QT has about the physical size of the screen: using my first pyqt application:

from PyQt5.QtWidgets import QApplication

q=QApplication(['demo'])

ls = q.screens()

myscr=ls[0]
print(f"name={myscr.name()}")
print(f"logicalDotsPerInchX={myscr.logicalDotsPerInchX()}")
print(f"logicalDotsPerInchY={myscr.logicalDotsPerInchY()}")
print(f"physicalDotsPerInch={myscr.physicalDotsPerInch()}")
print(f"physicalDotsPerInchX={myscr.physicalDotsPerInchX()}")
print(f"physicalDotsPerInchY={myscr.physicalDotsPerInchY()}")
print(f"physicalSize={myscr.physicalSize()}")
print(f"size={myscr.size()}")
print(f"devicePixelRatio={myscr.devicePixelRatio()}")
print(f"depth={myscr.depth()}")
print(f"virtualSize={myscr.virtualSize()}")
print(f"geometry={myscr.geometry()}")

I get:

name=XWAYLAND0
logicalDotsPerInchX=96.25263157894736
logicalDotsPerInchY=96.05042016806723
physicalDotsPerInch=320.48931496290584
physicalDotsPerInchX=320.51134020618554
physicalDotsPerInchY=320.46728971962614
physicalSize=PyQt5.QtCore.QSizeF(97.0, 214.0)
size=PyQt5.QtCore.QSize(1224, 2700)
devicePixelRatio=1.0
depth=24
virtualSize=PyQt5.QtCore.QSize(1224, 2700)
geometry=PyQt5.QtCore.QRect(0, 0, 1224, 2700)

since for my FP5, the physical size of the screen is supposed to be 21.4cm, that is, 8.425 inches, this gives 2700/(21.4/2.54) = 320.4672897196262 and that's physicalDotsPerInch is reporting in my test with pyqt on my FP5. Maybe Volle phones are also misreporting the physical size of the screen ?

Edit: I think I understand; I am using straight qt and pyqt that has no knowledge of mir, that's why it is using xcb: printenv returns QT_QPA_PLATFORM=ubuntumirclient;wayland-egl;ecb
I'll search if there is a way to get a plugin to enable my pyqt for ubuntu touch maybe it could give better results.

Edit 2: not found but I now doubt that there is a good way to fix it on the FP5, Internet gave me the useful tip to use an utility called 'mirout', and it reports to me:

phablet@ubuntu-phablet:~$ mirout
Connected to server: <default>
Output 1: LVDS, connected, 1224x2700+0+0, enabled, on, 97mm x 214mm (9.3"), normal, 3.00x, unknown, phone
1224x2700 60.00*+
Output 2: DisplayPort, disconnected
Output 3: Virtual, disconnected
1920x1080 60.00*+

so the problem is indeed with the phone, not the driver.