| Message ID | cover.1657294931.git.geert@linux-m68k.org |
|---|---|
| Headers | show |
| Series | drm: Add support for low-color frame buffer formats | expand |
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
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
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
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
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(-)