Closed Bug 1694258 Opened 3 years ago Closed 3 years ago

[wayland] Only shows black screen in weston kiosk mode on pinephone/arm


(Core :: Graphics, defect)






(Reporter: fabrice, Unassigned)


(Blocks 1 open bug, )



  • cross compile Firefox for aarch64-unknown-linux-gnu (using the sysroot from --enable-bootstrap).
  • push firefox to a pinephone
  • launch weston with the kiosk-shell (weston


  • firefox opens in full screen.


  • the screen turns full black (it's gray when no app runs).

Here's the log:

There's some crash in glxtest that might be related to bug 1676883, see No GPUs detected via PCI on ARM in the logs.

For the record: this appears to work fine on desktops/laptops as well as the desktop mode of weston on the pinephone.

Blocks: wayland
See Also: → 1676883
Summary: No GPUs detected via PCI on ARM → [wayland] Only shows black screen in weston kiosk mode on pinephone/arm


My rough understanding of the situation (thanks @marius.vlad0 for the detailed investigation!) is this:

We send a keyboard.enter event to an unmapped surface.
This somehow leads Firefox to commit that surface without a buffer but with a frame callback.
Since that surface is not visible, the compositor doesn't ever send back a wl_callback.done().

The first issue is that kiosk-shell send a keyboard.enter to an unmapped surface. This certainly isn't useful in general, although I don't think it's a protocol correctness violation. In any case, !564 fixes this.
This stray enter event uncovers the second issue, which is that Firefox sends a frame callback when committing without a buffer and effectively blocks on that callback signalling. If the stray enter, which seems to trigger this, is in fact not a protocol correctness violation, then Firefox's behavior is also independently problematic and should also be fixed.

So we should fix that behaviour indeed.

Severity: -- → S3
Flags: needinfo?(aosmond)

This is something that Martin or I should probably look into as it's quite Wayland specific.

Flags: needinfo?(aosmond) → needinfo?(stransky)

Sounds good - thanks.

That's Weston specific issue, right? I wonder if the commit is for SW renderer or VSync. Robert, do we have the VSync with empty commits enabled? I think we also do the wl_surface commit somewhere with actual wl_buffer attach.

Flags: needinfo?(stransky) → needinfo?(robert.mader)

Following up on

I do think that sending keyboard-enter to an unmapped surface is very close to protocol violation because I believe that unmapped surfaces should not be able to gain or have input focus.

Given that:

  • this is a very close call on whether it's valid behaviour of the compositor or not
  • it's now fixed in weston
  • we haven't seen that from any other compositors yet

I'd say let's close this as fixed by

Closed: 3 years ago
Flags: needinfo?(robert.mader)
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.