| Message ID | 51B1957F.40104@digi.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Hector, On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote: > For a combination of 18bit LCD data bus width and a color > mode of 32bpp, the driver was setting the color mapping to > rgb666, which is wrong, as the color in memory realy has an > rgb888 layout. > > This patch also removes the setting of flag CTRL_DF24 that > makes the driver dimiss the upper 2 bits when handling 32/24bpp > colors in a diplay with 18bit data bus width. This flag made > true color images display wrong in such configurations. > > Finally, the color mapping rgb666 has also been removed as nobody > is using it and high level applications like Qt5 cannot work > with it either. > > Reference: https://lkml.org/lkml/2013/5/23/220 > Signed-off-by: Hector Palacios <hector.palacios@digi.com> > Acked-by: Juergen Beisert <jbe@pengutronix.de> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Please also note that fbdev is now maintained by Jean Christophe Plagniol-Villard (plagnioj@jcrosoft.com, in CC), and that he is away until the 10th of June, so maybe it should be safe to resend it to him after this date. Thanks! Maxime -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Hector, On Fri, Jun 07, 2013 at 11:02:28AM +0200, maxime.ripard@free-electrons.com wrote: > On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote: > > For a combination of 18bit LCD data bus width and a color > > mode of 32bpp, the driver was setting the color mapping to > > rgb666, which is wrong, as the color in memory realy has an > > rgb888 layout. > > > > This patch also removes the setting of flag CTRL_DF24 that > > makes the driver dimiss the upper 2 bits when handling 32/24bpp > > colors in a diplay with 18bit data bus width. This flag made > > true color images display wrong in such configurations. > > > > Finally, the color mapping rgb666 has also been removed as nobody > > is using it and high level applications like Qt5 cannot work > > with it either. > > > > Reference: https://lkml.org/lkml/2013/5/23/220 > > Signed-off-by: Hector Palacios <hector.palacios@digi.com> > > Acked-by: Juergen Beisert <jbe@pengutronix.de> > > Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > Please also note that fbdev is now maintained by Jean Christophe > Plagniol-Villard (plagnioj@jcrosoft.com, in CC), and that he is away > until the 10th of June, so maybe it should be safe to resend it to him > after this date. It seems like Jean-Christophe is back online, maybe you should resend him the patch now, it would be great to have it for 3.11. Thanks, Maxime
On 06/18/2013 10:32 AM, maxime.ripard@free-electrons.com wrote: > Hi Hector, > > On Fri, Jun 07, 2013 at 11:02:28AM +0200, maxime.ripard@free-electrons.com wrote: >> On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote: >>> For a combination of 18bit LCD data bus width and a color >>> mode of 32bpp, the driver was setting the color mapping to >>> rgb666, which is wrong, as the color in memory realy has an >>> rgb888 layout. >>> >>> This patch also removes the setting of flag CTRL_DF24 that >>> makes the driver dimiss the upper 2 bits when handling 32/24bpp >>> colors in a diplay with 18bit data bus width. This flag made >>> true color images display wrong in such configurations. >>> >>> Finally, the color mapping rgb666 has also been removed as nobody >>> is using it and high level applications like Qt5 cannot work >>> with it either. >>> >>> Reference: https://lkml.org/lkml/2013/5/23/220 >>> Signed-off-by: Hector Palacios <hector.palacios@digi.com> >>> Acked-by: Juergen Beisert <jbe@pengutronix.de> >> >> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> >> >> Please also note that fbdev is now maintained by Jean Christophe >> Plagniol-Villard (plagnioj@jcrosoft.com, in CC), and that he is away >> until the 10th of June, so maybe it should be safe to resend it to him >> after this date. > > It seems like Jean-Christophe is back online, maybe you should resend > him the patch now, it would be great to have it for 3.11. I just resent it. Thanks for the reminder.
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c index 21223d4..d2c5105 100644 --- a/drivers/video/mxsfb.c +++ b/drivers/video/mxsfb.c @@ -239,24 +239,6 @@ static const struct fb_bitfield def_rgb565[] = { } }; -static const struct fb_bitfield def_rgb666[] = { - [RED] = { - .offset = 16, - .length = 6, - }, - [GREEN] = { - .offset = 8, - .length = 6, - }, - [BLUE] = { - .offset = 0, - .length = 6, - }, - [TRANSP] = { /* no support for transparency */ - .length = 0, - } -}; - static const struct fb_bitfield def_rgb888[] = { [RED] = { .offset = 16, @@ -309,9 +291,6 @@ static int mxsfb_check_var(struct fb_var_screeninfo *var, break; case STMLCDIF_16BIT: case STMLCDIF_18BIT: - /* 24 bit to 18 bit mapping */ - rgb = def_rgb666; - break; case STMLCDIF_24BIT: /* real 24 bit */ rgb = def_rgb888; @@ -453,11 +432,6 @@ static int mxsfb_set_par(struct fb_info *fb_info) return -EINVAL; case STMLCDIF_16BIT: case STMLCDIF_18BIT: - /* 24 bit to 18 bit mapping */ - ctrl |= CTRL_DF24; /* ignore the upper 2 bits in - * each colour component - */ - break; case STMLCDIF_24BIT: /* real 24 bit */ break;