Reverse Engineering DUO 2

[Ethanol10]

Hi there, I was attempting to follow ponces guide on how to build a GSI to get a start on modifying this one, however I'm hitting an issue where it can't find default.xml in the main root of the project, is that usual?

[Ethanol10]

To be clear, i'm at step 6 on this page: https://github.com/phhusson/treble_experimentations/wiki/How-to-build-a-GSI%3F

where it's trying to clone the repo from lineageOS, I replaced the URL with the git link here, but to no avail.

[Ethanol10]

I got the build script running but I've hit a wall with gradle:

--> Building treble_app

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

is this just a matter of downgrading gradle?

[Archfx]

You can ignore the gradle version warnings.

[Ethanol10]

@Archfx Do you build on an SSD or HDD? I have plenty of space on my HDD but just enough on my SSD, wondering if there was a significant benefit using SSDs

[Archfx]

I have both SSD and HDD, but I chose the HDD to build this. Every build involves lots of reads and writes, which directly affects the lifespan of the SSD. You can enable the cache which will speed up the process on HDD. Anyway, I think the CPU dominates during the build process.

[Ethanol10]

Im at a point in the build where it tries to check or presigned APKs, presumably for gapps, but it fails due to improper zip alignment, is there something I need to run to properly zip align the APKs?

[Ethanol10]

Is there a way to build this into an app to deploy? I would like to test changes but unsure on the build process for this system service:
https://github.com/Archfx/duoPosture

[Archfx]

Yes, you can build using the build.sh, but you can't test the display and other changes without persistent setting in the build file. Since all the production images are signed, you can't replace a persistent app.

One option would be to remove the persistent settings, change the package name to another, and use log files to debug the functionality. Compile, install, and observe the logs working as described. Once done we can move the changes back to the original repo.

If you want to test the app as it is, we have to use eng mode builds instead of userdebug. Then you can replace the persistent mode apps with new ones using adb.

[Ethanol10]

@Archfx Has there been efforts on testing the touchpen1.3 HAL? currently the touchpen only goes up to 1.2, but looking at the vendor partition we can see there's a touchpen 1.3 implementation.

[Ethanol10]

Yeah, might need to have some error detection on the hinge sensor, chances are the hinge greatly changing from a single screen to suddenly a dual screen posture is slim, so maybe we can check the delta between hinge angles to see if the jump is too great?

e.g, if the hinge difference between single and dual posture is within 10-20 deg, then it's probably safe to assume that it'll be ok to transition, but if it's a difference of more than 20, then that might be an erroneous reading.

The only issue is that it's hard to replicate this error sometimes. Might be hard to test but we can reduce errors for sure.

[Archfx]

Yeah, and the logic also can be simplified significantly in my opinion. Btw duo1 also has the hall sensor.

[Archfx]

Hi @Ethanol10, can you test the following command inside the adb shell on the rooted image with su permission?

pm disable-user --user all com.microsoft.surface.camera

I am trying to disable the stock camera app for all users at the boot.

[Ethanol10]

Hey @Archfx this is the output from that command with elevated permissions:

pm disable-user --user all com.microsoft.surface.camera

Exception occurred while executing 'disable-user':
java.lang.IllegalArgumentException: Call does not support special user #-1
        at com.android.server.am.UserController.ensureNotSpecialUser(UserController.java:2835)
        at com.android.server.am.UserController.handleIncomingUser(UserController.java:2801)
        at com.android.server.am.ActivityManagerService.handleIncomingUser(ActivityManagerService.java:14124)
        at android.app.ActivityManager.handleIncomingUser(ActivityManager.java:5198)
        at com.android.server.pm.PackageManagerShellCommand.translateUserId(PackageManagerShellCommand.java:3947)
        at com.android.server.pm.PackageManagerShellCommand.runSetEnabledSetting(PackageManagerShellCommand.java:2394)
        at com.android.server.pm.PackageManagerShellCommand.onCommand(PackageManagerShellCommand.java:292)
        at com.android.modules.utils.BasicShellCommandHandler.exec(BasicShellCommandHandler.java:97)
        at android.os.ShellCommand.exec(ShellCommand.java:38)
        at com.android.server.pm.PackageManagerService$IPackageManagerImpl.onShellCommand(PackageManagerService.java:6564)
        at android.os.Binder.shellCommand(Binder.java:1230)
        at android.os.Binder.onTransact(Binder.java:1043)
        at android.content.pm.IPackageManager$Stub.onTransact(IPackageManager.java:4620)
        at com.android.server.pm.PackageManagerService$IPackageManagerImpl.onTransact(PackageManagerService.java:6548)
        at android.os.Binder.execTransactInternal(Binder.java:1505)
        at android.os.Binder.execTransact(Binder.java:1444)

[Archfx]

Thanks

[Ethanol10]

In my digging, I've found the IHwBinder implementation of the touchpen and display topology used by Microsoft, which might be useful if we need to figure out more about the extra functions added versions above 1.0. I hope I can find implementations regarding the surface radio/radiox, which should help us in the long run.

[Archfx]

Great!!

[Archfx]

@Ethanol10 Check this build, this includes your treble app modifications and I added a notification panel quick setting for controlling what display to be used (manually and automatically). You have to add it using the pencil icon on the notification panel. However manual settings work great and reliably.

[Archfx]

Yeah, I loaded a Vanilla image from my previous test and the pen charge when device is charging option is still working, I don't really know why it's stopped working with GAPPS

What build type did you use for testing -userdebug or -eng?

[Ethanol10]

Should be userdebug

[Archfx]

