On Fri, 16 Oct 2026 11:29:54 GMT, Sergey Bylokhov <[email protected]> wrote:
>> Ubuntu 26.10 may send multiple stream format events, and our screen capture >> code doesn't handle it correctly: >> >> `onStreamParamChanged()` calls blocking `pw_thread_loop_signal(..., TRUE)` >> and expects the corresponding `pw_thread_loop_accept` call. >> However, `pw_thread_loop_accept` is only called while waiting for the >> initial format, so a subsequent event can block PipeWire thread indefinitely. >> >> --- >> >> So the minimal fix would be to replace it with a non-blocking >> `pw_thread_loop_signal(..., FALSE)` call and remove the corresponding accept >> call(with some other minor changes). >> >> However, this alone leaves several other issues to address: >> >> - The `isAllDataReady` check and the wait now run under the same lock, >> preventing lost wakeups. >> - Added a 10s shared timeout for format negotiation and frame capture, so >> missing events don't block java indefinitely. >> - After capturing a frame, `onStreamProcess()` now returns any additional >> buffers to PipeWire so they can be reused while the stream is still active, >> e.g., while waiting for frames from other screens. >> - Requeuing a PipeWire buffer allows its pixel data to be reused before we >> copy it to the Java array. The `captureDataPixbuf` now always owns pixel >> data. >> - `NULL` checks were added for pixbuf creation and scaling. >> - Capture cleanup and stream deactivation now run under the same PipeWire >> loop lock, preventing callbacks from observing partially reset capture state. >> - Other cleanup improvements (pw context destruction, captureDataPixbuf >> unref) >> - A valid restore token can be rejected incorrectly for uiScale other than 1 >> for non standard resolutions(e.g. rounding for height on VirtualBox screen >> `1359` > `680` > `1360` with uiScale 2). >> Now it uses native screen bounds directly. >> >> >> Testing looks good. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 586: > >> 584: while (!hasPipewireFailed && !data->hasFormat) { >> 585: int result = fp_pw_thread_loop_timed_wait_full(pw.loop, >> captureDeadline); >> 586: if (result < 0) { > > There might still be a chance that hasFormat was initialized in this case, so > should it be rechecked before return false? This can happen right at the deadline, when the format arrives as the wait times out (and 10s is a very generous timeout). There is no time left to wait for frames in this case, since the same deadline is shared with the frame capture. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33384#discussion_r4296646753
