Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconnect HDMI display leads to different errors, unable to start File Manager and broken settings for File Manager. #298

Open
qrp73 opened this issue Sep 28, 2024 · 6 comments

Comments

@qrp73
Copy link

qrp73 commented Sep 28, 2024

As we know reconnect HDMI leads to a different kind of errors in the desktop environment.

I just reconnected HDMI display and after this I'm unable to start File Manager.

When I start File Manager, nothing happens. I can see in btop that a new process "pcmanfm" is started, it consume about 21MB memory and don't consume CPU. But the window don't appears. It just hidden and remains in the memory.

Starting File Manager again leads to add next instance of the process, but the window don't appears. And all these "pcmanfm" processes remains in the memory.

When I tried to kill sub-process systemd->sh->wfrespawn->pcmanfm, the file manager window appears, but the settings are broken (Icon view instead of compact view). After that, I can start File Manager, but each time it opens with broken settings. I set Folder View Mode->Compact View, close window and start File Manager again, but it is shown with Icon View again.

20240928_21h05m11s_grim

Update: after system reboot, the settings for File Manager is restored.

I have video=HDMI-A-1:[email protected] option in cmdline.txt to keep display resolution when the cable is not connected, but it don't helps.

@popcornmix
Copy link

We have spent the last few weeks testing pcmanfm with a hacked kernel that simulates hdmi cable being unplugged and replugged every 10 seconds. Some memory leaks have been fixed. But I've not seen a behaviour matching yours.

There will be a new bookworm image soon that defaults to using labwc rather than wayfire which may improve things. You can switch yourself using raspi-config and advanced/wayland menu.

vc4.force_hotplug=1 is likely to work as a workaround as that prevents the desktop seeing the unplug at all.

@qrp73
Copy link
Author

qrp73 commented Sep 28, 2024

I encountered a peculiar issue with pcmanfm during the HDMI reconnection. Typically, this leads to a crash, but this time, it resulted in very unusual behavior from pcmanfm. I believe this may indicate a bug within the application, which is why I am reporting it here.

It seems that something is entering a deadlock in pcmanfm, preventing it from starting and causing it to wait indefinitely for an event. There are no error messages in dmesg, and I am unsure how to check if there are internal logs for pcmanfm.

vc4.force_hotplug=1

thanks I will try it

There will be a new bookworm image soon that defaults to using labwc rather than wayfire which may improve things. You can switch yourself using raspi-config and advanced/wayland menu.

it's a good news, but I prefer to stay with wayland

@lurch
Copy link
Collaborator

lurch commented Sep 30, 2024

There will be a new bookworm image soon that defaults to using labwc rather than wayfire which may improve things. You can switch yourself using raspi-config and advanced/wayland menu.

it's a good news, but I prefer to stay with wayland

Even better news: labwc is still wayland 🙂 Wayfire and Labwc are both Wayland compositors, and we've found labwc to work much better on the Raspberry Pi than wayfire (which is why we're switching to it).

@qrp73
Copy link
Author

qrp73 commented Oct 1, 2024

I like the wobbly effects of Wayfire. The only issue with Wayfire is that there is a problem with window position and size because it doesn't allow apps to change them. But I’ve gotten used to it.

What is the advantage of Labwc?

@ghollingworth
Copy link
Contributor

Wayfire is a massive hack... Well we've had to massively hack it to get it to work for us! The issue is that Wayfire uses wlroots, but doesn't use the scene graph capability and instead does all it's composition directly through the GPU. This means we couldn't use it on the older platforms because you cannot share the GPU between the compositor and the application (because, if you run out of CMA it will crash the compositor, kicking you out of your session).

LabWC uses the scene graph capability of wlroots, and this means we can do a lot of optimization in the compositor. It also means we will use the same compositor across all of Pi 1,2,3,4,5. For example, you can now use Pi Connect on all devices...

Gordon

@qrp73
Copy link
Author

qrp73 commented Oct 31, 2024

just tried labwc. It has no wobbly effect, but it runs pretty nice and I like it, windows are very responsive and there is definitely better situation with memory consumption and memory leaks. Good job :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants