All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: amd-gfx@lists.freedesktop.org,
	"Michel Dänzer" <michel@daenzer.net>,
	"open list" <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org,
	"Daniel Vetter" <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Date: Fri, 21 Apr 2017 11:06:05 +0300	[thread overview]
Message-ID: <20170421110605.1a255f44@eldfell> (raw)
In-Reply-To: <20170421075825.6307-1-kraxel@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 1993 bytes --]

On Fri, 21 Apr 2017 09:58:24 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
> 
> Comments says the RGB formats are little endian, but in practice they
> are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
> maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB8888, no matter
> whenever the machine is little endian or big endian.  The users of this
> function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
> is native endian, not little endian.  Most userspace also operates on
> native endian only.
> 
> So, go update the comments for all 16+24+32 bpp RGB formats.
> 
> Leaving the yuv formats as-is.  I have no idea if and how those are used
> on bigendian machines.
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
> Cc: Michel Dänzer <michel@daenzer.net>
> Cc: Alex Deucher <alexdeucher@gmail.com>
> Cc: amd-gfx@lists.freedesktop.org
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  include/uapi/drm/drm_fourcc.h | 82 +++++++++++++++++++++----------------------
>  1 file changed, 41 insertions(+), 41 deletions(-)

Hi,

just an idea - since we are not sure how the remaining formats are being
used, should those be marked somehow uncertain whether they are little
or native endian?

Otherwise the documentation will guide people to believe those are
certain, which OTOH might not be bad, because then it will make them
certain over time. Unless we would prefer everything to be native
endian?

This might be a chance to choose the endianess (native vs. little) for
all formats. Should we take it? Prefer native?


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: dri-devel@lists.freedesktop.org,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Ilia Mirkin" <imirkin@alum.mit.edu>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Alex Deucher" <alexdeucher@gmail.com>,
	amd-gfx@lists.freedesktop.org,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Sean Paul" <seanpaul@chromium.org>,
	"David Airlie" <airlied@linux.ie>,
	linux-kernel@vger.kernel.org (open list)
Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Date: Fri, 21 Apr 2017 11:06:05 +0300	[thread overview]
Message-ID: <20170421110605.1a255f44@eldfell> (raw)
In-Reply-To: <20170421075825.6307-1-kraxel@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Fri, 21 Apr 2017 09:58:24 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
> 
> Comments says the RGB formats are little endian, but in practice they
> are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
> maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB8888, no matter
> whenever the machine is little endian or big endian.  The users of this
> function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
> is native endian, not little endian.  Most userspace also operates on
> native endian only.
> 
> So, go update the comments for all 16+24+32 bpp RGB formats.
> 
> Leaving the yuv formats as-is.  I have no idea if and how those are used
> on bigendian machines.
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
> Cc: Michel Dänzer <michel@daenzer.net>
> Cc: Alex Deucher <alexdeucher@gmail.com>
> Cc: amd-gfx@lists.freedesktop.org
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  include/uapi/drm/drm_fourcc.h | 82 +++++++++++++++++++++----------------------
>  1 file changed, 41 insertions(+), 41 deletions(-)

Hi,

just an idea - since we are not sure how the remaining formats are being
used, should those be marked somehow uncertain whether they are little
or native endian?

Otherwise the documentation will guide people to believe those are
certain, which OTOH might not be bad, because then it will make them
certain over time. Unless we would prefer everything to be native
endian?

This might be a chance to choose the endianess (native vs. little) for
all formats. Should we take it? Prefer native?


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-04-21  8:06 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21  7:58 [PATCH] drm: fourcc byteorder: brings header file comments in line with reality Gerd Hoffmann
2017-04-21  7:58 ` Gerd Hoffmann
2017-04-21  8:06 ` Pekka Paalanen [this message]
2017-04-21  8:06   ` Pekka Paalanen
2017-04-21  9:38   ` Gerd Hoffmann
2017-04-21  9:38     ` Gerd Hoffmann
     [not found]     ` <1492767508.25675.23.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-21  9:44       ` Ville Syrjälä
2017-04-21  9:44         ` Ville Syrjälä
     [not found] ` <20170421075825.6307-1-kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-21  9:25   ` Ville Syrjälä
