All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To: Samuel Holland <samuel@sholland.org>,
	Andreas Kemnade <andreas@kemnade.info>
Cc: "Heiko Stübner" <heiko@sntech.de>,
	"Sandy Huang" <hjc@rock-chips.com>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org,
	"Alistair Francis" <alistair@alistair23.me>,
	"Ondřej Jirman" <x@xff.cz>, "Daniel Vetter" <daniel@ffwll.ch>,
	"David Airlie" <airlied@linux.ie>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Liang Chen" <cl@rock-chips.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/16] drm/rockchip: Rockchip EBC ("E-Book Controller") display driver
Date: Thu, 21 Apr 2022 09:10:15 +0200	[thread overview]
Message-ID: <1790161.aHo8FjPgqx@archbook> (raw)
In-Reply-To: <20220421084338.084c4d6e@aktux>

On Donnerstag, 21. April 2022 08:43:38 CEST Andreas Kemnade wrote:
> On Wed, 13 Apr 2022 17:19:00 -0500
> Samuel Holland <samuel@sholland.org> wrote:
> > Blitting/Blending in Software
> > =============================
> > There are multiple layers to this topic (pun slightly intended):
> >  1) Today's userspace does not expect a grayscale framebuffer.
> >     Currently, the driver advertises XRGB8888 and converts to Y4
> >     in software. This seems to match other drivers (e.g. repaper).
> > 
> >  2) Ignoring what userspace "wants", the closest existing format is
> >     DRM_FORMAT_R8. Geert sent a series[4] adding DRM_FORMAT_R1 through
> >     DRM_FORMAT_R4 (patch 9), which I believe are the "correct" formats
> >     to use.
> >
> hmm R=red? That sounds strange. I am unsure whether doing things with
> lower bit depths actually really helps. 

Hi,

for single-component formats, the name of the component plays
practically no role. Even if said component was really red,
it makes little difference to either side.

For example, the OpenGL straight up refers to all single component
image formats as only using the red component:

	OpenGL only allows "R", "RG", "RGB", or "RGBA"; other
	combinations are not allowed as internal image formats.

from https://www.khronos.org/opengl/wiki/Image_Format

In truth it would of course be nice if the world agreed on
not making the name of data structures imply some way they
are to be processed, but humanity hasn't gotten there yet.

> 
> Regards,
> Andreas
> 

Regards,
Nicolas Frattaroli



WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To: Samuel Holland <samuel@sholland.org>,
	Andreas Kemnade <andreas@kemnade.info>
Cc: "David Airlie" <airlied@linux.ie>, "Ondřej Jirman" <x@xff.cz>,
	dri-devel@lists.freedesktop.org,
	"Sandy Huang" <hjc@rock-chips.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	linux-rockchip@lists.infradead.org,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Liang Chen" <cl@rock-chips.com>,
	devicetree@vger.kernel.org,
	"Alistair Francis" <alistair@alistair23.me>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Peter Geis" <pgwipeout@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>
Subject: Re: [RFC PATCH 00/16] drm/rockchip: Rockchip EBC ("E-Book Controller") display driver
Date: Thu, 21 Apr 2022 09:10:15 +0200	[thread overview]
Message-ID: <1790161.aHo8FjPgqx@archbook> (raw)
In-Reply-To: <20220421084338.084c4d6e@aktux>

On Donnerstag, 21. April 2022 08:43:38 CEST Andreas Kemnade wrote:
> On Wed, 13 Apr 2022 17:19:00 -0500
> Samuel Holland <samuel@sholland.org> wrote:
> > Blitting/Blending in Software
> > =============================
> > There are multiple layers to this topic (pun slightly intended):
> >  1) Today's userspace does not expect a grayscale framebuffer.
> >     Currently, the driver advertises XRGB8888 and converts to Y4
> >     in software. This seems to match other drivers (e.g. repaper).
> > 
> >  2) Ignoring what userspace "wants", the closest existing format is
> >     DRM_FORMAT_R8. Geert sent a series[4] adding DRM_FORMAT_R1 through
> >     DRM_FORMAT_R4 (patch 9), which I believe are the "correct" formats
> >     to use.
> >
> hmm R=red? That sounds strange. I am unsure whether doing things with
> lower bit depths actually really helps. 

Hi,

for single-component formats, the name of the component plays
practically no role. Even if said component was really red,
it makes little difference to either side.

For example, the OpenGL straight up refers to all single component
image formats as only using the red component:

	OpenGL only allows "R", "RG", "RGB", or "RGBA"; other
	combinations are not allowed as internal image formats.

from https://www.khronos.org/opengl/wiki/Image_Format

In truth it would of course be nice if the world agreed on
not making the name of data structures imply some way they
are to be processed, but humanity hasn't gotten there yet.

