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, 22 Mar 2019 16:42:10 +0200 From: Ville Syrjälä <ville.syrjala@...ux.intel.com> To: Nicolas Dufresne <nicolas@...fresne.ca> Cc: Paul Kocialkowski <paul.kocialkowski@...tlin.com>, Maxime Ripard <maxime.ripard@...tlin.com>, Daniel Vetter <daniel.vetter@...el.com>, David Airlie <airlied@...ux.ie>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Sean Paul <seanpaul@...omium.org>, Mauro Carvalho Chehab <mchehab@...nel.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>, linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org, Hans Verkuil <hans.verkuil@...co.com>, Laurent Pinchart <laurent.pinchart@...asonboard.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>, linux-media@...r.kernel.org, Daniel Stone <daniels@...labora.com> Subject: Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support On Thu, Mar 21, 2019 at 03:14:06PM -0400, Nicolas Dufresne wrote: > Le jeudi 21 mars 2019 à 18:35 +0200, Ville Syrjälä a écrit : > > > I'm not sure what it's worth, but there is a "pixel format guide" > > > project that is all about matching formats from one API to another: > > > https://afrantzis.com/pixel-format-guide/ (and it has an associated > > > tool too). > > > > > > On the page about DRM, it seems that they got the word that DRM formats > > > are the native pixel order in little-endian systems: > > > https://afrantzis.com/pixel-format-guide/drm.html > > > > Looks consistent with the official word in drm_fourcc.h. > > > > $ python3 -m pfg find-compatible V4L2_PIX_FMT_XBGR32 drm > > Format: V4L2_PIX_FMT_XBGR32 > > Is compatible on all systems with: > > DRM_FORMAT_XRGB8888 > > Is compatible on little-endian systems with: > > Is compatible on big-endian systems with: > > > > $ python3 -m pfg find-compatible DRM_FORMAT_XRGB8888 v4l2 > > Format: DRM_FORMAT_XRGB8888 > > Is compatible on all systems with: > > V4L2_PIX_FMT_XBGR32 > > Is compatible on little-endian systems with: > > Is compatible on big-endian systems with: > > > > Even works both ways :) > > > > > Perhaps some drivers have been abusing the format definitions, leading > > > to the inconsistencies that Nicolas could witness? > > > > That is quite possible, perhaps even likely. No one really > > seems interested in making sure big endian systems actually > > work properly. I believe the usual approach is to hack > > around semi-rnadomly until the correct colors accidentally > > appear on the screen. > > We did not hack around randomly. BTW I didn't mean to imply it was you who hacked around randomly. Sorry if you got that impression. What I was trying to convey is the following sequence of events: 1. random person X gets their hand on a big endian machine for a while 2. colors are wrong 3. they hack stuff until the colors are correct in their current use case 4. they move on to more interesting things -- Ville Syrjälä Intel
Powered by blists - more mailing lists