Bug 53181

Is this still an issue?

It is. Reproduced with Weston-DRM, invoked with ./weston -i5. Got the lock screen straight-away after it dimmed the first time. Second time, however, had to mouse like crazy, when cursor was in lower-right corner of display. Resolution was set at hd1080.

This is still an issue on master. It appears to be exacerbated when a graphical workload is being executed at time of screen lock, perhaps proportional to complexity of the workload.

Looking at the title of this bug, just to be clear, is this about:
- mousing over a magic location unlocks the desktop *without* pressing the green button, or
- mousing over whatever is needed to see the green button?
You are describing the latter, but the title says the former. The former would probably be a weston-desktop-shell crash, which would be evident in the weston log, and easier to debug.

Can you observe, whether weston-screensaver gets executed or not, and does your installation have an outdated copy of the weston-screensaver binary somewhere?

There is something going on with the unlock dialog for sure, originally it used to be movable and resizeable, and I don't think it is anymore. The delay of 30 sec to 1 min would hint towards the panel clock updating, and if that indeed is related, there's some serious confusion in the code. Could you make the panel clock have seconds, so that it will update every second, and see if that makes any difference? I think there should be a weston.ini setting for it.


Does comment #2 mean that the cursor was stuck in the lower-right corner? Or just the cursor position, when the idle timeout was hit?

(In reply to comment #4)
> Looking at the title of this bug, just to be clear, is this about:
> - mousing over a magic location unlocks the desktop *without* pressing the
> green button

Not quite-- I'll modify the ticket title to clarify.

> - mousing over whatever is needed to see the green button?

Correct-- that what I was attempting to describe in the original filing.

> You are describing the latter, but the title says the former. The former
> would probably be a weston-desktop-shell crash, which would be evident in
> the weston log, and easier to debug.
> 
> Can you observe, whether weston-screensaver gets executed or not, and does
> your installation have an outdated copy of the weston-screensaver binary
> somewhere?

Sure, I'll address in next post.

> 
> There is something going on with the unlock dialog for sure, originally it
> used to be movable and resizeable, and I don't think it is anymore. The
> delay of 30 sec to 1 min would hint towards the panel clock updating, and if
> that indeed is related, there's some serious confusion in the code. Could
> you make the panel clock have seconds, so that it will update every second,
> and see if that makes any difference? I think there should be a weston.ini
> setting for it.
> 
> 
> Does comment #2 mean that the cursor was stuck in the lower-right corner? Or
> just the cursor position, when the idle timeout was hit?

Just the cursor, when the idle timeout was hit.

(In reply to comment #4)
> Can you observe, whether weston-screensaver gets executed or not, and does
> your installation have an outdated copy of the weston-screensaver binary
> somewhere?

I typically do not build weston-screensaver. For this case, I did re-build weston with the screensaver and modify weston.ini accordingly. The screensaver does indeed execute and does not crash or report anything strange. Reported issue applies when weston-screensaver is running. In fact, the issue is more pronounced with screensaver: complete rendering hang until the lock button appears.

This calls into question my mention of "magic mouse coordinates" for sure.

> 
> There is something going on with the unlock dialog for sure, originally it
> used to be movable and resizeable, and I don't think it is anymore. The
> delay of 30 sec to 1 min would hint towards the panel clock updating, and if
> that indeed is related, there's some serious confusion in the code. Could
> you make the panel clock have seconds, so that it will update every second,
> and see if that makes any difference? I think there should be a weston.ini
> setting for it.

Alas, no weston.ini config option that I could identify, so I tested with "stock" weston (updating every minute) and with locally-modified weston that has a panel displaying %H:%M:%S includes and a redraw_handler timer firing every second.

Same behavior seen for each weston build.

At some point between filing and the present, this bug seems to have been remedied. Closing as "worksforme."