Maru OS Nintendo Switch Port (LOS 17.1)

[T M]

Hi all!

A few of us in the Switchroot (https://switchroot.org/) group have been working on a Maru OS port to the Nintendo Switch using our LineageOS 17.1 sources and new L4T kernel, based on the existing Nvidia Tegra ports. We've been very successful so far, using forked Maru sources ported to 17.1 from https://github.com/deepak-divakar (see his thread on here for more details on his port). The OS boots and we got the Linux container running with desktop mode, but we're having some trouble getting display output. In order to get out (slightly hacked-together) Lineage port to do this, we force-disable hardware overlays and force-set the renderer to software/surfaceflinger. Unfortunately, that seems to not work with our Maru port, as even with the compositor props forcibly set in our device repo, HWC seems to still be on by default. This presents both our docking/secondary display bug and a nasty artifacting bug on device rotation (hence our force disabling). Any thoughts? For reference, all our maru-specific custom sources can be found at https://gitlab.com/switchroot-maru-os, our kernel sources can be found at https://gitlab.com/switchroot, and we also pull Nvidia Shield LOS repos from https://gitlab.incom.co/CM-Shield. Any insights, help, or advice would be greatly appreciated! Feel free to join our Linux 4 Switch Discord server (https://discord.gg/53mtKYt) if you'd like to help right where the action is. We appreciate all the work that's gone into this project, and we'd love to get it working at full potential, especially on a platform built for dock support!

[utzcoz]

Could you provide logs for it? If the display output failed, the mflinger or mclient will print some error information.

On Thu, Mar 18, 2021 at 12:04 PM T M <haloro...@gmail.com> wrote:

Hi all!

A few of us in the Switchroot (https://switchroot.org/) group have been working on a Maru OS port to the Nintendo Switch using our LineageOS 17.1 sources and new L4T kernel, based on the existing Nvidia Tegra ports. We've been very successful so far, using forked Maru sources ported to 17.1 from https://github.com/deepak-divakar (see his thread on here for more details on his port). The OS boots and we got the Linux container running with desktop mode, but we're having some trouble getting display output. In order to get out (slightly hacked-together) Lineage port to do this, we force-disable hardware overlays and force-set the renderer to software/surfaceflinger. Unfortunately, that seems to not work with our Maru port, as even with the compositor props forcibly set in our device repo, HWC seems to still be on by default. This presents both our docking/secondary display bug and a nasty artifacting bug on device rotation (hence our force disabling). Any thoughts? For reference, all our maru-specific custom sources can be found at https://gitlab.com/switchroot-maru-os, our kernel sources can be found at https://gitlab.com/switchroot, and we also pull Nvidia Shield LOS repos from https://gitlab.incom.co/CM-Shield. Any insights, help, or advice would be greatly appreciated! Feel free to join our Linux 4 Switch Discord server (https://discord.gg/53mtKYt) if you'd like to help right where the action is. We appreciate all the work that's gone into this project, and we'd love to get it working at full potential, especially on a platform built for dock support!

--
You received this message because you are subscribed to the Google Groups "Maru OS dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maru-os-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/maru-os-dev/81f6163b-43e7-4e68-b4eb-44296bd4a00fn%40googlegroups.com.

[T M]

Logcat is attached--Only events referencing mclient or mflinger I found were 3 telemetry events stating the mclient version. Again, we've had issues with display output on our main Lineage release, forcing us to disable HWC by default, but this seems to not be correctly applying in Maru, which appears to be using hardware overlays despite force setting the relevant props.

[utzcoz]

I tested the display output with HWC disabled with my Pixel XL, and it works fine.

It uses the latest maru-0.7 source code.

The logcat doesn't show an error about mclient or mflinger.

Actually the mflinger will show some information when it works.

Could you test it with a simulated display in the development settings page and catch

logcat between your start a simulated display, and you finish after some minutes?

To view this discussion on the web visit https://groups.google.com/d/msgid/maru-os-dev/100fbfec-325c-409b-964a-1256808aeedfn%40googlegroups.com.

[T M]

No my point about HWC was that it seemed to refuse to be disabled and that the Switch doesn't do secondary display using HWC due to a bug in the hardware composer we can't fix (Nvidia doesn't officially support Q so stuff has had to be reversed on O and P + ported from O and P). I could be wrong about some of this, though. Anyway, we got correct logs this time--I think we improperly collected them for that last one.

Procedure for simulated_display.txt as relayed by tester: turned on desktop mode, logcat, second display simulator, waited, docked, undocked, plugged back into pc, logcat
Procedure for only_started_desktop_mode.txt as relayed by tester: turned on desktop mode, waited, logcat

If you need anything else, please let me know. Thanks for the help btw

[utzcoz]

> 03-18 09:39:55.027  3773  3773 E Surface : Surface::lock failed, already locked
> 03-18 09:39:55.027  3773  3773 E mflinger: failed to lock buffer
> 03-18 09:39:55.045  3773  3773 E Surface : Surface::lock failed, already locked
> 03-18 09:39:55.045  3773  3773 E mflinger: failed to lock buffer
> 03-18 09:39:55.057  3773  3773 E Surface : Surface::lock failed, already locked
> 03-18 09:39:55.057  3773  3773 E mflinger: failed to lock buffer
> 03-18 09:39:55.128  3773  3773 E Surface : Surface::lock failed, already locked
> 03-18 09:39:55.128  3773  3773 E mflinger: failed to lock buffer
> 03-18 09:39:55.140  3773  3773 E Surface : Surface::lock failed, already locked
> 03-18 09:39:55.140  3773  3773 E mflinger: failed to lock buffer
> 03-18 09:39:55.173  3773  3773 E Surface : Surface::lock failed, already locked
> 03-18 09:39:55.173  3773  3773 E mflinger: failed to lock buffer
> 03-18 09:39:55.221  3773  3773 E Surface : Surface::lock failed, already locked

> 03-18 09:39:55.221  3773  3773 E mflinger: failed to lock buffer

From the log file, the current critical failed reason is to try to lock the buffer that locked before.

The possible reason that comes to mind is the mclient request to lock the buffer, but doesn't

request to unlockAndPost before the next lock request.  I check the code base you use, and it

disables the debug flag of mflinger, so some request logs don't log, maybe you should

enable the debug flag, and rebuild the system, to get more log. The code should be modified

is here: https://github.com/deepak-divakar/mflinger/blob/maru-lineage-17.1/src/mflinger/mflinger.cpp#L43,

you should change it to 1.

Another possible reason is that the buffer allocated by mflinger is locked by another component

of SurfaceFlinger. I am not sure about it, because it doesn't occur in common situations. Maybe

you also could add a log statement to Surface::lock, such as ALOGD("Surface::lock"), to check

the lock invoking to see whether there are other lock requests beside mflinger's.

After that, could you re-grab logcat info just like last time, and send it to here?

To view this discussion on the web visit https://groups.google.com/d/msgid/maru-os-dev/0617c00f-a6c8-41d9-88c4-f86448fe3368n%40googlegroups.com.

[utzcoz]

Sorry, the debug flag is enabled by myself locally for testing purposes.

[T M]

Done. Log is attached. "Surface::lock called" is the log message printed when Surface::lock is called.

[utzcoz]

03-18 17:42:18.845  3757  3757 D mflinger: Lock buffer request!
03-18 17:42:18.845  3757  3757 D mflinger: [L] n: 4
03-18 17:42:18.845  3757  3757 D mflinger: [L] requested id = 2
03-18 17:42:18.845  3757  3757 D Surface : Surface::lock called
03-18 17:42:18.849  2959  2959 I hwservicemanager: getTransport: Cannot find entry android.hardware.graphics.mapper@3.0::IMapper/default in either framework or device manifest.
03-18 17:42:18.849  3757  3757 W Gralloc3: mapper 3.x is not supported

// other logcat

03-18 17:42:18.884  3757  3757 D mflinger: n: 4
03-18 17:42:18.884  3757  3757 D mflinger: buf: 64
03-18 17:42:18.884  3757  3757 D mflinger: Update buffer request!
03-18 17:42:18.884  3757  3757 D mflinger: [updateBuffer] n: 12
03-18 17:42:18.884  3757  3757 D mflinger: [updateBuffer] requested id = 2
03-18 17:42:18.884  3757  3757 D mflinger: [updateBuffer] requested pos = (953, 533)
03-18 17:42:18.885  3757  3757 D mflinger: n: 4
03-18 17:42:18.885  3757  3757 D mflinger: buf: 128
03-18 17:42:18.885  3757  3757 D mflinger: Lock buffer request!
03-18 17:42:18.885  3757  3757 D mflinger: [L] n: 4
03-18 17:42:18.885  3757  3757 D mflinger: [L] requested id = 1
03-18 17:42:18.885  3757  3757 D Surface : Surface::lock called
03-18 17:42:18.907  3657  3657 I joycond : type=1400 audit(0.0:1313): avc: denied { read } for scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=netlink_kobject_uevent_socket permissive=1
03-18 17:42:19.410  3744  7310 D AudioTrack: stop(15): called with 52920 frames delivered
03-18 17:42:19.454  3757  3757 D mflinger: n: 4
03-18 17:42:19.454  3757  3757 D mflinger: buf: 128
03-18 17:42:19.454  3757  3757 D mflinger: Lock buffer request!
03-18 17:42:19.455  3757  3757 D mflinger: [L] n: 4
03-18 17:42:19.455  3757  3757 D mflinger: [L] requested id = 2
03-18 17:42:19.455  3757  3757 D Surface : Surface::lock called
03-18 17:42:19.455  3757  3757 E Surface : Surface::lock failed, already locked

03-18 17:42:19.455  3757  3757 E mflinger: failed to lock buffer

From the log, we know the mclient requests to lock the buffer with id 2, and update it, and then requests to lock the buffer with id 1.

Before the mclient requests unlockAndPost to unlock and post the buffer with id 2 to SurfaceFlinger, it requests lock for the buffer

with id 2, and it causes lock failure. The lock failure for the buffer with id 1 is the same as the buffer with id 2.

The following log is expected on my development phone:

03-13 11:28:19.919   835   835 D mflinger: Create buffer request!
03-13 11:28:19.919   835   835 D mflinger: [C] n: 8
03-13 11:28:19.919   835   835 D mflinger: [C] requested dims = (1280x720)
03-13 11:28:19.919   835   835 D mflinger: [C] 1 -- num_surfaces = 0
03-13 11:28:19.928   835   835 D mflinger: [C] 2 -- num_surfaces = 1
03-13 11:28:19.929   835   835 D mflinger: n: 4
03-13 11:28:19.929   835   835 D mflinger: buf: 32
03-13 11:28:19.929   835   835 D mflinger: Create buffer request!
03-13 11:28:19.929   835   835 D mflinger: [C] n: 8
03-13 11:28:19.929   835   835 D mflinger: [C] requested dims = (24x24)
03-13 11:28:19.929   835   835 D mflinger: [C] 1 -- num_surfaces = 1
03-13 11:28:19.930   835   835 D mflinger: [C] 2 -- num_surfaces = 2
03-13 11:28:19.931   835   835 D mflinger: n: 4
03-13 11:28:19.931   835   835 D mflinger: buf: 128
03-13 11:28:19.931   835   835 D mflinger: Lock buffer request!
03-13 11:28:19.931   835   835 D mflinger: [L] n: 4
03-13 11:28:19.931   835   835 D mflinger: [L] requested id = 2
03-13 11:28:19.945   835   835 D mflinger: n: 4
03-13 11:28:19.945   835   835 D mflinger: buf: 256
03-13 11:28:19.945   835   835 D mflinger: Unlock and post buffer request!
03-13 11:28:19.945   835   835 D mflinger: [U] n: 4
03-13 11:28:19.945   835   835 D mflinger: [U] requested id = 2
03-13 11:28:19.946   835   835 D mflinger: n: 4
03-13 11:28:19.946   835   835 D mflinger: buf: 64
03-13 11:28:19.946   835   835 D mflinger: Update buffer request!
03-13 11:28:19.946   835   835 D mflinger: [updateBuffer] n: 12
03-13 11:28:19.946   835   835 D mflinger: [updateBuffer] requested id = 2
03-13 11:28:19.946   835   835 D mflinger: [updateBuffer] requested pos = (953, 533)
03-13 11:28:19.946   835   835 D mflinger: n: 4
03-13 11:28:19.947   835   835 D mflinger: buf: 128
03-13 11:28:19.947   835   835 D mflinger: Lock buffer request!
03-13 11:28:19.947   835   835 D mflinger: [L] n: 4
03-13 11:28:19.947   835   835 D mflinger: [L] requested id = 1
03-13 11:28:19.966   835   835 D mflinger: n: 4
03-13 11:28:19.966   835   835 D mflinger: buf: 256
03-13 11:28:19.966   835   835 D mflinger: Unlock and post buffer request!

From the current log, it looks like the mclient doesn't send the unlock command to the mflinger. But the MUnlockBuffer and

MLockBuffer are called in the same method. The possible reason is the mclient encounters the exception when copying Linux surface

to shared buffer, aka the method copy_ximg_to_buffer_mlocked, in mclient.c. Could you use lxc-attach to attach

Linux to check whether the mcilent works correctly? And the mclient uses fprintf to print error information to stderr, could

you also check it?

To view this discussion on the web visit https://groups.google.com/d/msgid/maru-os-dev/cc6e9943-502f-4dff-96e0-f9c8be2bcb0cn%40googlegroups.com.

[Azkali Manad]

Hi I am another L4S devs working on MaruOS.

We tried recently to use lxc-attach here is the log we got :

1|icosa:/ # lxc-attach -n default
lxc_container: external/lxc/src/lxc/attach.c: 

lxc_attach: 749 failed to get the init pid

We didn't got any further with lxc-attach.

BUT we made some progress by using lxc-start see the attached image.

So it seems to me that mclient works and that we miss something related to configuration.

[utzcoz]

I don't have good method to debug the mclient, and it needs preetam's help to provide method to debug the mclient, or get more log. 

This weekend I will check your repository again, and see whether there are some configurations are missed., or anything I could do.

To view this discussion on the web visit https://groups.google.com/d/msgid/maru-os-dev/fbba84c9-ef7b-432e-b525-f74c08a83aeen%40googlegroups.com.

[Azkali Manad]

Hi any news ? :)

[utzcoz]

Sorry to replay too late. Could you try to fix it with a workaround method that unlocks buffer when it locks failed, and locks again after unlocking?

To view this discussion on the web visit https://groups.google.com/d/msgid/maru-os-dev/870bd3f9-e516-4bc1-825b-c039ece7353en%40googlegroups.com.

[luka...@gmail.com]

Hello, I can confirm issue on Gigaset GS290. I implemented buffer unlock if lock failed, it worked but still no image.
06-15 10:30:21.248   938   938 D mflinger: n: 4
06-15 10:30:21.248   938   938 D mflinger: buf: 128
06-15 10:30:21.248   938   938 D mflinger: Lock buffer request!
06-15 10:30:21.248   938   938 D mflinger: [L] n: 4
06-15 10:30:21.248   938   938 D mflinger: [L] requested id = 1
06-15 10:30:21.248   938   938 E Surface : Surface::lock failed, already locked
06-15 10:30:21.248   938   938 W mflinger: failed to lock buffer, trying to relock
06-15 10:30:21.253   938   938 W mflinger: buffer lock is ok

понеділок, 12 квітня 2021 р. о 18:06:44 UTC+3 utzcoz пише:

[luka...@gmail.com]

maru@stretch:/$ DISPLAY=:0 mclient
<6>intial screen config: 1280x720 508mmx286mm
<3>error mmaping buffer: Permission denied
<3>MLockBuffer failed!
<3>failed to render cursor sprite
<3>error mmaping buffer: Permission denied
<3>MLockBuffer failed!

mclient log

вівторок, 15 червня 2021 р. о 10:33:14 UTC+3 luka...@gmail.com пише:

[utzcoz]

Luka's problem looks like similar to https://github.com/maruos/maruos/issues/129. And he has found that mclient doesn't unlock buffer after mmap failed. So T M as problem maybe also related to it.

To view this discussion on the web visit https://groups.google.com/d/msgid/maru-os-dev/4980bde7-3fe5-41ee-9033-cd8c8c8e9a35n%40googlegroups.com.