public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

             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