> 
> Regards,
> Andreas
> 

Regards,
Nicolas Frattaroli



WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To: Samuel Holland <samuel@sholland.org>,
	Andreas Kemnade <andreas@kemnade.info>
Cc: "Heiko Stübner" <heiko@sntech.de>,
	"Sandy Huang" <hjc@rock-chips.com>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org,
	"Alistair Francis" <alistair@alistair23.me>,
	"Ondřej Jirman" <x@xff.cz>, "Daniel Vetter" <daniel@ffwll.ch>,
	"David Airlie" <airlied@linux.ie>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Liang Chen" <cl@rock-chips.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/16] drm/rockchip: Rockchip EBC ("E-Book Controller") display driver
Date: Thu, 21 Apr 2022 09:10:15 +0200	[thread overview]
Message-ID: <1790161.aHo8FjPgqx@archbook> (raw)
In-Reply-To: <20220421084338.084c4d6e@aktux>

On Donnerstag, 21. April 2022 08:43:38 CEST Andreas Kemnade wrote:
> On Wed, 13 Apr 2022 17:19:00 -0500
> Samuel Holland <samuel@sholland.org> wrote:
> > Blitting/Blending in Software
> > =============================
> > There are multiple layers to this topic (pun slightly intended):
> >  1) Today's userspace does not expect a grayscale framebuffer.
> >     Currently, the driver advertises XRGB8888 and converts to Y4
> >     in software. This seems to match other drivers (e.g. repaper).
> > 
> >  2) Ignoring what userspace "wants", the closest existing format is
> >     DRM_FORMAT_R8. Geert sent a series[4] adding DRM_FORMAT_R1 through
> >     DRM_FORMAT_R4 (patch 9), which I believe are the "correct" formats
> >     to use.
> >
> hmm R=red? That sounds strange. I am unsure whether doing things with
> lower bit depths actually really helps. 

Hi,

for single-component formats, the name of the component plays
practically no role. Even if said component was really red,
it makes little difference to either side.

For example, the OpenGL straight up refers to all single component
image formats as only using the red component:

	OpenGL only allows "R", "RG", "RGB", or "RGBA"; other
	combinations are not allowed as internal image formats.

from https://www.khronos.org/opengl/wiki/Image_Format

In truth it would of course be nice if the world agreed on
not making the name of data structures imply some way they
are to be processed, but humanity hasn't gotten there yet.

> 
> Regards,
> Andreas
> 

Regards,
Nicolas Frattaroli



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To: Samuel Holland <samuel@sholland.org>,
	Andreas Kemnade <andreas@kemnade.info>
Cc: "Heiko Stübner" <heiko@sntech.de>,
	"Sandy Huang" <hjc@rock-chips.com>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org,
	"Alistair Francis" <alistair@alistair23.me>,
	"Ondřej Jirman" <x@xff.cz>, "Daniel Vetter" <daniel@ffwll.ch>,
	"David Airlie" <airlied@linux.ie>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Liang Chen" <cl@rock-chips.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/16] drm/rockchip: Rockchip EBC ("E-Book Controller") display driver
Date: Thu, 21 Apr 2022 09:10:15 +0200	[thread overview]
Message-ID: <1790161.aHo8FjPgqx@archbook> (raw)
In-Reply-To: <20220421084338.084c4d6e@aktux>

On Donnerstag, 21. April 2022 08:43:38 CEST Andreas Kemnade wrote:
> On Wed, 13 Apr 2022 17:19:00 -0500
> Samuel Holland <samuel@sholland.org> wrote:
> > Blitting/Blending in Software
> > =============================
> > There are multiple layers to this topic (pun slightly intended):
> >  1) Today's userspace does not expect a grayscale framebuffer.
> >     Currently, the driver advertises XRGB8888 and converts to Y4
> >     in software. This seems to match other drivers (e.g. repaper).
> > 
> >  2) Ignoring what userspace "wants", the closest existing format is
> >     DRM_FORMAT_R8. Geert sent a series[4] adding DRM_FORMAT_R1 through
> >     DRM_FORMAT_R4 (patch 9), which I believe are the "correct" formats
> >     to use.
> >
> hmm R=red? That sounds strange. I am unsure whether doing things with
> lower bit depths actually really helps. 

Hi,

for single-component formats, the name of the component plays
practically no role. Even if said component was really red,
it makes little difference to either side.

For example, the OpenGL straight up refers to all single component
image formats as only using the red component:

	OpenGL only allows "R", "RG", "RGB", or "RGBA"; other
	combinations are not allowed as internal image formats.

from https://www.khronos.org/opengl/wiki/Image_Format

In truth it would of course be nice if the world agreed on
not making the name of data structures imply some way they
are to be processed, but humanity hasn't gotten there yet.

