mbox series

[v3,00/10] drm: Add support for low-color frame buffer formats

Message ID cover.1657294931.git.geert@linux-m68k.org (mailing list archive)
Headers show
Series drm: Add support for low-color frame buffer formats | expand

Message

Geert Uytterhoeven July 8, 2022, 6:20 p.m. UTC
Hi all,

A long outstanding issue with the DRM subsystem has been the lack of
support for low-color displays, as used typically on older desktop
systems, and on small embedded displays.

This patch series adds support for color-indexed frame buffer formats
with 2, 4, and 16 colors.  It has been tested on ARAnyM using a
work-in-progress Atari DRM driver supporting 2, 4, 16, 256, and 65536
colors, with text console operation, fbtest, and modetest.

Overview:
  - Patch 1 introduces a helper, to be used by later patches in the
    series,
  - Patch 2 introduces a flag to indicate color-indexed formats,
  - Patches 3 and 4 correct calculations of bits per pixel for sub-byte
    pixel formats,
  - Patches 5 and 6 introduce the new C[124] formats,
  - Patch 7 fixes an untested code path,
  - Patch 8 documents the use of "red" for light-on-dark displays,
  - Patches 9 and 10 add more fourcc codes for light-on-dark and
    dark-on-light frame buffer formats, which may be useful for e.g. the
    ssd130x and repaper drivers.

Changes compared to v2[1]:
  - Add Reviewed-by,
  - Document fill order,
  - Fix FB_VISUAL_TRUECOLOR,
  - Replace light-on-dark/dark-on-light by direct/inverse relationship
    between channel value and brightness.

Changes compared to v1[2]:
  - Reshuffle patches,
  - New patch "[PATCH v2 02/10] drm/fourcc: Add
    drm_format_info.is_color_indexed flag",
  - Improve pixel descriptions,
  - Require depth to match bpp in drm_mode_legacy_fb_format(),
  - Set .is_color_indexed flag.
  - Use drm_format_info_bpp() helper instead of deprecated .depth field
    or format-dependent calculations,
  - Use new .is_color_indexed field instead of checking against a list
    of formats,
  - Add Acked-by,
  - Replace FIXME by TODO comment,
  - New patch "[PATCH v2 08/10] [RFC] drm/fourcc: Document that
    single-channel "red" can be any color",
  - Add rationale for adding new formats,
  - Add D[248] for completeness.

Notes:
  - This is the first patch series in a series of 3:
      - To make high-color modes work on big-endian, you also need [3],
      - To make mode selection on the command line work for Atari video
	modes, you need [4].
  - There is also a related series of 3 patch series for modetest:
      - Using modetest with low-color formats (C[124]) requires [5],
      - Using modetest with high-color formats (RG16, XR24) requires
	[6],
      - Using modetest with video mode names containing dashes requires
	[7].
  - As this was used on emulated hardware only, and I do not have Atari
    hardware, I do not have performance figures to compare with fbdev.
    I hope to do proper measuring with an Amiga DRM driver, eventually.
  - While the Atari DRM driver is not fit for submission yet, you can
    find it at [8], if you are adventurous.

Thanks for your comments!

[1] "[PATCH v2 00/10] drm: Add support for low-color frame buffer
    formats"
    https://lore.kernel.org/r/cover.1646683502.git.geert@linux-m68k.org/
[2] "[PATCH 0/8] drm: Add support for low-color frame buffer formats"
    https://lore.kernel.org/r/20220215165226.2738568-1-geert@linux-m68k.org/
[3] "[PATCH 0/3] drm: Endianness fixes"
    https://lore.kernel.org/r/cover.1657300532.git.geert@linux-m68k.org
[4] "[PATCH 0/5] drm/modes: Command line mode selection fixes and
    improvements"
    https://lore.kernel.org/r/cover.1657301107.git.geert@linux-m68k.org
[5] "[PATCH libdrm v2 00/10] Add support for low-color frame buffer
    formats"
    https://lore.kernel.org/r/cover.1657302034.git.geert@linux-m68k.org
[6] "[PATCH libdrm v2 00/10] Big-endian fixes"
    https://lore.kernel.org/r/cover.1657302103.git.geert@linux-m68k.org
[7] "[PATCH libdrm] modetest: Add support for named modes containing
    dashes"
[8] https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=atari-drm-wip

