From: Hector Palacios <hector.palacios@digi.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "fabio.estevam@freescale.com" <fabio.estevam@freescale.com>,
<s.hauer@pengutronix.de>,
"maxime.ripard@free-electrons.com"
<maxime.ripard@free-electrons.com>, <brian@crystalfontz.com>
Subject: mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours
Date: Thu, 23 May 2013 13:55:28 +0200 [thread overview]
Message-ID: <519E03B0.1080006@digi.com> (raw)
Hello,
I'm using an i.MX28 based board with lcd connected with 18bits data bus.
My platform uses 32 bits per pixel:
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
With these settings the mxsfb.c driver sets flag DATA_FORMAT_24_BIT at HW_LCDIF_CTRL
register in function mxsfb_set_par():
case 32:
dev_dbg(&host->pdev->dev, "Setting up RGB888/666 mode\n");
ctrl |= CTRL_SET_WORD_LENGTH(3);
switch (host->ld_intf_width) {
case STMLCDIF_8BIT:
dev_dbg(&host->pdev->dev,
"Unsupported LCD bus width mapping\n");
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;
}
According to the manual, this flag does:
0x0: ALL_24_BITS_VALID: Data input to the block is in 24 bpp format, such that all
RGB 888 data is contained in 24 bits.
0x1: DROP_UPPER_2_BITS_PER_BYTE — Data input to the block is actually RGB 18 bpp, but
there is 1 colour per byte, hence the upper 2 bits in each byte do not contain any
useful data, and should be dropped.
The setting of this flag is producing bad colours with true colour images (i.e. the
Linux penguin is displayed ok, but QT applications or images displayed with fbv are not).
I believe the setting of this flag is not correct (after all, if my bpp is 32, then
all 24bit colours are useful and dropping the upper 2 bits is a bad idea).
If I don't set it, then true colour images are displayed correctly. The only problem
is that the Linux penguin is displayed much darker than usual (correct colours, but
darker). Perhaps the 224 colour format of this image justifies it?
I noticed the cfa10049 platform also uses the same configuration (18 bits data bus and
32bpp) and was wondering if true colour images are correctly displayed in this
platform with this flag set (for example with fbv application [1]).
Regards,
--
Héctor Palacios
[1] http://freecode.com/projects/fbv
next reply other threads:[~2013-05-23 11:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-23 11:55 Hector Palacios [this message]
2013-05-23 13:00 ` mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours maxime.ripard
2013-05-23 13:31 ` Juergen Beisert
2013-05-23 15:56 ` Hector Palacios
2013-05-24 10:28 ` Juergen Beisert
2013-05-24 10:43 ` Hector Palacios
2013-05-24 11:00 ` Juergen Beisert
2013-05-24 13:33 ` Juergen Beisert
2013-06-07 7:21 ` maxime.ripard
2013-06-07 7:28 ` Hector Palacios
2013-06-07 7:34 ` Juergen Beisert
2013-06-07 7:42 ` maxime.ripard
2013-06-07 8:10 ` [PATCH] video: mxsfb: fix color settings for 18bit data bus and 32bpp Hector Palacios
2013-06-07 9:02 ` maxime.ripard
2013-06-18 8:32 ` maxime.ripard
2013-06-18 8:45 ` Hector Palacios
2013-05-24 8:11 ` mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours maxime.ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=519E03B0.1080006@digi.com \
--to=hector.palacios@digi.com \
--cc=brian@crystalfontz.com \
--cc=fabio.estevam@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox