| Message ID | 1351096402-5802-1-git-send-email-eich@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich <eich@suse.de> wrote: > The Radeon driver reduces the framebuffer resolution to 8bpp if > a device with less than 32 Mb 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. > It is done to give X more memory to work with since the console memory > is not freed but remains allocated while X is active. > Still, running the fbdev Xserver driver - which we do during installation > - will give applications an 8bit pseudo-color visual which doesn't look > too pretty. > We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower > and to 8 only if 8MB or less VRAM is found. > This should be a reasonable compromise for us. > This patch will most likely not ever make it upstream. > > This works around ugly modes on crappy IPMI cards using ES1000. I don't have a strong opinion either way on this one. Alex > > Signed-off-by: Egbert Eich <eich@suse.de> > --- > drivers/gpu/drm/radeon/radeon_fb.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c > index cc8489d..9e8e221 100644 > --- a/drivers/gpu/drm/radeon/radeon_fb.c > +++ b/drivers/gpu/drm/radeon/radeon_fb.c > @@ -356,9 +356,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) > int bpp_sel = 32; > int ret; > > - /* select 8 bpp console on RN50 or 16MB cards */ > - if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024)) > + /* select 16 bpp console on RN50 or 32MB cards */ > + 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) > -- > 1.7.6.3 >
On Thu, Oct 25, 2012 at 3:07 AM, Alex Deucher <alexdeucher@gmail.com> wrote: > On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich <eich@suse.de> wrote: >> The Radeon driver reduces the framebuffer resolution to 8bpp if >> a device with less than 32 Mb 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. >> It is done to give X more memory to work with since the console memory >> is not freed but remains allocated while X is active. >> Still, running the fbdev Xserver driver - which we do during installation >> - will give applications an 8bit pseudo-color visual which doesn't look >> too pretty. >> We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower >> and to 8 only if 8MB or less VRAM is found. >> This should be a reasonable compromise for us. >> This patch will most likely not ever make it upstream. >> >> This works around ugly modes on crappy IPMI cards using ES1000. > > I don't have a strong opinion either way on this one. Why would you use fbdev? package -modesetting at least if not the real ATI DDX. Dave.
On Mit, 2012-10-24 at 18:33 +0200, Egbert Eich wrote: > The Radeon driver reduces the framebuffer resolution to 8bpp if > a device with less than 32 Mb 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. > It is done to give X more memory to work with since the console memory > is not freed but remains allocated while X is active. > Still, running the fbdev Xserver driver - which we do during installation > - will give applications an 8bit pseudo-color visual which doesn't look > too pretty. Is it not possible for xf86-video-fbdev to choose a higher depth anyway, even if specified explicitly in xorg.conf or on the Xorg command line? > We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower > and to 8 only if 8MB or less VRAM is found. > This should be a reasonable compromise for us. > This patch will most likely not ever make it upstream. This last sentence seems stale here. :)
Dave Airlie writes: > On Thu, Oct 25, 2012 at 3:07 AM, Alex Deucher <alexdeucher@gmail.com> wrote: > > On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich <eich@suse.de> wrote: > >> The Radeon driver reduces the framebuffer resolution to 8bpp if > >> a device with less than 32 Mb 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. > >> It is done to give X more memory to work with since the console memory > >> is not freed but remains allocated while X is active. > >> Still, running the fbdev Xserver driver - which we do during installation > >> - will give applications an 8bit pseudo-color visual which doesn't look > >> too pretty. > >> We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower > >> and to 8 only if 8MB or less VRAM is found. > >> This should be a reasonable compromise for us. > >> This patch will most likely not ever make it upstream. > >> > >> This works around ugly modes on crappy IPMI cards using ES1000. > > > > I don't have a strong opinion either way on this one. > > Why would you use fbdev? package -modesetting at least if not the real ATI DDX. > fbdev is good as a general fallback which works pretty much everywhere - even if there's no KMS driver available in the kernel (in this case with vesa fbdev). I'm not pushing strongly for this patch making it into the mainline kernel, I need to carry it around for our enterprise product for the time being. It could well be that it can be tossed once we redesign things for SLE13. But maybe you may want to repace the '<=' with a '<' so that the code matches the comment above ie. that one gets 8bpp only for 16MB and less which would already help. Cheers, Egbert.
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index cc8489d..9e8e221 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -356,9 +356,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) int bpp_sel = 32; int ret; - /* select 8 bpp console on RN50 or 16MB cards */ - if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024)) + /* select 16 bpp console on RN50 or 32MB cards */ + 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)
The Radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32 Mb 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. It is done to give X more memory to work with since the console memory is not freed but remains allocated while X is active. Still, running the fbdev Xserver driver - which we do during installation - will give applications an 8bit pseudo-color visual which doesn't look too pretty. We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower and to 8 only if 8MB or less VRAM is found. This should be a reasonable compromise for us. This patch will most likely not ever make it upstream. This works around ugly modes on crappy IPMI cards using ES1000. Signed-off-by: Egbert Eich <eich@suse.de> --- drivers/gpu/drm/radeon/radeon_fb.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)