search for: drm_ioctl_mode_create_dumb

...s similar to NV12, but 10 bits per component, and some packing and padding. First plane: 3 pixels in a 32 bit group Second plane: 3 pixels in a 64 bit group, 2x2 subsampled So, on average, a pixel on the first plane takes 32 / 3 = 10.666... bits on a line. That's not a usable number for the DRM_IOCTL_MODE_CREATE_DUMB ioctl. What I did was to use the pixel group size as "bpp" for DRM_IOCTL_MODE_CREATE_DUMB. So, e.g., for 720 x 576: Stride for first plane: 720 * (32 / 3) / 8 = 960 bytes Stride for second plane: 720 / 2 * (64 / 3) / 8 = 960 bytes First plane: 720 / 3 = 240 pixel groups Second plane:...

...onent, > and some packing and padding. > > First plane: 3 pixels in a 32 bit group > Second plane: 3 pixels in a 64 bit group, 2x2 subsampled > > So, on average, a pixel on the first plane takes 32 / 3 = 10.666... > bits on a line. That's not a usable number for the > DRM_IOCTL_MODE_CREATE_DUMB ioctl. > > What I did was to use the pixel group size as "bpp" for > DRM_IOCTL_MODE_CREATE_DUMB. So, e.g., for 720 x 576: > > Stride for first plane: 720 * (32 / 3) / 8 = 960 bytes > Stride for second plane: 720 / 2 * (64 / 3) / 8 = 960 bytes > > First plane: 720...

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. Align the pitch according to hardware requirements. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com> --- drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +++++-- 1 file changed, 5

...g and padding. >> >> First plane: 3 pixels in a 32 bit group >> Second plane: 3 pixels in a 64 bit group, 2x2 subsampled >> >> So, on average, a pixel on the first plane takes 32 / 3 = 10.666... >> bits on a line. That's not a usable number for the >> DRM_IOCTL_MODE_CREATE_DUMB ioctl. >> >> What I did was to use the pixel group size as "bpp" for >> DRM_IOCTL_MODE_CREATE_DUMB. So, e.g., for 720 x 576: >> >> Stride for first plane: 720 * (32 / 3) / 8 = 960 bytes >> Stride for second plane: 720 / 2 * (64 / 3) / 8 = 960 bytes &gt...

While wading through the code I've noticed we have a little issue in virtio: We attach a format to the bo when it is created (DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer (DRM_IOCTL_MODE_ADDFB). Easy way out: support a single format only. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_gem.c | 5 ++++- drivers/gpu/drm/virtio/virtgpu_plane.c | 9 +-------- 2 files changed, 5 insert...

While wading through the code I've noticed we have a little issue in virtio: We attach a format to the bo when it is created (DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer (DRM_IOCTL_MODE_ADDFB). Easy way out: support a single format only. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_gem.c | 5 ++++- drivers/gpu/drm/virtio/virtgpu_plane.c | 9 +-------- 2 files changed, 5 insert...

...ifferent mapping on bigendian machines is wrong. It's there because of broken drm_mode_addfb() behavior. So with drm_mode_addfb() being fixed we can fix this too. While wading through the code I've noticed we have a little issue in virtio: We attach a format to the bo when it is created (DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer (DRM_IOCTL_MODE_ADDFB). Easy way out: Support a single format only. Pick DRM_FORMAT_HOST_XRGB8888, it is the only one actually used in practice. Drop unused mappings in virtio_gpu_translate_format(). With this patch applied both ADDFB and ADDFB2 ioctls work c...

...ifferent mapping on bigendian machines is wrong. It's there because of broken drm_mode_addfb() behavior. So with drm_mode_addfb() being fixed we can fix this too. While wading through the code I've noticed we have a little issue in virtio: We attach a format to the bo when it is created (DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer (DRM_IOCTL_MODE_ADDFB). Easy way out: Support a single format only. Pick DRM_FORMAT_HOST_XRGB8888, it is the only one actually used in practice. Drop unused mappings in virtio_gpu_translate_format(). With this patch applied both ADDFB and ADDFB2 ioctls work c...

...ifferent mapping on bigendian machines is wrong. It's there because of broken drm_mode_addfb() behavior. So with drm_mode_addfb() being fixed we can fix this too. While wading through the code I've noticed we have a little issue in virtio: We attach a format to the bo when it is created (DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer (DRM_IOCTL_MODE_ADDFB). Easy way out: Support a single format only. Pick DRM_FORMAT_HOST_XRGB8888, it is the only one actually used in practice. Drop unused mappings in virtio_gpu_translate_format(). With this patch applied both ADDFB and ADDFB2 ioctls work c...

...ib: Rename is_intel to has_known_intel_chipset lib: add igt_require_intel lib: Have gem_set_tiling require intel lib: Expose is_i915_device lib: Assert we are on i915 from intel_get_drm_devid lib: Call intel_get_drm_devid only from intel code lib: Add wrapper for DRM_IOCTL_MODE_CREATE_DUMB lib: Add helper kmstest_dumb_map_buffer lib: Add igt_dirty_fb lib: Map dumb buffers lib: Add igt_create_bo_with_dimensions kms_addfb_basic: call igt_create_bo_with_dimensions kms_addfb_basic: move tiling functionality into each subtest kms_addfb_basic: Spli...

Dumb-buffer pitch and size is specified by width, height, bits-per-pixel plus various hardware-specific alignments. The calculation of these values is inconsistent and duplicated among drivers. The results for formats with bpp < 8 are incorrect. This series fixes this for most drivers. Default scanline pitch and buffer size are now calculated with the existing 4CC helpers. There is a new