We only want camera preview use case to use the same padding as
BO_USE_HW_VIDEO_ENCODER. Previously we check this by BO_USE_SCANOUT
flag. This would cause some format issues in CTS drm tests. This patch
updates CL:3551188 to check for BO_USE_CAMERA_WRITE flag as well.
BUG=b:227983122
TEST=check camera is normal on kukui
TEST=android.media.cts.MediaDrmClearkeyTest#* pass on kukui
Change-Id: I1606b677678dfafc6331713f67d327a2b6030394
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3574581
Tested-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Miguel Casas-Sanchez <mcasas@chromium.org>
Reviewed-by: Miguel Casas <mcasas@google.com>
Reviewed-by: Kazuhiro Inaba <kinaba@chromium.org>
Tested-by: Kazuhiro Inaba <kinaba@chromium.org>
Commit-Queue: Hsin-Yi Wang <hsinyi@chromium.org>
minigbm clients use the SCANOUT flag whenever they want the
minigbm-allocated buffers to be promoted to overlays. Mediatek doesn't
support YUV overlays, so remove the SCANOUT flag.
BUG=b:224698291
TEST=emerge on elm, emerge and deploy on kukui/jacuzzi
Change-Id: If3ee2fb925c7e729269c31caab991bb0bc56b0de
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3555233
Tested-by: Hsin-Yi Wang <hsinyi@chromium.org>
Feels: Hsin-Yi Wang <hsinyi@chromium.org>
Auto-Submit: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Miguel Casas <mcasas@google.com>
Commit-Queue: Hsin-Yi Wang <hsinyi@chromium.org>
Since CL:3515652, preview under photo mode no longer uses hw video
encoder. This results in the wrong padding set in minigbm. Make camera
preview mode to use the original padding by detecting the
GRALLOC_USAGE_HW_COMPOSER (BO_USE_SCANOUT) flag.
BUG=b:224698291
TEST=check camera preview on krane
Change-Id: I299886a8f2106678f19ffff308331afec9627614
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3551188
Tested-by: Hsin-Yi Wang <hsinyi@chromium.org>
Auto-Submit: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Miguel Casas-Sanchez <mcasas@chromium.org>
Reviewed-by: Miguel Casas <mcasas@google.com>
Commit-Queue: Hsin-Yi Wang <hsinyi@chromium.org>
Video buffers are forced to use 64 alignment because of some nebulous
argument around better cache performance (b/35560932, it was mostly
about kevin and somehow hana got bundled in).
On Mediatek, however, video decoder and image processor use 16-
alignment (like macroblocks), forcing the use of the image processor
to reconcile these two, negating any performance/cache improvements.
This CL changes that to only use 64-alignment to non-YUV (hence,
video) quads, and this only for Hana.
BUG=b:220175010
TEST=video.DecodeAccel.* on hana
Change-Id: I48ee1beac29f915734830eda64705a2b4827a901
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3475099
Tested-by: Miguel Casas-Sanchez <mcasas@chromium.org>
Tested-by: Miguel Casas <mcasas@google.com>
Reviewed-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Miguel Casas <mcasas@google.com>
Commit-Queue: Miguel Casas <mcasas@google.com>
These are VIRGL_BIND_SAMPLER_VIEW compatible formats checked by vrend.
So virtgpu advertises texture support for them correspondingly. When it
comes to host gbm allocation, minigbm failed because of no support,
which breaks the api contract. Advertising them for mt8183 fixes it.
BUG=b:204633833
TEST=dEQP-VK.api.external.memory.android_hardware_buffer.*
Change-Id: I2429f2f5ac04b8193ac3505774deba224f464d92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3253838
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Fei Shao <fshao@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
If the FLEX_YCbCr_420_888 format gets resolved into YVU420, the backend
must strip scanout to satisfy the format support.
BUG=b:201686603
TEST=gralloctest alloc_combinations
Change-Id: I9206cb4d695b9a7eb052d2bbf2ea1032d706abb1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3198681
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Auto-Submit: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Fei Shao <fshao@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
It makes more sense to resovle the format and use_flags together to
avoid duplicates.
Add the helper to vc4 and dumb_driver backends since that's missed
from prior frontend refactoring.
Split the resolve helper in virtgpu_virgl for the 3d and 2d paths to
make code logic cleaner.
BUG=b:199524294
TEST=CQ
Change-Id: I89b633ea484f0fc5bb9b4e0548cad017b9970cc6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3200143
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Jason Macnak <natsu@google.com>
Reviewed-by: Chia-I Wu <olv@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
1. frontends access the driver via drv.h only
2. the renamed drv_helpers and drv_array_helpers are for driver only
3. remove extern "C" from drv_helpers.h given not exposed to gralloc
4. remove all redundant includes for those helpers
BUG=b:199524294
TEST=CQ and gralloc builds on aosp
Change-Id: I3f4d33076a6a8161804f1b7c26950ff5496507e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3195651
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olv@google.com>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
Only 2d virtgpu backend needs to fallback here because virtio primary
plane only allows DRM_FORMAT_XRGB8888.
Most our platforms cannot display YV12 (except msm), thus the fallback
is required for the converted DRM_FORMAT_YVU420_ANDROID. For virgl
backend, additionally append a BO_USE_LINEAR as a replacement for the
hack inside compute_virgl_bind_flags.
BUG=b:199524294
TEST=CQ
TEST=gralloctest alloc_combinations
TEST=android.media.cts.VideoDecoderRotationTest
Change-Id: Ic87838ea2aae2b0abf87ed898ad75a3d7e556471
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3166775
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Auto-Submit: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
This reverts commit bfd4b0a3ab.
Reason for revert: This breaks CTS: b:196768393
Original change's description:
> minigbm: mediatek: Conditionally resolve DRM_FORMAT_BGR888 to DRM_FORMAT_XBGR8888
>
> Since the original DRM_FORMAT_BGR888 format did not support
> BO_USE_RENDERING or BO_USE_TEXTURE flag and Chromium doesn't
> support 24-bit RGB format, resolve the DRM_FORMAT_BGR888
> to DRM_FORMAT_XBGR8888 to solve the problem.
>
> BUG=b:191096118
> TEST=deploy vendor image and open "My Talking Tom 2" app
>
> Signed-off-by: Nick Fan <Nick.Fan@mediatek.com>
> Change-Id: Ibfc76b3790045731c95f1cd387e67ecc5d775e0b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2976161
> Reviewed-by: Nick Fan <nick.fan@mediatek.corp-partner.google.com>
> Reviewed-by: Fei Shao <fshao@chromium.org>
> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
> Tested-by: Nick Fan <nick.fan@mediatek.corp-partner.google.com>
> Commit-Queue: Fei Shao <fshao@chromium.org>
Bug=b:191096118,b:196768393
Change-Id: I049e41c0885863fd514c43e56705382779b3daa4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3097252
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Tested-by: Fei Shao <fshao@chromium.org>
Auto-Submit: Fei Shao <fshao@chromium.org>
Reviewed-by: Shawn Ku <shawnku@chromium.org>
Commit-Queue: Kazuhiro Inaba <kinaba@chromium.org>
Since the original DRM_FORMAT_BGR888 format did not support
BO_USE_RENDERING or BO_USE_TEXTURE flag and Chromium doesn't
support 24-bit RGB format, resolve the DRM_FORMAT_BGR888
to DRM_FORMAT_XBGR8888 to solve the problem.
BUG=b:191096118
TEST=deploy vendor image and open "My Talking Tom 2" app
Signed-off-by: Nick Fan <Nick.Fan@mediatek.com>
Change-Id: Ibfc76b3790045731c95f1cd387e67ecc5d775e0b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2976161
Reviewed-by: Nick Fan <nick.fan@mediatek.corp-partner.google.com>
Reviewed-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Nick Fan <nick.fan@mediatek.corp-partner.google.com>
Commit-Queue: Fei Shao <fshao@chromium.org>
90a0c88636 "minigbm/mediatek: Allocate NV12 video buffers for MT8192"
added NV12 to the list of supported formats, but forgot to return it
when needed. Fix this.
BUG=b:167469726
BUG=b:184014873
TEST=ARC++ on Asurada allocates NV12 video buffers.
Change-Id: I5182949f39a44d7a1dd7b1f118b300ac0f56559a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2823624
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Tzung-Bi Shih <tzungbi@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Fritz Koenig <frkoenig@chromium.org>
With real HW protection on the horizon, let's repurpose the
protection flag to mean that.
Currently, our protected buffer scheme on the Android side
allocates a dummy fd, which is sent to Chrome. Chrome
associates that dummy fd with an unmappable shared memory
buffer. In the entire process, minigbm doesn't really do
anything.
We prevent buffers allocated with the protected
flag from being mapped, but since it's a dummy fd it's not
really useful.
Chrome doesn't use the protected flag yet, but hopefully will
so in the future, but with real HW protection.
BUG=
TEST=
Change-Id: I57be26926539471f062ffeff33b523a3899c35f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2466958
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
To unblock the HALv3 camera migration for MT8173 platform, we changed to
use NV12 for camera read/write, video hw encoder/decoder for
DRM_FORMAT_FLEX_YCbCr_420_888 format on MT8173 in crrev.com/c/2317328.
However, it broke V4L2 VDA since it does not support NV12, as per
b:162698479.
Since camera will not use video decoder actually, change MT8173
back to use YVU420 for video decoder.
BUG=b:162698479
TEST=tast run [DUT] arc.VideoDecodeAccel.h264
Change-Id: Iee83ab0184541b24ecc9e4fb07138c09228e5440
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2336352
Tested-by: Wei Lee <wtlee@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Wei Lee <wtlee@chromium.org>
Auto-Submit: Wei Lee <wtlee@chromium.org>
We use SCANOUT_VEA_READ_CAMERA_AND_CPU_READ_WRITE for camera
capture use scenario in Chrome. Therefore, NV12 format must be
allowed for all those usage masks. This CL modifies the usages on
all platforms.
BUG=chromium:982201
TEST=video.EncodeAccel.vp8_720p_i420 on eve
Change-Id: I7880e64049f3bbf9dd1c177619e41362baf641f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2240995
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
minigbm has allowed HW_VIDEO_ENCODER usage to YVU420 so that
chrome can allocate YVU420 with HW_VIDEO_ENCODER. But this
format is no longer allocated by chrome with the usage. Let's
delete the code.
BUG=chromium:982201
TEST=None
Change-Id: Ia6bbc24e7782e3e73c2eb00c00127af212ddf486
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2245967
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Auto-Submit: Hirokazu Honda <hiroh@chromium.org>
ARCVM sets encoder/decoder usage on the blob output/input buffers, so
that virtio_gpu knows to perform transfers from/to the host where
appropriate. Recently, virtio_gpu started passing all bind flags to the
host, instead of reducing them in the guest. These factors combined
means that the host backends now need to support encoder/decoder usage
with R8 format.
Test: manually verify ARCVM YouTube
Bug: b:158957350
Change-Id: I58bf657496647f8002c693d17a1186f4cf527b01
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2245540
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
All renderer target works are eligible for scanout, after looking
at mtk_plane_init.
BUG=b:151064316
TEST=Mirror mode works again on Kukui
Change-Id: Ife8948c167c1d75622404af573f8cc92b3516416
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2118463
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Instead of calling drmPrimeHandleToFD directly, call drv_bo_get_plane_fd
so that the FD is exported with DRM_RDWR if possible.
When a handle is exported, the drm framework caches the underlying
dma_buf struct, even if all fd references are closed. This means that
the flags from the first export operation end up being the primary flags
for all subsequent export attempts. This change ensures that the O_RDWR
flag is set on the first call, to prevent permission checks in
PlatformSharedMemoryRegion from failing.
BUG=b:151394062
TEST=youtube on arcvm on kukui
Change-Id: I9de7bb67b45b3669704f3487889b10ed62493418
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2101054
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
We want to use the same buffer from camera to JPEG hardware encoder so
align the height of camera usage buffer 16 that is required by the JPEG
hardware encoder.
BUG=b:141516308
TEST=Check if data offset is correct. Take picture with CCA.
Change-Id: I0db10762494423f7c4a340725015839803b40af4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1984211
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Hsu Wei-Cheng <mojahsu@chromium.org>
Commit-Queue: Hsu Wei-Cheng <mojahsu@chromium.org>
In this CL, we add DRM_FORMAT_MTISP_SXYZW10, a 10-bit private bayer
format for private reprocessing on MediaTek ISP P1. We change the logic
around resolving the DRM format for IMPLEMENTATION_DEFINED buffers. When
CAMERA_READ usage flag is present, we consider it to be a buffer for
reprocessing and resolve the format to our private format.
BUG=b:130851309
TEST=Emerge and deploy minigbm cros-camera-libcbm cros-camera
cros-camera-hal-mtk, then verify that ZSL is working.
Change-Id: I8d9fd4e6a20c284751915e136bef0b4ceb143d78
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1753902
Tested-by: Jasmine Chen <lnishan@google.com>
Auto-Submit: Jasmine Chen <lnishan@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Jasmine Chen <lnishan@google.com>
This reverts commit aa6b072d4c.
Reason for revert: This change is unnecessary because HW_VIDEO_ENCODER
usage is unmasked in crrev.com/c/1940034.
Original change's description:
> Enable to allocate XBGR8888 with HW_VIDEO_ENCODER usage
>
> crrev.com/c/1904910 masks the HW_VIDEO_ENCODER usage when
> BO_USE_HW_VIDEO_ENCODER is specified in gralloc. A camera stack allocates
> XBGR8888 buffer with BO_USE_HW_VIDEO_ENCODER usage in ARC++ video
> recording if the camera HAL version is V1. Thanks to crrev.com/c/1904910,
> it is necessary to enable to allocate XBGR8888 with HW_VIDEO_ENCODER usage.
>
> BUG=b:144135251
> TEST=Recording with GCA
>
> Change-Id: I61beee87a1531c0dea371861ffb31ce2189ef854
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1934068
> Tested-by: Hirokazu Honda <hiroh@chromium.org>
> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
> Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Bug: b:144135251
Cq-Depend: chromium:1940034
Change-Id: I8d64c97399a601487fc84a6ecae337c235bd4464
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1947685
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Auto-Submit: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
crrev.com/c/1904910 masks the HW_VIDEO_ENCODER usage when
BO_USE_HW_VIDEO_ENCODER is specified in gralloc. A camera stack allocates
XBGR8888 buffer with BO_USE_HW_VIDEO_ENCODER usage in ARC++ video
recording if the camera HAL version is V1. Thanks to crrev.com/c/1904910,
it is necessary to enable to allocate XBGR8888 with HW_VIDEO_ENCODER usage.
BUG=b:144135251
TEST=Recording with GCA
Change-Id: I61beee87a1531c0dea371861ffb31ce2189ef854
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1934068
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
crrev.com/c/1767450 changed the default android flexible buffer format
back to YV12, but the video decoding scenario on MT8183 requires NV12
buffers. Add an exception for this case.
BUG=b:141732718
TEST=Play H.264 video with acceleration using both Chrome and Android's
Youtube.
Change-Id: Ie4b80389b22650450ea45f5cdea36a00360899a9
Reviewed-on: https://chromium-review.googlesource.com/1833362
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Ready: Alexandre Courbot <acourbot@chromium.org>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The R8 format should be configured with LINEAR_METADATA.
BUG=b:141328294
TEST=manually on Kukui
Change-Id: I612e78d28b63960428a6dce04104c3266b124a23
Reviewed-on: https://chromium-review.googlesource.com/1816204
Tested-by: Ricky Liang <jcliang@chromium.org>
Commit-Ready: Ricky Liang <jcliang@chromium.org>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Required to build for arm64 on mediatek, and let's fix the
rockchip one, while we're at it.
BUG=b:140228960
TEST=emerge-kevin-arc64 -av arc-cros-gralloc
TEST=emerge-kukui -av arc-cros-gralloc (with ARC++ 64-bit)
Change-Id: I8e04355a4d247b44ac86963331be72495655d321
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1775949
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Auto-Submit: Nicolas Boichat <drinkcat@chromium.org>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
crrev.com/c/1716864 made gralloc allocae NV12 buffer with the android flexible
format, DRM_FORMAT_FLEX_YCbCr_420_888. However, the change broke many CTS tests.
This partially reverts the commit. The allocated buffer fromat becomes YVU420.
BUG=chromium:987185
BUG=b:139714614
Cq-Depend: chromium:1767680
Change-Id: I9fcde88cff79fac2655fb627418b371b314077c1
Reviewed-on: https://chromium-review.googlesource.com/1767450
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Ready: Hirokazu Honda <hiroh@chromium.org>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Chrome needs to allocate a linear buffer that a hardware video encoder can read
and cpu can read and write. There is no use flag in gbm that specifies the
former. This CL introduces a new use flag for that.
BUG=b:138703716
TEST=None
Change-Id: Ied0321914a366294a47e4fc5c2a8f08ee0351bd8
Reviewed-on: https://chromium-review.googlesource.com/1728729
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
YV12 have been a pixel format of output frame in HW decoder on MediaTek device.
Since all other platforms uses NV12 for the format, it is good to change the
format to NV12 on MediaTek as well. So we can only think about NV12 for a pixel
format in HW decoder.
BUG=chromium:987185
TEST=video_decode_accelerator_tests
TEST=Play video with Chrome
Cq-Depend:chromium:1716844
Change-Id: Ic7e4f66d503247bdeba9cb66c8a598b233ed6df9
Reviewed-on: https://chromium-review.googlesource.com/1716864
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Add NV21, YUYV and YVU420 formats support for MT8183 camera
Use config to seperate modification only for MT8183
BUG=b:109911488
TEST=emerge-kukui minigbm
Change-Id: I7201b89de3fa062f96cd69e4b91a2a4b434c738e
Signed-off-by: Nick Fan <Nick.Fan@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/1267857
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Nick Fan <nick.fan@mediatek.corp-partner.google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Mesa drivers can't use it, in general.
I'm leaving in Rockchip since I haven't gotten any reports
about this test failing on kevin-arcnext.
Fixes: abe44f ("minigbm: add support for BG24")
BUG=b:77876551, b:115564746
TEST=The following tests should pass on Eve/Grunt arc-next:
android.hardware.nativehardware.cts.AHardwareBufferNativeTests#SingleLayer_ColorTest_GpuColorOutputAndSampledImage_R8G8B8_UNORM
android.hardware.nativehardware.cts.AHardwareBufferNativeTests#SingleLayer_ColorTest_GpuColorOutputCpuRead_R8G8B8_UNORM
android.hardware.nativehardware.cts.AHardwareBufferNativeTests#SingleLayer_ColorTest_GpuColorOutputIsRenderable_R8G8B8_UNORM
android.hardware.nativehardware.cts.AHardwareBufferNativeTests#SingleLayer_ColorTest_GpuSampledImageCanBeSampled_R8G8B8_UNORM
Change-Id: Ic7aec07c89fdc21e0c8392238e833f7980062049
Reviewed-on: https://chromium-review.googlesource.com/1229439
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Before this change, a NULL pointer could have been passed to munmap(),
making impossible for it to unmap previoulsy mapped memory. After this
change, munmap() always receives a valid pointer.
BUG=b:71835379 b:114699642
TEST=adb shell "am instrument -w --abi armeabi-v7a -e class\
android.uirendering.cts.testclasses.InfrastructureTests#testScreenshot\
android.uirendering.cts/android.support.test.runner.AndroidJUnitRunner"
Change-Id: Ic1b15807623209ab28d0d4ed63fe0d6ef2dcc6f8
Signed-off-by: Luigi Santivetti <luigi.santivetti@imagination.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/1221667
Commit-Ready: Kazuhiro Inaba <kinaba@chromium.org>
Tested-by: Pin-chih Lin <johnylin@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Without doing this it's possible for the CPU to access the memory when it's
in use by another device.
TEST=adb shell "am instrument -w --abi armeabi-v7a -e class\
android.media.cts.EncodeDecodeTest#testEncodeDecodeVideoFromPersistentSurfaceToSurfaceQCIF\
android.media.cts/android.support.test.runner.AndroidJUnitRunner"
BUG=b:71835379
Change-Id: I3b1508a0eab3b020b7c42978cb1e1099ebc029fd
Signed-off-by: Luigi Santivetti <luigi.santivetti@imagination.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/1193302
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
