From: "Ville Syrjälä" <syrjala@sci.fi>
To: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: spock@gentoo.org,
Linux-fbdev-devel <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Fix 8bpp RGB fields length
Date: Mon, 2 Mar 2009 19:40:49 +0200 [thread overview]
Message-ID: <20090302174049.GB6298@sci.fi> (raw)
In-Reply-To: <20090302180239.f6e67497.krzysztof.h1@poczta.fm>
On Mon, Mar 02, 2009 at 06:02:39PM +0100, Krzysztof Helt wrote:
> On Mon, 2 Mar 2009 15:02:02 +0200
> Ville Syrjälä <syrjala@sci.fi> wrote:
>
> > On Sun, Mar 01, 2009 at 09:55:56PM +0100, Krzysztof Helt wrote:
> > > Hi,
> > >
> > > I found that some fbdev drivers set RGB field's lengths incorrectly
> > > to 6 bits. This is incorrect as the field's length says how many bits
> > > has a color index when using color palette (6 bits = 64 colors).
> >
> > A slight omission in the fbdev API I suppose since the LUT entries are
> > nearly always 3*8bits wide. VGA being the exception.
> >
>
> If offsets of all RGB components are the same the length field says
> how lone the pallete index is. It does not say anything how long
> the LUT entries are. This is the same misunderstanding as done
> inside the driver.
Yes. I meant that the change is correct but the API doesn't provide any
means of conveying the LUT entry size to userspace which is a bit
unfortunate.
> > > Fix this error in uvesafb by dropping DAC switching to 8 bits
> > > completely. Advantage of this approach is making the driver shorter,
> > > disadvantage is that some color fidelity is lost.
> >
> > I don't see much point in dropping this. It would reduce the image
> > quality and it looks like after your first fix this code would amount
> > to less than a dozen lines. But not my call anyway.
> >
>
> I wonder if it affects quality at all as with 256 different pixel values
> selected from over 262000 is not much more better quality that
> if these 256 values are taken from another set of values which
> is only about 3% different.
I suppose it doesn't matter much unless the palette is tuned to produce
nice gradients.
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
next prev parent reply other threads:[~2009-03-02 17:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-01 20:55 Fix 8bpp RGB fields length Krzysztof Helt
2009-03-02 13:02 ` Ville Syrjälä
2009-03-02 17:02 ` Krzysztof Helt
2009-03-02 17:40 ` Ville Syrjälä [this message]
2009-03-29 19:14 ` Michal Januszewski
2009-03-29 19:26 ` Geert Uytterhoeven
2009-03-29 21:18 ` Ville Syrjälä
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=20090302174049.GB6298@sci.fi \
--to=syrjala@sci.fi \
--cc=krzysztof.h1@poczta.fm \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=spock@gentoo.org \
/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;
as well as URLs for NNTP newsgroup(s).