Bug#974172: libmutter-7-0: Cannot unlock screen with Wayland on arm64, keybard and mouse unresponsive

Gali Drudis-Sole galids at gmail.com
Mon Nov 16 19:28:07 GMT 2020

On Fri, Nov 13, 2020 at 1:54 PM Simon McVittie <smcv at debian.org> wrote:

> Control: retitle -1 libmutter-7-0: Cannot unlock screen with Wayland on
> arm64, keybard and mouse unresponsive
> On Thu, 12 Nov 2020 at 00:20:03 +0100, Gali Drudis-Sole wrote:
> > On Wed, 11 Nov, 2020 at 10:32, Simon McVittie <smcv at debian.org> wrote:
> >     This works fine for me, and presumably other GNOME users, so there
> must be
> >     something specific to your system that is relevant.
> >
> > Good. I hope to find it.
> One elephant in the room is that you're on an arm64 system, which is
> certainly unusual for a GNOME desktop. We've had a report on IRC that
> another arm64 user (with a different GPU) is seeing a similar bug.

Great. That looks like a good starting point.

> > Nov 11 23:04:29 mobian gsd-usb-protect[2319]: Error calling USBGuard
> DBus to
> > change the protection after a screensaver event:
> > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.usbguard1
> > was not provided by any .service files
> This is not a problem and can safely be ignored.
> > Nov 11 23:04:29 mobian gnome-shell
> > [2141]: Bogus presentation time 0 travelled back in time, using current
> time.
> This might indicate a problem, I'm not sure.
> > Sorry, that was my error when reporting the bug. Version 3.38.0-2 DOES
> > but upgrading to the current testing version (3.38-1.2) DOES NOT WORK.
> Does 3.38.1-3 from experimental make any difference? That version has the
> latest changes from the upstream gnome-3-38 branch, which will be released
> in 3.38.2 at some point.

I've upgraded libmutter-7-0 and mutter-common to 3.38.1-3 from
experimental, but there was no difference. The screen can be unlocked if it
is not blanked, but it cannot be unlocked after blanking.

> If 3.38.1-3 doesn't solve this, since you've been able to narrow this
> down to two relatively close versions, it would be useful for someone
> with appropriate hardware (I don't have this) to do a `git bisect`
> between the good version and the bad version, to isolate which specific
> change made this regress - that would make it a lot more likely that
> someone can figure out the root cause.

I will give it a try.

>     smcv

Galí Drudis Solé
  galids at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20201116/195da598/attachment-0001.html>

More information about the pkg-gnome-maintainers mailing list