Background / PDFs rendering Incorrectly when switching between recent documents.

[corigne]

Device: Remarkable 2 (Ordered and received no more than 2 weeks prior.)
Version: 2.15.1.1189-patch_39.2.1-0-ge776ce3

Conditions: Happens regardless of left-handedness or right-handedness. Does not appear on the base OS, only with tweaked binary. Is reproducible. When in a notebook or PDF, switch to a recent notebook or PDF using two finger swipe or the recent documents menubar icon. Part of the screen does not render correctly on the document switch. The writing renders correctly, but the template background and PDF image do not. The side of the render affected is the side on which the toolbar is being rendered, according to the handedness setting. I have tried uninstalling the tweaks and reinstalling the tweaks. I have attached a video and photo for reference.

I am running Oxide, and followed the appropriate steps as detailed in the installation guide for setting up Xochitl to run correctly with Oxide to avoid rendering errors cause by duplicate Xochitl processes. I do not believe it is related to having oxide installed, as this occurs in the demo as well. If the error is possibly related to oxide, I would imagine other apps would be affected, but I have not observed such behavior in Koreader or any other applications I use.

I checked known bugs, but I didn't see anything that seemed to match this issue.

remarkable_IZtXUWnD.mp4

[ddvk]

did you try without Oxide, with just xochitl running?

[Eeems]

did you try without Oxide, with just xochitl running?

Since Oxide doesn't do anything with the screen after handing off to a client. It's more likely that this would be rm2fb related if it's not caused by one of the changed in your binary patches. That or somehow there is a second xochitl instance running, but that usually shows differently.

[corigne]

did you try without Oxide, with just xochitl running?

I did try it without oxide. I initially had only the tweak for about two days before I installed Oxide about a week ago. I didn't pay it much attention initially though. I can try disabling Oxide again and only run the tweaks and see if the behavior persists.

[corigne]

did you try without Oxide, with just xochitl running?

Since Oxide doesn't do anything with the screen after handing off to a client. It's more likely that this would be rm2fb related if it's not caused by one of the changed in your binary patches. That or somehow there is a second xochitl instance running, but that usually shows differently.

I can confirm, this is not the same behavior as is presented when there are two instances of Xochitl running. I've had that bug before and it is very distinct.

[MahirAbbas]

i've had that bug before. I reset the remarkable, and only installed ddvk hacks and the bug disapeared. I think this is likely due to multiple apps running

[corigne]

i've had that bug before. I reset the remarkable, and only installed ddvk hacks and the bug disapeared. I think this is likely due to multiple apps running

I was planning on testing it today when I'm free. I don't know enough about the inner workings of the remarkable to know if running Xochitl with other apps through a launcher like Oxide affects the framebuffer behavior. @Eeems seems sure that Oxide itself shouldn't be impacting the rendering.

Perhaps multiple apps interfacing with the framebuffer at once is the issue, but I'm not sure how to test this. I would be open to suggestions.

[Eeems]

i've had that bug before. I reset the remarkable, and only installed ddvk hacks and the bug disapeared. I think this is likely due to multiple apps running

I was planning on testing it today when I'm free. I don't know enough about the inner workings of the remarkable to know if running Xochitl with other apps through a launcher like Oxide affects the framebuffer behavior. @Eeems seems sure that Oxide itself shouldn't be impacting the rendering.

Perhaps multiple apps interfacing with the framebuffer at once is the issue, but I'm not sure how to test this. I would be open to suggestions.

Double check to make sure that the xochitl service is stopped with systemctl status xochitl.

I like to also use htop to look at running processes to make sure that the only xochitl processes are under tarnish. You can install htop with opkg install htop. You can then toggle showing parent/child relationships with f5, and hide threads with shift-h.

[corigne]

i've had that bug before. I reset the remarkable, and only installed ddvk hacks and the bug disapeared. I think this is likely due to multiple apps running

I was planning on testing it today when I'm free. I don't know enough about the inner workings of the remarkable to know if running Xochitl with other apps through a launcher like Oxide affects the framebuffer behavior. @Eeems seems sure that Oxide itself shouldn't be impacting the rendering.
Perhaps multiple apps interfacing with the framebuffer at once is the issue, but I'm not sure how to test this. I would be open to suggestions.

Double check to make sure that the xochitl service is stopped with systemctl status xochitl.

I like to also use htop to look at running processes to make sure that the only xochitl processes are under tarnish. You can install htop with opkg install htop. You can then toggle showing parent/child relationships with f5, and hide threads with shift-h.

So, I have already checked the service status just to make sure I configured the tablet correctly. The xochitl process is disabled inactive(dead). As far as htop, I am only getting one instance of xochitl in the process tree, and it is listed as a child of tarnish.

[Eeems]

That looks correct to me. My gut still says this is more likely to be an issue with rm2fb than with ddvk-hacks. But it would still be good to see if you can replicate outside of Oxide:

systemctl stop tarnish
systemctl start xochitl

If you can still replicate there, the next step would be to test without rm2fb.

systemctl stop xochitl
systemctl stop rm2fb
systemctl start xochitl

After all of this you can get back to a normal working state by either rebooting or running the following:

systemctl stop xochitl
systemctl start rm2fb
systemctl start tarnish

[corigne]

@ddvk I disabled tarnish, stopped the tarnish service, enabled xochitl, and started the xochitl service, and I am still experiencing the behavior. Here is an htop of the current processes for confirmation:

[Eeems]

I would not recommend enabling/disabling as part of your testing for temporary changes. You only need to start/stop services. Enable/disable changes what happens when you reboot the device, start/stop does not.