Geert Uytterhoeven (10):
  drm/fourcc: Add drm_format_info_bpp() helper
  drm/fourcc: Add drm_format_info.is_color_indexed flag
  drm/client: Use actual bpp when allocating frame buffers
  drm/framebuffer: Use actual bpp for DRM_IOCTL_MODE_GETFB
  drm/fourcc: Add DRM_FORMAT_C[124]
  drm/fb-helper: Add support for DRM_FORMAT_C[124]
  drm/gem-fb-helper: Use actual bpp for size calculations
  drm/fourcc: Clarify the meaning of single-channel "red"
  [RFC] drm/fourcc: Add DRM_FORMAT_R[124]
  [RFC] drm/fourcc: Add DRM_FORMAT_D[1248]

 drivers/gpu/drm/drm_client.c                 |   4 +-
 drivers/gpu/drm/drm_fb_helper.c              | 101 ++++++++++++++-----
 drivers/gpu/drm/drm_fourcc.c                 |  55 +++++++++-
 drivers/gpu/drm/drm_framebuffer.c            |   2 +-
 drivers/gpu/drm/drm_gem_framebuffer_helper.c |  12 +--
 include/drm/drm_fourcc.h                     |   4 +
 include/uapi/drm/drm_fourcc.h                |  32 +++++-
 7 files changed, 167 insertions(+), 43 deletions(-)

Comments

Sam Ravnborg July 9, 2022, 1:38 p.m. UTC | #1
Hi Geert,

On Fri, Jul 08, 2022 at 08:20:45PM +0200, Geert Uytterhoeven wrote:
> 	Hi all,
> 
> A long outstanding issue with the DRM subsystem has been the lack of
> support for low-color displays, as used typically on older desktop
> systems, and on small embedded displays.

IT is super to have this addressed - thanks!

> 
> This patch series adds support for color-indexed frame buffer formats
> with 2, 4, and 16 colors.  It has been tested on ARAnyM using a
> work-in-progress Atari DRM driver supporting 2, 4, 16, 256, and 65536
> colors, with text console operation, fbtest, and modetest.
> 
> Overview:
>   - Patch 1 introduces a helper, to be used by later patches in the
>     series,
>   - Patch 2 introduces a flag to indicate color-indexed formats,
>   - Patches 3 and 4 correct calculations of bits per pixel for sub-byte
>     pixel formats,
>   - Patches 5 and 6 introduce the new C[124] formats,
>   - Patch 7 fixes an untested code path,
>   - Patch 8 documents the use of "red" for light-on-dark displays,
>   - Patches 9 and 10 add more fourcc codes for light-on-dark and
>     dark-on-light frame buffer formats, which may be useful for e.g. the
>     ssd130x and repaper drivers.

Applied all patches to drm-misc (drm-misc-next), including the last two
RFC patches as we then have the formats ready when a user pops up.

	Sam
Thomas Zimmermann July 11, 2022, 8:50 a.m. UTC | #2
Hi

Am 09.07.22 um 15:38 schrieb Sam Ravnborg:
> Hi Geert,
> 
> On Fri, Jul 08, 2022 at 08:20:45PM +0200, Geert Uytterhoeven wrote:
>> 	Hi all,
>>
>> A long outstanding issue with the DRM subsystem has been the lack of
>> support for low-color displays, as used typically on older desktop
>> systems, and on small embedded displays.

For the patchset

Acked-by: Thomas Zimemrmann <tzimmermann@suse.de>

> 
> IT is super to have this addressed - thanks!
> 
>>
>> This patch series adds support for color-indexed frame buffer formats
>> with 2, 4, and 16 colors.  It has been tested on ARAnyM using a
>> work-in-progress Atari DRM driver supporting 2, 4, 16, 256, and 65536
>> colors, with text console operation, fbtest, and modetest.
>>
>> Overview:
>>    - Patch 1 introduces a helper, to be used by later patches in the
>>      series,
>>    - Patch 2 introduces a flag to indicate color-indexed formats,
>>    - Patches 3 and 4 correct calculations of bits per pixel for sub-byte
>>      pixel formats,
>>    - Patches 5 and 6 introduce the new C[124] formats,
>>    - Patch 7 fixes an untested code path,
>>    - Patch 8 documents the use of "red" for light-on-dark displays,
>>    - Patches 9 and 10 add more fourcc codes for light-on-dark and
>>      dark-on-light frame buffer formats, which may be useful for e.g. the
>>      ssd130x and repaper drivers.
> 
> Applied all patches to drm-misc (drm-misc-next), including the last two
> RFC patches as we then have the formats ready when a user pops up.

I know it's v3 already, but give people at least a workday for reviewing 
before merging patches of this size and impact. Friday-evening patches 
are not supposed to be merged on Saturday afternoons.

Best regards
Thomas

> 
> 	Sam
Sam Ravnborg July 11, 2022, 9:12 a.m. UTC | #3
Hi Thomas,

