In D28337#648844, @meven wrote:

Solid only sends broadcast notification and doesn't wait for any reply, thus unmounting may fail due to preview jobs not stopping in time.

That points to a solid shortcoming worth fixing. Adding a wait for apps to ask solid to wait or to wait by default for instance 20-50ms between tearDownRequested and teardownDone

It's also may be possible to repeat unmount request from solid a few times with some delays between requests to try waiting until preview jobs are stopped when unmount is requested from 'mounted devices' widget. I've tried 5 retries with 2 seconds between each one, and it worked for me. But waiting for replies to unmount notifications in solid might be preferable to retries.

Comparison of result before change and after change:

In D27703#623741, @sandsmark wrote:

lgtm.

Could you please merge this change? Or is something stopping from merging it?

In D27774#621379, @yurchor wrote:

There are other pending requests that were pending uncommitted. Would you like to push them into the repo first?

Updated change to obtain information only about last device mounted over specific mount path. At least filesystem may be different in such case.

In D27650#618492, @davidedmundson wrote:

Can I have your full name + email address please.

Got rid of two disconnects and updated summary formatting.

In D27650#618207, @davidedmundson wrote:

And this used QWeakPointer leads to premature destruction of object m_layout points to.

Do you have commit access?

Fix consists of following line:

Uploaded updated change

In D27650#617550, @davidedmundson wrote:

This function takes a plain pointer and wraps it into weak shared pointer.

That's QWeakPointer.

QPointer is something else that doesn't have an equivalent in stdlib.
It takes a QObject, then QObject has a special hook to unset watching QPointers to nullptr in QObject::~QObject()

Could you please take a look at this change as well?

Here's screenshot of empty Science and Development groups being visible before this change is applied:

Here's how empty "Other Settings Modules" entry looks when selected:

In D27357#610605, @broulik wrote:

Neither the XSync nor the windows backend explicitly call resumingFromIdle in simulateUserActivity, so I think this should be fine.
However, I don't know if that won't indirectly trigger it if the session was idle? Maybe we need to check if the session was idle and only then emit the signal.

Abandoning in favour of D27279 and D27357

I think I found source of infinite recursion.

I've managed to reproduce it and take a backtrace. It's an infinite recursion. Eventually stack's end is reached, although it takes some time to do it. Here's a piece of backtrace I got:

I've tested this patch in it's current form, and powerdevil no longer crashes for me on launch too. How can I reproduce crash in resume on idle? Can it be done in virtual machine?

Thanks, I'll try reworking KIdleTime.

Updated remaining conditions

In D27278#608788, @broulik wrote:

Makes sense, this can go into 5.18 branch.
Do I need to land this for you?

In D27278#608791, @broulik wrote:

There seem to be a bunch of additional m_helper.isNull() that could be ported to be consistent?

Fixed superfluous parenthesis in one of conditions.

I've hit this crash trying to use KDE via x2go (https://wiki.x2go.org/doku.php) with both x2go client and server running in two separate VMs.

In D24653#547385, @apol wrote:

Please submit to master.