summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-03-21amdgpu: add amdgpu_va_range_alloc2Pierre-Eric Pelloux-Prayer3-7/+37
This is the same functionnality that amdgpu_va_range_alloc offers, except it's now usable without a device handle. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
2024-03-21amdgpu: expose amdgpu_va_manager publiclyPierre-Eric Pelloux-Prayer4-22/+74
This will allow applications to use this feature without a device. The first use case will be native context: we want VA address to be managed by the guest (to avoid a round-trip to the host to only generate a VA) but the amdgpu_device only exist on the host. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
2024-03-21amdgpu: add amdgpu_va_managerPierre-Eric Pelloux-Prayer3-26/+31
Until now VA management was tied to a device handle, but there's no reason for this. As a first step to export VA management outside of amdgpu_device, this commit adds a new structure type holding the 4 va_mgr. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
2024-03-05amdgpu: Make amdgpu_device_deinitialize thread-safeDavid Rosca1-2/+2
Device will be removed from dev_list when refcount reaches 0, so the dev_mutex must be locked before decreasing reference otherwise there's a race where this device is still in dev_list with refcount 0 which will assert or crash in amdgpu_device_initialize trying to use this device instead of creating new one. Fixes issue reported in https://gitlab.freedesktop.org/drm/amd/-/issues/2156#note_2268110 Reviewed-by: Marek Olšák <marek.olsak@amd.com>
2024-02-26tests/util: add tidss driverFrancesco Valla1-0/+1
Add an entry for the "tidss" driver, so that the test utilities work with this driver without passing the -M argument. Signed-off-by: Francesco Valla <valla.francesco@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-02-15meson: make build system happy by replacing deprecated featureAdrián Larumbe2-2/+2
ExternalProgram.path() is deprecated since 0.55, use ExternalProgram.full_path() instead. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2024-02-12xf86drm: Don't consider node names longer than the maximum allowedDylan Baker1-2/+18
This fixes the logic that decides if a node name is valid to use the same length restrictions that are used in drmDeviceAlloc, which expects node names to conform to a specific naming scheme (On OSes except OpenBSD this means `/dev/dri/renderD123`). This addresses the problem of node names that are longer than expected, while still allowing symlinks to work. I've also applied the same fix to the OpenBSD path, while bringing the check that `snprintf` didn't error from OpenBSD to the main path. Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Tested-by: Mark Janes <markjanes@swizzler.org> Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
2024-02-12Revert "xf86drm: ignore symlinks in process_device()"Dylan Baker1-4/+1
This reverts commit 7ab1cdac9013d2a4c41b3d0975f953585517cfa1. This breaks numerous tools that rely on being able to read symlinks, and constitutes a regression. Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Tested-by: Mark Janes <markjanes@swizzler.org> Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Closes: #103
2024-02-08xf86drm: ignore symlinks in process_device()103-regression-intel-mesa-buildtests-broken-by-libdrm-updateTobias Jakobi1-1/+4
If the user has some UDev rules in place that creates symlinks for one of the card or render nodes, and the name of the symlink is too long, then drmDeviceAlloc() ends up truncating the name of the node. This in turn results in chaos in different subsystems. E.g. vulkaninfo dies early with this: Code 0 : failed to stat DRM primary node /dev/dri/my-favorite- (VK_ERROR_INITIALIZATION_FAILED) (if the symlink is called /dev/dri/my-favorite-card-node) Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
2024-01-24amdgpu: add marketing names from amd-6.0.1Jonathan Gray1-0/+1
2024-01-24amdgpu: add marketing name for Radeon RX 6550MJonathan Gray1-0/+1
from notebookcheck review of Lenovo ThinkPad Z16 Gen 2
2024-01-24amdgpu: add marketing names from amd-6.0Jonathan Gray1-0/+2
2024-01-24amdgpu: add marketing names from Windows Steam Deck OLED APU driverJonathan Gray1-0/+2
2024-01-24amdgpu: add marketing names from PRO Edition for W7700Jonathan Gray1-0/+1
2024-01-24amdgpu: add marketing names from Adrenalin 23.11.1Jonathan Gray1-0/+60
2024-01-13build: bump version to 2.4.120libdrm-2.4.120Simon Ser1-1/+1
Signed-off-by: Simon Ser <contact@emersion.fr>
2024-01-13Sync headers with drm-nextSimon Ser2-1/+60
Synchronize drm.h and drm_mode.h to drm-next. Generated using make headers_install. Generated from drm-next branch commit a60501d7c2d3e70b3545b9b96576628e369d8e85 Signed-off-by: Simon Ser <contact@emersion.fr> Acked-by: Simon Zeni <simon.zeni@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-01-04amdgpu: fix use-after-freePierre-Eric Pelloux-Prayer1-2/+2
Closes: https://gitlab.freedesktop.org/mesa/drm/-/issues/96 Reviewed-by: Marek Olšák <marek.olsak@amd.com>
2024-01-01radeon: fix missing stencil_tile_mode initialisation in the linear/fallback caseEric Engestrom1-0/+1
../radeon/radeon_surface.c:1611:13: error: 'stencil_tile_mode' may be used uninitialized [-Werror=maybe-uninitialized] 1611 | r = si_surface_init_1d(surf_man, surf, surf->stencil_level, 1, stencil_tile_mode, surf->bo_size, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2023-12-21meson: bump libdrm version to 2.4.119libdrm-2.4.119Marek Olšák1-1/+1
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
2023-12-21amdgpu: add amdgpu_va_get_start_addrMarek Olšák3-0/+11
for Mesa Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
2023-11-20build: bump version to 2.4.118libdrm-2.4.118Simon Ser1-1/+1
Signed-off-by: Simon Ser <contact@emersion.fr>
2023-11-20xf86drmMode: add drmModeCloseFB()Simon Ser3-0/+18
Add a wrapper for the new CLOSEFB IOCTL, to close a framebuffer without implicitly disabling planes or CRTCs. See https://lore.kernel.org/dri-devel/20231020101926.145327-2-contact@emersion.fr/ Signed-off-by: Simon Ser <contact@emersion.fr>
2023-11-20Sync headers with drm-nextSimon Ser2-17/+113
Synchronize drm.h, drm_mode.h and drm_fourcc.h to drm-next. Generated using make headers_install. Generated from drm-next branch commit c79b972eb88b077d2765e7790d0902b3dc94d55c Signed-off-by: Simon Ser <contact@emersion.fr>
2023-11-20xf86drm: add drmGetNodeTypeFromDevIdSimon Ser3-0/+25
This is useful to figure out whether the dev_t refers to a primary node or a render node. Indeed, drmGetDeviceFromDevId returns a drmDevice, which holds both the primary and render nodes. Signed-off-by: Simon Ser <contact@emersion.fr>
2023-11-15modetest: switch usage to proper options grammarNeil Armstrong1-4/+26
It was unclear how #mode could be used, so fixup the usage string and print the struct grammar of the -s and -P options to clarify the usage. The following grammar was compiled: <plane_topology> ::= <plane_id> "@" <crtc_id> ":" <width> "x" <height> ( <plane_offsets> )? <plane_offsets> ::= "+" <x_offset> "+" <y_offset> ( <plane_scale> )? <plane_scale> ::= "*" <scale> ( <plane_format> )? <plane_format> ::= "@" <format> <mode_topology> ::= <connector_id> ( "," <connector_id> )* ( "@" <crtc_id> )? ":" <mode_selection> ( "@" <format> )? <mode_selection> ::= <indexed_mode> | <named_mode> | <custom_mode> <indexed_mode> ::= "#" <mode_index> <named_mode> ::= <width> "x" <height> ( "-" <vrefresh> )? <custom_mode> ::= <hdisplay> "," <hsyncstart> "," <hsyncend> "," <htotal> "," <vdisplay> "," <vsyncstart> "," <vsyncend> "," <vtotal> "-" <vrefresh> <property> ::= <object_id> ":" <property_name> ":" <value> <plane_id> ::= [0-9]+ <crtc_id> ::= [0-9]+ <width> ::= [0-9]+ <height> ::= [0-9]+ <x_offset> ::= [0-9]+ <y_offset> ::= [0-9]+ <scale> ::= [0-9]+ ( "." [0-9]+ ) <format> ::= ( [A-Z] | [0-9] )+ <connector_id> ::= [0-9]+ <mode_index> ::= [0-9]+ <hdisplay> ::= [0-9]+ <hsyncstart> ::= [0-9]+ <hsyncend> ::= [0-9]+ <htotal> ::= [0-9]+ <vdisplay> ::= [0-9]+ <vsyncstart> ::= [0-9]+ <vsyncend> ::= [0-9]+ <vtotal> ::= [0-9]+ <object_id> ::= [0-9]+ <vrefresh> ::= [0-9]+ <property_name> ::= ( [A-Z] | [0-9] | "_" )+ <value> ::= [0-9]+ with the https://bnfplayground.pauliankline.com/ service Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-10-31modetest: add support for big-endian XRGB1555/RGB565Geert Uytterhoeven1-0/+4
Add support for creating buffers using big-endian formats. For now this is limited to XRGB1555 and RGB565, which are the most common big-endian formats. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - No changes, v2: - New.
2023-10-31util: add pwetty support for big-endian RGB565Geert Uytterhoeven1-0/+1
Add support for rendering the crosshairs in a buffer using the big-endian RGB565 format. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - No changes, v2: - New.
2023-10-31util: fix pwetty on big-endianGeert Uytterhoeven1-0/+44
Cairo always uses native byte order for rendering. Hence if the byte order of the frame buffer differs from the byte order of the CPU, the frame buffer contents need to be byteswapped twice: once before rendering, to convert to native byte order, and a second time after rendering, to restore the frame buffer format's byte order. Note that byte swapping is not done for ARGB32 formats, as for these formats, byte order only affects the order of the red, green, and blue channels, which we do not care about here. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Wrap byteswap_buffer{16,32}() implementation inside #if HAVE_CAIRO to avoid defined-but-not-used compiler warnings, v2: - RGB30 is untested.
2023-10-31util: add test pattern support for big-endian XRGB1555/RGB565Geert Uytterhoeven1-10/+21
Add support for drawing the SMPTE and tiles test patterns in buffers using big-endian formats. For now this is limited to XRGB1555 and RGB565, which are the most common big-endian formats. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Increase indentation after definition of cpu_to_be16(), v2: - New.
2023-10-31modetest: add support for parsing big-endian formatsGeert Uytterhoeven1-6/+9
When specifying a frame buffer format like "RG16_BE" (big-endian RG16), modetest still uses the little-endian variant, as the format string is truncated to four characters. Fix this by increasing the format string size to 8 bytes (7 characters + NUL terminator). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Update for suffix change from "be" to "_BE", cfr. commit ffb9375a505700ad ("xf86drm: handle DRM_FORMAT_BIG_ENDIAN in drmGetFormatName()"), - Replace hardcoded numbers in code by sizeof(), v2: - New.
2023-10-31util: add missing big-endian RGB16 frame buffer formatsGeert Uytterhoeven1-0/+3
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Update for suffix change from "be" to "_BE", cfr. commit ffb9375a505700ad ("xf86drm: handle DRM_FORMAT_BIG_ENDIAN in drmGetFormatName()"), v2: - New.
2023-10-31util: fix 16 bpp patterns on big-endianGeert Uytterhoeven1-7/+14
DRM formats are defined to be little-endian, unless the DRM_FORMAT_BIG_ENDIAN flag is set. Hence writes of multi-byte pixel values need to take endianness into account. Introduce a swap16() helper to byteswap 16-bit values, and a cpu_to_le16() helper to convert 16-bit values from CPU-endian to little-endian, and use the latter in the various pattern fill functions for 16-bit formats. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Increase indentation after definition of cpu_to_le16(), v2: - New.
2023-10-31util: fix 32 bpp patterns on big-endianGeert Uytterhoeven1-9/+23
DRM formats are defined to be little-endian, unless the DRM_FORMAT_BIG_ENDIAN flag is set. Hence writes of multi-byte pixel values need to take endianness into account. Introduce a swap32() helper to byteswap 32-bit values, and a cpu_to_le32() helper to convert 32-bit values from CPU-endian to little-endian, and use the latter in the various pattern fill functions for 32-bit formats. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - Use new HAVE_BIG_ENDIAN symbol, v3: - Increase indentation after definition of cpu_to_le32(), v2: - Add Acked-by, - Add swap32() intermediate helper, - Add __ARM_BIG_ENDIAN and __s390__.
2023-10-31intel: determine target endianness using mesonGeert Uytterhoeven2-2/+7
The endianness of the target is currently determined based on preprocessor symbols. Unfortunately some symbols checked are wrong (sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC), and several checks for big-endian architectures are missing. Fix this by introducing a new preprocessor symbol HAVE_BIG_ENDIAN, which is set based on meson's knowledge of the target endianness. Android.common.mk does not need an update, as Android is always little-endian (https://developer.android.com/ndk/guides/abis.html). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - Replace explicit #ifdef checks by a define set by meson, v3: - No changes, v2: - Add arm, aarch64, microblaze, s390, and sh.
2023-10-30modetest: add support for DRM_FORMAT_NV{15,20,30}Jonas Karlman4-10/+225
Add smpte and tiles pattern for 10-bit NV15, NV20 and NV30 pixel formats based on the existing pattern for NV12 with colors simply scaled from 8-bit to 10-bit. These pixel formats are typically used by video decoder and display pipeline on Rockchip SoCs, e.g. on RK322X, RK3288, RK3328 and RK3399 the video decoder produce 10-bit video frames in NV15 and NV20 format. NV20 and NV30 pixel formats was added in drm-misc commit 728c15b4b5f3 ("drm/fourcc: Add NV20 and NV30 YUV formats"). This can be tested/validated on Rockchip SoCs with drm-misc commit d4b384228562 ("drm/rockchip: vop: Add NV15, NV20 and NV30 support"). Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Christopher Obbard <chris.obbard@collabora.com> Tested-by: Christopher Obbard <chris.obbard@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-10-24meson: fix typo in libdrm_intelDavid Jagu1-1/+1
Replace system() with cpu_family() for libdrm_intel This restore libdrm_intel to be built by default Closes: #93 Signed-off-by: David Jagu <marav8@free.fr>
2023-10-24modetest: add SMPTE pattern support for C[124] formatsGeert Uytterhoeven1-3/+6
Add support for drawing the SMPTE pattern in buffers using a color-indexed frame buffer formats with two, four, or sixteen colors. Note that this still uses 256 as the CLUT size, as DRM_IOCTL_MODE_SETGAMMA enforces that the size matches against the (fixed) gamma size, while the CLUT size depends on the format. Move clearing the color LUT entries from util_smpte_index_gamma() to its caller, as only the caller knows how many entries there really are (currently DRM always assumes 256 entries). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - Add missing C[12] to oneline-summary, - Do not remove memset() of full lut, else some entries may stay uninitialized, v3: - Add Acked-by, v2: - Split off changes to tests/modetest/modetest.c, - Add C1 and C2 support. The linuxdoc comments say userspace can query the gamma size: * drm_mode_gamma_set_ioctl - set the gamma table * * Set the gamma table of a CRTC to the one passed in by the user. Userspace can * inquire the required gamma table size through drm_mode_gamma_get_ioctl. * drm_mode_gamma_get_ioctl - get the gamma table * * Copy the current gamma table into the storage provided. This also provides * the gamma table size the driver expects, which can be used to size the * allocated storage. but the code doesn't seem to support that in an easy way (like setting red/green/blue to NULL on input, retrieving gamma_size on output), only by providing big enough buffers for red/green/blue, and looping over gamma_size until -EINVAL is no longer returned.
2023-10-24modetest: add support for DRM_FORMAT_C[124]Geert Uytterhoeven1-0/+15
Add support for creating buffers using the new color-indexed frame buffer formats with two, four, and sixteen colors. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Add Acked-by, v2: - Split off changes to tests/modetest/buffers.c.
2023-10-24util: add SMPTE pattern support for C2 formatGeert Uytterhoeven1-1/+99
Add support for drawing the SMPTE pattern in a buffer using the C2 indexed format. As only four colors are available, resolution is halved, and the pattern is drawn in a PenTile RG-GB matrix, using Floyd-Steinberg dithering. The magnitude of the green subpixels is reduced, as there are twice as many green subpixels as red or blue subpixels. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- Dithering example at https://drive.google.com/file/d/1g5O8XeacrjrC8rgaVENvR65YeI6QvmtO/view v5: - Add Reviewed-by, v4: - Replace FILL_COLOR() use by pentile_color_lut[], v3: - Add Acked-by, v2: - New.
2023-10-24util: add SMPTE pattern support for C1 formatGeert Uytterhoeven1-3/+171
Add support for drawing the SMPTE pattern in a buffer using the C1 indexed format. As only two colors are available, the pattern is drawn in black and white, using Floyd-Steinberg dithering[1]. [1] https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dithering Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- Dithering example at https://drive.google.com/file/d/1waJczErrIaEKRhBCCU1ynxRG8agpo0Xx/view v5: - Add Reviewed-by, v4: - Replace FILL_COLOR() use by bw_color_lut[], v3: - Add Acked-by, - Add Wikipedia link, v2: New.
2023-10-24util: add SMPTE pattern support for C4 formatGeert Uytterhoeven1-0/+42
Add support for drawing the SMPTE pattern in a buffer using the C4 indexed format. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Add Acked-by, v2: - Use new smpte_top[], - Split off changes to tests/util/pattern.c.
2023-10-24util: store number of colors for indexed formatsGeert Uytterhoeven2-4/+5
Store the number of available colors for color-indexed frame buffer formats in the format_info[] array. This avoids the need of test code for having to use switch statements all the time to obtain the number of colors, or to check if a mode is color-indexed or not. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Add Acked-by, v2: - New.
2023-10-24util: add support for DRM_FORMAT_C[124]Geert Uytterhoeven1-0/+3
Add support for creating buffers using the new color-indexed frame buffer formats with two, four, and sixteen colors. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Add Acked-by, v2: - Split off changes to tests/util/format.c.
2023-10-24util: factor out and optimize C8 SMPTE color LUTGeert Uytterhoeven3-44/+82
The color LUT for the SMPTE pattern in indexed mode contains 22 entries, although only 13 are non-unique. Reduce the size of the color LUT by dropping duplicate entries, so it can be reused for formats supporting e.g. 16 colors. Rename the function util_smpte_c8_gamma() to util_smpte_fill_lut(), and its first parameter size to ncolors, to match their actual use. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - Rename util_smpte_index_gamma() to util_smpte_fill_lut(), and its first parameter from size to ncolors, - Move smpte_color_lut[] down, - Kill FILL_COLOR() macro, - Add and use EXPAND_COLOR() macro, v3: - Add Acked-by, v2: - Factor out smpte color LUT.
2023-10-24util: improve SMPTE color LUT accuracyGeert Uytterhoeven1-3/+3
Fill in the LSB when converting color components from 8-bit to 16-bit. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- v5: - Add Reviewed-by, v4: - No changes, v3: - Add Acked-by, v2: - New.
2023-10-20build: bump version to 2.4.117libdrm-2.4.117Simon Ser1-1/+1
Signed-off-by: Simon Ser <contact@emersion.fr>
2023-10-20meson: replace deprecated program.path -> program.full_pathDylan Baker4-4/+4
To avoid Meson warnings Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Reviewed-by: Simon Ser <contact@emersion.fr>
2023-10-20meson: Use feature.require() and feature.allowed()Dylan Baker2-88/+36
To reduce the size and complexity of checks. require() allows combining auto and enabled checks(), so that something like ```meson x = get_option('feature') y = false if x.enabled() if not condition error(...) endif y = condition endif ``` can be rewritten as: ```meson y = get_option('feature').require(condition, error_message : ...).allowed() ``` require checks the condition, then if the feature is required it emits an error with the given message otherwise it returns a disabled feature. allowed then returns whether the feature is not disabled, and returns that (ie, .allowed() == not .disabled()). This is especially helpful for longer more complex conditions Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
2023-10-20meson: fix intel requirementsDylan Baker1-2/+6
Intel requires libpciaccess and an x86/x86_64 host, so if those aren't found and it's enabled we need to error Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Reviewed-by: Simon Ser <contact@emersion.fr>