Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 17242045db7fe32a02b655bc64304f3eb157099c
https://github.com/WebKit/WebKit/commit/17242045db7fe32a02b655bc64304f3eb157099c
Author: Adrian Perez de Castro <ape...@igalia.com>
Date: 2025-08-29 (Fri, 29 Aug 2025)
Changed paths:
M Source/WTF/wtf/PlatformWPE.cmake
A Source/WTF/wtf/android/RefPtrAndroid.cpp
A Source/WTF/wtf/android/RefPtrAndroid.h
M Source/WebKit/Platform/IPC/ArgumentCoders.h
M Source/WebKit/Platform/IPC/Attachment.h
M Source/WebKit/Platform/IPC/Connection.h
A Source/WebKit/Platform/IPC/android/ArgumentCodersAndroid.cpp
A Source/WebKit/Platform/IPC/android/ArgumentCodersAndroid.h
M Source/WebKit/Platform/IPC/unix/ArgumentCodersUnix.cpp
M Source/WebKit/Platform/IPC/unix/ConnectionUnix.cpp
M Source/WebKit/Platform/IPC/unix/UnixMessage.h
M Source/WebKit/PlatformWPE.cmake
M Source/WebKit/SourcesWPE.txt
Log Message:
-----------
[WPE][IPC] Add support for AHardwareBuffer attachments
https://bugs.webkit.org/show_bug.cgi?id=297592
Reviewed by Carlos Garcia Campos.
When building for Android, make message attachments a variant to
allow passing both UnixFileDescriptor or AHardwareBuffer through
IPC. This involved the following related changes in how Attachment
objects are handled: a new AttachmentInfo::m_type member indicates
whether an attachment is an UnixFileDescriptor or an AHardwareBuffer,
and alternative code paths are needed used to act them.
The trickier part of actually sending and receiving AHardwareBuffer
objects: we cannot "open up" the inside of buffer, and passing them
around needs to be done with AHardwareBuffer_sendHandleToUnixSocket()
and AHardwareBuffer_recvHandleFromUnixSocket(). These function will
themselves send/receive a message for each AHardwareBuffer, out of
our control. Therefore, on the writing end:
- When preparing to send a message, note the amount of buffer
handles in a new MessageInfo::m_validHardwareBufferCount
member (invalid/null handles are not sent).
- Store the valid AHardwareBuffer handles to be sent later and
send the message (sans buffer handles) in the usual fashion.
- Send the AHardwareBuffer handles right after the message.
At the end of Connection::sendOutputMessage(), store the buffer
handles Connection::m_outgoingHardwareBuffers, and call
::sendOutgoingHardwareBuffers().
- The ::sendOutgoingHardwareBuffers() function attempts to send
as many handles as it can right away. If the operation would
block, it makes use of the socket monitor to re-schedule calling
itself when the socket is ready again for sending. This is
repeated until there are no more buffers left.
On the receiving end things are a little bit trickier because the
socket monitor is always armed to invoke Connection::readyReadHandler()
and this means that we cannot start it independently to handle only
retiring AHardwareBuffer handles from the socket -- we need to thread
the code to retire buffer handles into the existing functions:
- The ::readyReadHandler() function may be invoked either to
retry sending the "main" message, or to retry sending buffer
handles. The Connection::m_pendingIncomingHardwareBufferCount
is used to determine which code path to follow.
- First, if there are no pending buffer handles to receive, a
message is read. At the moment the code assumes that message
are always read in their entirety, which is the case with
SOCK_SEQPACKET.
- The read message up to this point includes both the payload and
file descriptors. The MessageInfo in the header of the message
indicates how many AHardwareBuffer handles we need to retire.
This is saved in Connection::m_pendingIncomingHardwareBufferCount
before calling ::receiveIncomingHardwareBuffers().
- Then ::receiveIncomingHardwareBuffers() attempts retiring from
the socket as many buffer handles as it can. If reading handles
would block, the function returns immediately, and will rely on
the next call to ::readyReadHandler() -- as the socket monitor
is always kept armed and invoke it for reading.
- When execution reaches ::readyReadHandler() again and, crucially,
there are still AHardwareBuffer handles pending to be retired from
the socket, it will call again ::receiveIncomingHardwareBuffers()
to resume the task. When all the handles have been retired from
the socket we still need a call to ::processMessage() at this point,
but without going first through trying to read another complete
message.
* Source/WTF/wtf/PlatformWPE.cmake:
* Source/WTF/wtf/android/RefPtrAndroid.cpp: Added.
(WTF::DefaultRefDerefTraits<AHardwareBuffer>::refIfNotNull):
(WTF::DefaultRefDerefTraits<AHardwareBuffer>::derefIfNotNull):
* Source/WTF/wtf/android/RefPtrAndroid.h: Added.
* Source/WebKit/Platform/IPC/ArgumentCoders.h:
* Source/WebKit/Platform/IPC/Attachment.h:
* Source/WebKit/Platform/IPC/Connection.h:
* Source/WebKit/Platform/IPC/android/ArgumentCodersAndroid.cpp: Added.
(IPC::ArgumentCoder<UnixFileDescriptor>::decode):
(IPC::ArgumentCoder<RefPtr<AHardwareBuffer>>::encode):
(IPC::ArgumentCoder<RefPtr<AHardwareBuffer>>::decode):
* Source/WebKit/Platform/IPC/android/ArgumentCodersAndroid.h: Added.
* Source/WebKit/Platform/IPC/unix/ArgumentCodersUnix.cpp:
* Source/WebKit/Platform/IPC/unix/ConnectionUnix.cpp:
(IPC::AttachmentInfo::AttachmentInfo):
(IPC::AttachmentInfo::type const):
(IPC::AttachmentInfo::setType):
(IPC::Connection::processMessage):
(IPC::Connection::readyReadHandler):
(IPC::Connection::platformCanSendOutgoingMessages const):
(IPC::Connection::sendOutputMessage):
(IPC::Connection::sendOutgoingHardwareBuffers):
(IPC::Connection::receiveIncomingHardwareBuffers):
* Source/WebKit/Platform/IPC/unix/UnixMessage.h:
(IPC::MessageInfo::MessageInfo):
(IPC::MessageInfo::hardwareBufferCount const):
(IPC::UnixMessage::UnixMessage):
* Source/WebKit/PlatformWPE.cmake:
* Source/WebKit/SourcesWPE.txt:
Canonical link: https://commits.webkit.org/299311@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
