From: Egbert Eich eich@suse.de
The radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32MB VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different colors is more than one gets on a VGA text console. However this leads to a poor 8bit pseudo-color visual when running X on fbdev, too, which is quite ugly.
In this patch, we try to give some moderate compromise: limit the framebuffer bpp to 8 only when VRAM is 8MB or less, and use 16 bpp otherwise for 32MB or less VRAM.
Signed-off-by: Egbert Eich eich@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de ---
This has been included in SUSE kernel for quite some time, and I'm trying to upstream this. The 16bpp looks more reasonable nowadays, but I know this is a matter of taste, too. It'd be great if you guys can comment on this, at least, whether it's uttly non-sense or not.
thanks,
Takashi
drivers/gpu/drm/radeon/radeon_fb.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 356ad90a5238..b5f2642f124b 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -347,9 +347,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) if (list_empty(&rdev->ddev->mode_config.connector_list)) return 0;
- /* select 8 bpp console on RN50 or 16MB cards */ - if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024)) + /* select 8 bpp console on 8MB cards, or 16 bpp on RN50 or 32MB */ + if (rdev->mc.real_vram_size <= (8*1024*1024)) bpp_sel = 8; + else if (ASIC_IS_RN50(rdev) || + rdev->mc.real_vram_size <= (32*1024*1024)) + bpp_sel = 16;
rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); if (!rfbdev)
On 18/07/17 11:20 AM, Takashi Iwai wrote:
From: Egbert Eich eich@suse.de
The radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32MB VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different colors is more than one gets on a VGA text console. However this leads to a poor 8bit pseudo-color visual when running X on fbdev, too, which is quite ugly.
In this patch, we try to give some moderate compromise: limit the framebuffer bpp to 8 only when VRAM is 8MB or less, and use 16 bpp otherwise for 32MB or less VRAM.
Signed-off-by: Egbert Eich eich@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de
This has been included in SUSE kernel for quite some time, and I'm trying to upstream this. The 16bpp looks more reasonable nowadays, but I know this is a matter of taste, too. It'd be great if you guys can comment on this, at least, whether it's uttly non-sense or not.
[...]
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 356ad90a5238..b5f2642f124b 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -347,9 +347,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) if (list_empty(&rdev->ddev->mode_config.connector_list)) return 0;
- /* select 8 bpp console on RN50 or 16MB cards */
- if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024))
/* select 8 bpp console on 8MB cards, or 16 bpp on RN50 or 32MB */
if (rdev->mc.real_vram_size <= (8*1024*1024)) bpp_sel = 8;
else if (ASIC_IS_RN50(rdev) ||
rdev->mc.real_vram_size <= (32*1024*1024))bpp_sel = 16;rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); if (!rfbdev)
Looks reasonable to me — if nothing else, at least the comment and code will match again! :)
My only potential doubt is whether there could be another reason than VRAM size why RN50 should use 8 bpp. Assuming not,
Reviewed-by: Michel Dänzer michel.daenzer@amd.com
On Tue, 18 Jul 2017 22:53:48 +0200, Michel D4nzer wrote:
On 18/07/17 11:20 AM, Takashi Iwai wrote:
From: Egbert Eich eich@suse.de
The radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32MB VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different colors is more than one gets on a VGA text console. However this leads to a poor 8bit pseudo-color visual when running X on fbdev, too, which is quite ugly.
In this patch, we try to give some moderate compromise: limit the framebuffer bpp to 8 only when VRAM is 8MB or less, and use 16 bpp otherwise for 32MB or less VRAM.
Signed-off-by: Egbert Eich eich@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de
This has been included in SUSE kernel for quite some time, and I'm trying to upstream this. The 16bpp looks more reasonable nowadays, but I know this is a matter of taste, too. It'd be great if you guys can comment on this, at least, whether it's uttly non-sense or not.
[...]
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 356ad90a5238..b5f2642f124b 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -347,9 +347,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) if (list_empty(&rdev->ddev->mode_config.connector_list)) return 0;
- /* select 8 bpp console on RN50 or 16MB cards */
- if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024))
- /* select 8 bpp console on 8MB cards, or 16 bpp on RN50 or 32MB */
- if (rdev->mc.real_vram_size <= (8*1024*1024)) bpp_sel = 8;
- else if (ASIC_IS_RN50(rdev) ||
rdev->mc.real_vram_size <= (32*1024*1024))bpp_sel = 16; rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL);Looks reasonable to me — if nothing else, at least the comment and code will match again! :)
My only potential doubt is whether there could be another reason than VRAM size why RN50 should use 8 bpp. Assuming not,
We also hope there no such popular board :) FWIW, at least we didn't get a relevant bug report, so far.
Reviewed-by: Michel Dänzer michel.daenzer@amd.com
Thanks!
Takashi
On Wed, Jul 19, 2017 at 4:45 AM, Takashi Iwai tiwai@suse.de wrote:
On Tue, 18 Jul 2017 22:53:48 +0200, Michel D4nzer wrote:
On 18/07/17 11:20 AM, Takashi Iwai wrote:
From: Egbert Eich eich@suse.de
The radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32MB VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different colors is more than one gets on a VGA text console. However this leads to a poor 8bit pseudo-color visual when running X on fbdev, too, which is quite ugly.
In this patch, we try to give some moderate compromise: limit the framebuffer bpp to 8 only when VRAM is 8MB or less, and use 16 bpp otherwise for 32MB or less VRAM.
Signed-off-by: Egbert Eich eich@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de
This has been included in SUSE kernel for quite some time, and I'm trying to upstream this. The 16bpp looks more reasonable nowadays, but I know this is a matter of taste, too. It'd be great if you guys can comment on this, at least, whether it's uttly non-sense or not.
[...]
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 356ad90a5238..b5f2642f124b 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -347,9 +347,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) if (list_empty(&rdev->ddev->mode_config.connector_list)) return 0;
- /* select 8 bpp console on RN50 or 16MB cards */
- if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024))
- /* select 8 bpp console on 8MB cards, or 16 bpp on RN50 or 32MB */
- if (rdev->mc.real_vram_size <= (8*1024*1024)) bpp_sel = 8;
- else if (ASIC_IS_RN50(rdev) ||
rdev->mc.real_vram_size <= (32*1024*1024))bpp_sel = 16; rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL);Looks reasonable to me — if nothing else, at least the comment and code will match again! :)
My only potential doubt is whether there could be another reason than VRAM size why RN50 should use 8 bpp. Assuming not,
We also hope there no such popular board :) FWIW, at least we didn't get a relevant bug report, so far.
Reviewed-by: Michel Dänzer michel.daenzer@amd.com
Thanks!
Applied. thanks!
Alex
Takashi _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Michel Dänzer -
Takashi Iwai