On Mon, Jul 11, 2022 at 10:50:00AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 09.07.22 um 15:38 schrieb Sam Ravnborg:
> > Hi Geert,
> > 
> > On Fri, Jul 08, 2022 at 08:20:45PM +0200, Geert Uytterhoeven wrote:
> > > 	Hi all,
> > > 
> > > A long outstanding issue with the DRM subsystem has been the lack of
> > > support for low-color displays, as used typically on older desktop
> > > systems, and on small embedded displays.
> 
> For the patchset
> 
> Acked-by: Thomas Zimemrmann <tzimmermann@suse.de>
> 
> > 
> > IT is super to have this addressed - thanks!
> > 
> > > 
> > > This patch series adds support for color-indexed frame buffer formats
> > > with 2, 4, and 16 colors.  It has been tested on ARAnyM using a
> > > work-in-progress Atari DRM driver supporting 2, 4, 16, 256, and 65536
> > > colors, with text console operation, fbtest, and modetest.
> > > 
> > > Overview:
> > >    - Patch 1 introduces a helper, to be used by later patches in the
> > >      series,
> > >    - Patch 2 introduces a flag to indicate color-indexed formats,
> > >    - Patches 3 and 4 correct calculations of bits per pixel for sub-byte
> > >      pixel formats,
> > >    - Patches 5 and 6 introduce the new C[124] formats,
> > >    - Patch 7 fixes an untested code path,
> > >    - Patch 8 documents the use of "red" for light-on-dark displays,
> > >    - Patches 9 and 10 add more fourcc codes for light-on-dark and
> > >      dark-on-light frame buffer formats, which may be useful for e.g. the
> > >      ssd130x and repaper drivers.
> > 
> > Applied all patches to drm-misc (drm-misc-next), including the last two
> > RFC patches as we then have the formats ready when a user pops up.
> 
> I know it's v3 already, but give people at least a workday for reviewing
> before merging patches of this size and impact. Friday-evening patches are
> not supposed to be merged on Saturday afternoons.

Sorry for being too enthusiastic on this one.
Will wait a bit more in the future for these kind of patches.

	Sam
Daniel Vetter Aug. 10, 2022, 4:02 p.m. UTC | #4
On Mon, Jul 11, 2022 at 11:12:51AM +0200, Sam Ravnborg wrote:
> Hi Thomas,
> 
> On Mon, Jul 11, 2022 at 10:50:00AM +0200, Thomas Zimmermann wrote:
> > Hi
> > 
> > Am 09.07.22 um 15:38 schrieb Sam Ravnborg:
> > > Hi Geert,
> > > 
> > > On Fri, Jul 08, 2022 at 08:20:45PM +0200, Geert Uytterhoeven wrote:
> > > > 	Hi all,
> > > > 
> > > > A long outstanding issue with the DRM subsystem has been the lack of
> > > > support for low-color displays, as used typically on older desktop
> > > > systems, and on small embedded displays.
> > 
> > For the patchset
> > 
> > Acked-by: Thomas Zimemrmann <tzimmermann@suse.de>
> > 
> > > 
> > > IT is super to have this addressed - thanks!
> > > 
> > > > 
> > > > This patch series adds support for color-indexed frame buffer formats
> > > > with 2, 4, and 16 colors.  It has been tested on ARAnyM using a
> > > > work-in-progress Atari DRM driver supporting 2, 4, 16, 256, and 65536
> > > > colors, with text console operation, fbtest, and modetest.
> > > > 
> > > > Overview:
> > > >    - Patch 1 introduces a helper, to be used by later patches in the
> > > >      series,
> > > >    - Patch 2 introduces a flag to indicate color-indexed formats,
> > > >    - Patches 3 and 4 correct calculations of bits per pixel for sub-byte
> > > >      pixel formats,
> > > >    - Patches 5 and 6 introduce the new C[124] formats,
> > > >    - Patch 7 fixes an untested code path,
> > > >    - Patch 8 documents the use of "red" for light-on-dark displays,
> > > >    - Patches 9 and 10 add more fourcc codes for light-on-dark and
> > > >      dark-on-light frame buffer formats, which may be useful for e.g. the
> > > >      ssd130x and repaper drivers.
> > > 
> > > Applied all patches to drm-misc (drm-misc-next), including the last two
> > > RFC patches as we then have the formats ready when a user pops up.
> > 
> > I know it's v3 already, but give people at least a workday for reviewing
> > before merging patches of this size and impact. Friday-evening patches are
> > not supposed to be merged on Saturday afternoons.
> 
> Sorry for being too enthusiastic on this one.
> Will wait a bit more in the future for these kind of patches.

Took me a bit longer to unburry and get to this, and lgtm except patch 1
where I have a semantic concern. Can you pls do the quick patch to adjust
that? Since this is all about the Cx/Rx/Dx formats I don't think it'll
matter really.

Thanks, Daniel