lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 21 Apr 2017 15:12:03 +0200 From: Gerd Hoffmann <kraxel@...hat.com> To: Christian König <christian.koenig@....com> Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com>, Jani Nikula <jani.nikula@...ux.intel.com>, David Airlie <airlied@...ux.ie>, Michel Dänzer <michel@...nzer.net>, open list <linux-kernel@...r.kernel.org>, dri-devel@...ts.freedesktop.org, Pekka Paalanen <ppaalanen@...il.com>, Sean Paul <seanpaul@...omium.org>, amd-gfx@...ts.freedesktop.org, Alex Deucher <alexdeucher@...il.com>, Daniel Vetter <daniel.vetter@...el.com>, Ilia Mirkin <imirkin@...m.mit.edu> Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality. Hi, > > "native" to me feels more like "native to the GPU" since these things > > really are tied to the GPU not the CPU. That's also why I went with the > > explicit endianness originally so that the driver could properly declare > > what the GPU supports. > And to be honest I would really prefer to stick with that approach for > exactly that reason. > > The proposed change would require that drivers have different code path > for different CPU byte order. Those code path tend to be not tested very > well and are additional complexity we probably don't want inside the driver. We can add fixed-endian #defines without too much effort, at least for the 8 bits per color formats. In qemu we have the same problem, only with pixman. Those formats are native endian too, but often we have to handle a fixed format, so we did this: /* * pixman image formats are defined to be native endian, * that means host byte order on qemu. So we go define * fixed formats here for cases where it is needed, like * feeding libjpeg / libpng and writing screenshots. */ #ifdef HOST_WORDS_BIGENDIAN # define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_r8g8b8a8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_a8b8g8r8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_b8g8r8x8 #else # define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_a8b8g8r8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_r8g8b8a8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_x8r8g8b8 #endif > My personal opinion is that formats in drm_fourcc.h should be > independent of the CPU byte order and the function > drm_mode_legacy_fb_format() and drivers depending on that incorrect > assumption be fixed instead. The problem is this isn't a kernel-internal thing any more. With the addition of the ADDFB2 ioctl the fourcc codes became part of the kernel/userspace abi ... cheers, Gerd
Powered by blists - more mailing lists