2017-04-21  9:25     ` Ville Syrjälä
2017-04-21  9:50     ` Gerd Hoffmann
2017-04-21  9:50       ` Gerd Hoffmann
     [not found]       ` <1492768218.25675.33.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-21 11:05         ` Ville Syrjälä
2017-04-21 11:05           ` Ville Syrjälä
2017-04-21 11:08       ` Ville Syrjälä
2017-04-21 11:08         ` Ville Syrjälä
     [not found]         ` <20170421110804.GH30290-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-04-21 11:40           ` Pekka Paalanen
2017-04-21 11:40             ` Pekka Paalanen
2017-04-21 11:49             ` Ville Syrjälä
2017-04-21 11:49               ` Ville Syrjälä
2017-04-21 12:02               ` Christian König
2017-04-21 11:41         ` Gerd Hoffmann
2017-04-21 11:41           ` Gerd Hoffmann
2017-04-21 11:42         ` Christian König
     [not found]           ` <f1b0ae60-b20e-ad52-7fbf-32f2c045f5fc-5C7GfCeVMHo@public.gmane.org>
2017-04-21 13:12             ` Gerd Hoffmann
2017-04-21 13:12               ` Gerd Hoffmann
     [not found]               ` <1492780323.25675.45.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-21 13:21                 ` Christian König
2017-04-21 13:21                   ` Christian König
2017-04-21 13:27                   ` Christian König
2017-04-21 13:27                     ` Christian König
     [not found]                     ` <fab1354d-bb5d-b196-a698-f465906ffc68-5C7GfCeVMHo@public.gmane.org>
2017-04-21 15:21                       ` Harry Wentland
2017-04-21 15:21                         ` Harry Wentland
2017-04-21 16:14                 ` Gerd Hoffmann
2017-04-21 16:14                   ` Gerd Hoffmann
     [not found]                   ` <1492791271.25675.57.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-22 10:05                     ` Ville Syrjälä
2017-04-22 10:05                       ` Ville Syrjälä
2017-04-22 21:59                       ` Gerd Hoffmann
2017-04-22 21:59                         ` Gerd Hoffmann
     [not found]                       ` <20170422100522.GS30290-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-04-24  6:57                         ` Michel Dänzer
2017-04-24  6:57                           ` Michel Dänzer
     [not found]                           ` <de9e5634-ca98-d0e4-e715-c48c860328b2-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-04-24 13:03                             ` Ville Syrjälä
2017-04-24 13:03                               ` Ville Syrjälä
     [not found]                               ` <20170424130348.GV30290-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-04-25  1:12                                 ` Michel Dänzer
2017-04-25  1:12                                   ` Michel Dänzer
     [not found]                                   ` <d5c73823-4d63-c44d-8ba9-54f5e80c5497-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-04-25  3:08                                     ` Michel Dänzer
2017-04-25  3:08                                       ` Michel Dänzer
2017-04-25 10:26                                   ` Ville Syrjälä
2017-04-25 10:26                                     ` Ville Syrjälä
     [not found]                                     ` <20170425102607.GL30290-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-04-26  2:10                                       ` Michel Dänzer
2017-04-26  2:10                                         ` Michel Dänzer
2017-05-11 21:23         ` Pavel Machek
2017-05-11 21:23           ` Pavel Machek
2017-05-12  9:10           ` Ville Syrjälä
2017-05-12  9:10             ` Ville Syrjälä
2017-04-21 14:49   ` Ilia Mirkin
2017-04-21 14:49     ` Ilia Mirkin
     [not found]     ` <CAKb7Uvgx2_O8y+HWGv8TEv0BqpXrLL5SdAt2d3gh6g69U6F=Sw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-21 16:59       ` Ville Syrjälä
2017-04-21 16:59         ` Ville Syrjälä
     [not found]         ` <20170421165907.GQ30290-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-04-22  5:07           ` Ilia Mirkin
2017-04-22  5:07             ` Ilia Mirkin
2017-04-22  9:50             ` Ville Syrjälä
2017-04-22  9:50               ` Ville Syrjälä
     [not found]               ` <20170422095056.GR30290-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-04-22 13:40                 ` Ilia Mirkin
2017-04-22 13:40                   ` Ilia Mirkin
2017-04-22 13:48                   ` Ilia Mirkin
2017-04-22 13:48                     ` Ilia Mirkin
     [not found]                     ` <CAKb7Uvig0J2rg=yJT4g8OuqR9RW4x2TzK-DA_zs_Qc_up4dACQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-22 19:24                       ` Ilia Mirkin
2017-04-22 19:24                         ` Ilia Mirkin
2017-04-24  6:33                         ` Michel Dänzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170421110605.1a255f44@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel@daenzer.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.