also the manual display setting is pretty neat, but it can lock a screen from receiving input in the same manner as the bug where the touch suddenly deregisters.

When the touch deregistration happens with manual mode. Is it when the device is rotated or just right after you set the display manually?

I noticed that the hinge angle value oscillates even when the device is fully open (phone mode), which makes the peek mode overlay visible without doing anything.

Edit: Seems like my changes are properly committed into the repo

Your changes are only in duoTreble right?

[Ethanol10]

When the touch deregistration happens with manual mode. Is it when the device is rotated or just right after you set the display manually?

No particular rotation, just toggling it locks the screen on the second trigger.

Your changes are only in duoTreble right?

Yeah, should only be there.

[Archfx]

No particular rotation, just toggling it locks the screen on the second trigger.

Do you particularly observe this on all settings manual(left), manual(right), manual(tablet), and automatic, or just in some configurations?

[Ethanol10]

Do you particularly observe this on all settings manual(left), manual(right), manual(tablet), and automatic, or just in some configurations?

I think it's happening because it changes in the same way as the other bug we had awhile ago. Aka, switching the screen dynamically requires the pen to restore touch. It just so happens that the second manual option on toggle locks the screen up because two screen transitions occurred, from dual, to singular, then the opposite singular. If the singular options were switched in toggle order it'd exhibit the same issue.

[Ethanol10]

Maybe something lies in the display topology/touch hal impl, I'll grab a copy of it when I can from the SD2 partitions and post it when I can.

[Ethanol10]

@Archfx Something I noticed, If you set the Single screen setting to left and go from left to dual, the screen also locks up. I think there's something up with specifically transitions from Left -> any other posture

[Ethanol10]

Could it be anything to do with the negative offset?
e.g

            0 -> {
                systemWm?.clearForcedDisplaySize(DEFAULT_DISPLAY)
                displayManager?.setDisplayOffsets(DEFAULT_DISPLAY, 0, 0)
                setComposition(2)
                if (!previousTablet) { 
                    restartLauncher(this) 
                }
                previousTablet = true
            }

            1 -> {
                if (isDuo2) {
                    touchHalCompSet(2)
                }
                displayManager?.setDisplayOffsets(DEFAULT_DISPLAY, -PANEL_OFFSET, 0)  // <- this one
                systemWm?.setForcedDisplaySize(DEFAULT_DISPLAY, PANEL_X, PANEL_Y)
                setComposition(0)
                if (previousTablet) { 
                    restartLauncher(this) 
                }
                previousTablet = false
            }

            2 -> {
                if (isDuo2) {
                    touchHalCompSet(2)
                }
                displayManager?.setDisplayOffsets(DEFAULT_DISPLAY, PANEL_OFFSET, 0)
                systemWm?.setForcedDisplaySize(DEFAULT_DISPLAY, PANEL_X, PANEL_Y)
                setComposition(1)
                if (previousTablet) { 
                    restartLauncher(this) 
                }
                previousTablet = false       
            }

this however doesn't explain why the pen gets it working, still quite puzzling to see it stop working even though the posture can react but disallow input.

[Ethanol10]

@Archfx in DisplayTopology v1_2 there seems to be three functions unique to 1.2 that "hint" to the screen what it should display, as well as a function to set the LayoutState. It's unknown what values the mode hint functions take, as well as the layout state.

Here: https://github.com/Ethanol10/surface-vendor/blob/main/displaytopology/V1_2/IDisplayTopology.java

    int getExternalModeHint() throws RemoteException;

    void setExternalModeHint(int i) throws RemoteException;

    void setLayoutState(int i) throws RemoteException;

One day I'll have to dump what getExternalModeHint returns in each posture, maybe we can do something with that

[Archfx]

Could it be anything to do with the negative offset? e.g
this however doesn't explain why the pen gets it working, still quite puzzling to see it stop working even though the posture can react but disallow input.

Now that I've looked at this, I think you're right. A negative offset could be a culprit here.

This is from `base/services/core/

public void setDisplayOffsets(int displayId, int x, int y) {
            synchronized (mSyncRoot) {
                final LogicalDisplay display = mLogicalDisplayMapper.getDisplayLocked(displayId);
                if (display == null) {
                    return;
                }
                if (display.getDisplayOffsetXLocked() != x
                        || display.getDisplayOffsetYLocked() != y) {
                    if (DEBUG) {
                        Slog.d(TAG, "Display " + displayId + " offset set to ("
                                + x + ", " + y + ")");
                    }
                    display.setDisplayOffsetsLocked(x, y);
                    scheduleTraversalLocked(false);
                }
            }
        }    

At the end, it set the offset in this location /frameworks/base/services/core/java/com/android/server/display/LogicalDisplay.java

        if (orientation == Surface.ROTATION_0) {
            mTempDisplayRect.offset(mDisplayOffsetX, mDisplayOffsetY);
        } else if (orientation == Surface.ROTATION_90) {
            mTempDisplayRect.offset(mDisplayOffsetY, -mDisplayOffsetX);
        } else if (orientation == Surface.ROTATION_180) {
            mTempDisplayRect.offset(-mDisplayOffsetX, -mDisplayOffsetY);
        } else {  // Surface.ROTATION_270
            mTempDisplayRect.offset(-mDisplayOffsetY, mDisplayOffsetX);
        }

Can you test with a different value to see what happens?

If it doesn't do anything, we can try your alternate option.

PS: You mentioned earlier that double tap also triggers this issue. Try commenting the double tap posture overlay as well (showPostureOverlay() and hidePostureOverlay()).