On 24/04/17 11:26 PM, Ville Syrjälä wrote:
On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote:
On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
drm: fourcc byteorder: add DRM_FORMAT_CPU_* drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format
As I explained in my last followup in the "[PATCH] drm: fourcc byteorder: brings header file comments in line with reality." thread, the mapping between GPU and CPU formats has to be provided by the driver, it cannot be done statically.
Well, the drm fourcc codes represent the cpu view (i.e. what userspace will fill the ADDFB2-created framebuffers with).
Ville is adamant that they represent the GPU view. This needs to be resolved one way or the other.
Since the byte swapping can happen either for CPU or display access I guess we can't just consider the GPU and display as a single entity.
We may need to consider several agents:
- display
- GPU
- CPU
- other DMA
Not sure what we can say about 4. I presume it's going to be like the GPU or the CPU in the sense that it might go through the CPU byte swapping logic or not. I'm just going to ignore it.
Let's say we have the following bytes in memory (in order of increasing address): A,B,C,D We'll assume GPU and display are LE natively. Each component will see the resulting 32bpp 8888 pixel as follows (msb left->lsb right):
LE CPU w/ no byte swapping: display: DCBA GPU: DCBA CPU: DCBA = everyone agrees
BE CPU w/ no byte swapping: display: DCBA GPU: DCBA CPU: ABCD = GPU and display agree
BE CPU w/ display byte swapping: display: ABCD GPU: DCBA CPU: ABCD = CPU and display agree
BE CPU w/ CPU access byte swapping: display: DCBA GPU: DCBA CPU: DCBA = everyone agrees
Beware that for this list, you're using a format definition which is based on a packed 32-bit value. This does *not* match the current DRM_FORMAT_*8888 definitions. E.g. in the last case, display and GPU use the same DRM_FORMAT, but the CPU uses the "inverse" one.