[corigne]

I would not recommend enabling/disabling as part of your testing for temporary changes. You only need to start/stop services.

Noted, I hadn't considered that. You're right though, enable/disable just adds/removes the symlinks so that makes sense. Still, same effect with extra (unnecessary steps).

Edit: I imagine since this shows the same behavior, I can probably just turn oxide back on in the meantime.

[Eeems]

I would not recommend enabling/disabling as part of your testing for temporary changes. You only need to start/stop services.

Noted, I hadn't considered that. You're right though, enable/disable just adds/removes the symlinks so that makes sense. Still, same effect with extra (unnecessary steps).

Edit: I imagine since this shows the same behavior, I can probably just turn oxide back on in the meantime.

I'd recommend testing without rm2fb and oxide as well: #518 (comment)

[corigne]

I would not recommend enabling/disabling as part of your testing for temporary changes. You only need to start/stop services.

Noted, I hadn't considered that. You're right though, enable/disable just adds/removes the symlinks so that makes sense. Still, same effect with extra (unnecessary steps).
Edit: I imagine since this shows the same behavior, I can probably just turn oxide back on in the meantime.

I'd recommend testing without rm2fb and oxide as well: #518 (comment)

On it. Just saw your previous update. Wil get back to you shortly.

[corigne]

That looks correct to me. My gut still says this is more likely to be an issue with rm2fb than with ddvk-hacks. But it would still be good to see if you can replicate outside of Oxide:

systemctl stop tarnish
systemctl start xochitl

If you can still replicate there, the next step would be to test without rm2fb.

systemctl stop xochitl
systemctl stop rm2fb
systemctl start xochitl

After all of this you can get back to a normal working state by either rebooting or running the following:

systemctl stop xochitl
systemctl start rm2fb
systemctl start tarnish

@Eeems not sure if this is intended behavior, but stopping rm2fb and starting xochitl results in a blank screen. Nothing changes after the point when I stop the framebuffer service.

If I restart rm2fb and start xochitl or oxide, the tablet functions normally. Is the tweaked binary reliant on the framebuffer service?

[Eeems]

Try running xochitl manually instead with xochitl. It sounds like our logic for detecting rm2fb on start of the xochitl service is broken and needs to be fixed.

[corigne]

Try running xochitl manually instead with xochitl. It sounds like our logic for detecting rm2fb on start of the xochitl service is broken and needs to be fixed.

It looks like the logic detecting rm2fb is in the binary itself, because even with the rm2fb service disabled completely in systemd, manually running xochitl doesn't result in any screen updates. After starting the framebuffer again the behavior is as expected.

[Eeems]

Oh, run unset LD_PRELOAD first.

[corigne]

It'll be a few minutes before I can get back to you but I will try this ASAP.

[corigne]

Oh, run unset LD_PRELOAD first.

This did not change anything. No screen response when running xochitl manually or by starting the service while the framebuffer server is down.

[Eeems]

Oh, run unset LD_PRELOAD first.

This did not change anything. No screen response when running xochitl manually or by starting the service while the framebuffer server is down.

Umm, that's odd. It should have. But I don't have a rM2 to test with. The issue is that the LD_PRELOAD variable is still somehow set, which is causing the rm2fb client to load. I would have expected doing the following to have worked:

systemctl stop xochitl
systemctl stop tarnish
systemctl stop rm2fb
unset LD_PRELOAD
xochitl

You can try those steps again, but instead of running xochitl at the end, run /usr/bin/xochitl

[corigne]

Oh, run unset LD_PRELOAD first.

This did not change anything. No screen response when running xochitl manually or by starting the service while the framebuffer server is down.

Umm, that's odd. It should have. But I don't have a rM2 to test with. The issue is that the LD_PRELOAD variable is still somehow set, which is causing the rm2fb client to load. I would have expected doing the following to have worked:

systemctl stop xochitl
systemctl stop tarnish
systemctl stop rm2fb
unset LD_PRELOAD
xochitl

You can try those steps again, but instead of running xochitl at the end, run /usr/bin/xochitl

This worked.

With the framebuffer server disabled and using the binary in /usr/bin the behavior does not occur. Is there a way to use the tweaks, and I guess more importantly tarnish/oxide and other apps without having the framebuffer running?

I did a which xochitl just for kicks, and the result was /opt/bin/xochitl whereas you had me run /usr/bin/xochitl.

Out of curiosity, what is the difference?

[Eeems]

With the framebuffer server disabled and using the binary in /usr/bin the behavior does not occur. Is there a way to use the tweaks, and I guess more importantly tarnish/oxide and other apps without having the framebuffer running?

rm2fb is required for third party applications to use the screen. Without it, there is no way to display on the screen due to how the framebuffer driver works on the reMarkable 2.

I did a which xochitl just for kicks, and the result was /opt/bin/xochitl whereas you had me run /usr/bin/xochitl.

Out of curiosity, what is the difference?

That's the helper script provided by toltec to automate some things to make xochitl play nice with other packages: https://github.com/toltec-dev/toltec/blob/stable/package/xochitl/xochitl

Since this is not an issue with ddvk-hacks, and is instead a bug with rm2fb, I'd recommend closing this issue and opening a new one on the remarkable2-framebuffer repository that links back to this.

[corigne]

Will do. Thanks for the help so far. Hopefully, this goes toward a useful improvement!

[corigne]

Closing issue and moving to rm2fb repo.

[Eeems]

For anybody who wants to follow the thread after finding this: ddvk/remarkable2-framebuffer#122