Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
On Wed, 2009-09-16 at 08:20 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. If the mode_set_base hook is supposed to handle depth changes, there should be no flicker, should there? Yup exactly, so if we fix that this should be fine. Actually, how's the palette supposed to be handled if mode_set_base needs to switch from depth 16 to 24? Unless I'm missing something, the existing palette will be at least incomplete. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:20 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. If the mode_set_base hook is supposed to handle depth changes, there should be no flicker, should there? Yup exactly, so if we fix that this should be fine. Actually, how's the palette supposed to be handled if mode_set_base needs to switch from depth 16 to 24? Unless I'm missing something, the existing palette will be at least incomplete. We don't set the palette in mode set either now do we, its loaded in the dpms on function, maybe we should call it in the mode set base case as well. Dave. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
On Wed, 2009-09-16 at 17:16 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:20 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. If the mode_set_base hook is supposed to handle depth changes, there should be no flicker, should there? Yup exactly, so if we fix that this should be fine. Actually, how's the palette supposed to be handled if mode_set_base needs to switch from depth 16 to 24? Unless I'm missing something, the existing palette will be at least incomplete. We don't set the palette in mode set either now do we, its loaded in the dpms on function, maybe we should call it in the mode set base case as well. But where would it get the missing entries from? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 17:16 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:20 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. If the mode_set_base hook is supposed to handle depth changes, there should be no flicker, should there? Yup exactly, so if we fix that this should be fine. Actually, how's the palette supposed to be handled if mode_set_base needs to switch from depth 16 to 24? Unless I'm missing something, the existing palette will be at least incomplete. We don't set the palette in mode set either now do we, its loaded in the dpms on function, maybe we should call it in the mode set base case as well. But where would it get the missing entries from? I think the default lut values would suffice. If X is setting a mode it'll probably load the LUT anyways. Dave. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. Dave. Signed-off-by: Michel Dänzer daen...@vmware.com --- drivers/gpu/drm/radeon/radeon_fb.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 28818eb..6ee7843 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -227,10 +227,10 @@ int radeonfb_create(struct drm_device *dev, mode_cmd.width = surface_width; mode_cmd.height = surface_height; - mode_cmd.bpp = 32; + mode_cmd.bpp = 16; /* need to align pitch with crtc limits */ mode_cmd.pitch = radeon_align_pitch(rdev, mode_cmd.width, mode_cmd.bpp, fb_tiled) * ((mode_cmd.bpp + 1) / 8); - mode_cmd.depth = 24; + mode_cmd.depth = 16; size = mode_cmd.pitch * mode_cmd.height; aligned_size = ALIGN(size, PAGE_SIZE); -- 1.6.3.3 -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. If the mode_set_base hook is supposed to handle depth changes, there should be no flicker, should there? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. If the mode_set_base hook is supposed to handle depth changes, there should be no flicker, should there? Yup exactly, so if we fix that this should be fine. Dave. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