> 
> Regards,
> Andreas
> 

Regards,
Nicolas Frattaroli



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-04-21  7:10 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13 22:19 [RFC PATCH 00/16] drm/rockchip: Rockchip EBC ("E-Book Controller") display driver Samuel Holland
2022-04-13 22:19 ` Samuel Holland
2022-04-13 22:19 ` Samuel Holland
2022-04-13 22:19 ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 01/16] drm: Add a helper library for EPD drivers Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 02/16] dt-bindings: display: rockchip: Add EBC binding Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-14  8:15   ` Andreas Kemnade
2022-04-14  8:15     ` Andreas Kemnade
2022-04-14  8:15     ` Andreas Kemnade
2022-04-14  8:15     ` Andreas Kemnade
2022-04-15  3:00     ` Samuel Holland
2022-04-15  3:00       ` Samuel Holland
2022-04-15  3:00       ` Samuel Holland
2022-04-15  3:00       ` Samuel Holland
2022-04-15 11:45       ` Andreas Kemnade
2022-04-15 11:45         ` Andreas Kemnade
2022-04-15 11:45         ` Andreas Kemnade
2022-04-15 11:45         ` Andreas Kemnade
2022-04-13 22:19 ` [RFC PATCH 03/16] drm/rockchip: Add EBC platform driver skeleton Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 04/16] drm/rockchip: ebc: Add DRM " Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 05/16] drm/rockchip: ebc: Add CRTC mode setting Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 06/16] drm/rockchip: ebc: Add CRTC refresh thread Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 07/16] drm/rockchip: ebc: Add CRTC buffer management Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 08/16] drm/rockchip: ebc: Add LUT loading Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 09/16] drm/rockchip: ebc: Implement global refreshes Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 10/16] drm/rockchip: ebc: Implement partial refreshes Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 11/16] drm/rockchip: ebc: Enable diff mode for " Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 12/16] drm/rockchip: ebc: Add support for direct mode Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 13/16] drm/rockchip: ebc: Add a panel reflection option Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 14/16] drm/panel-simple: Add eInk ED103TC2 Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 15/16] arm64: dts: rockchip: rk356x: Add EBC node Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19 ` [RFC PATCH 16/16] [DO NOT MERGE] arm64: dts: rockchip: pinenote: Enable EBC display pipeline Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-13 22:19   ` Samuel Holland
2022-04-14  8:50 ` [RFC PATCH 00/16] drm/rockchip: Rockchip EBC ("E-Book Controller") display driver Maxime Ripard
2022-04-14  8:50   ` Maxime Ripard
2022-04-14  8:50   ` Maxime Ripard
2022-04-14  8:50   ` Maxime Ripard
2022-05-25 17:18   ` Daniel Vetter
2022-05-25 17:18     ` Daniel Vetter
2022-05-25 17:18     ` Daniel Vetter
2022-05-25 17:18     ` Daniel Vetter
2022-05-31  8:58     ` Maxime Ripard
2022-05-31  8:58       ` Maxime Ripard
2022-05-31  8:58       ` Maxime Ripard
2022-06-01 12:35       ` Daniel Vetter
2022-06-01 12:35         ` Daniel Vetter
2022-06-01 12:35         ` Daniel Vetter
2022-06-01 12:35         ` Daniel Vetter
2022-06-08 14:48         ` Maxime Ripard
2022-06-08 14:48           ` Maxime Ripard
2022-06-08 14:48           ` Maxime Ripard
2022-06-08 15:34           ` Daniel Vetter
2022-06-08 15:34             ` Daniel Vetter
2022-06-08 15:34             ` Daniel Vetter
2022-06-08 15:34             ` Daniel Vetter
2022-04-21  6:43 ` Andreas Kemnade
2022-04-21  6:43   ` Andreas Kemnade
2022-04-21  6:43   ` Andreas Kemnade
2022-04-21  6:43   ` Andreas Kemnade
2022-04-21  7:10   ` Nicolas Frattaroli [this message]
2022-04-21  7:10     ` Nicolas Frattaroli
2022-04-21  7:10     ` Nicolas Frattaroli
2022-04-21  7:10     ` Nicolas Frattaroli

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=1790161.aHo8FjPgqx@archbook \
    --to=frattaroli.nicolas@gmail.com \
    --cc=airlied@linux.ie \
    --cc=alistair@alistair23.me \
    --cc=andreas@kemnade.info \
    --cc=cl@rock-chips.com \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=michael.riesch@wolfvision.net \
    --cc=mripard@kernel.org \
    --cc=pgwipeout@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=samuel@sholland.org \
    --cc=thierry.reding@gmail.com \
    --cc=tzimmermann@suse.de \
    --cc=x@xff.cz \
    /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.