From: Ondrej Zajicek <santiago@crfreenet.org>
To: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Linux-fbdev-devel <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [PATCH] s3fb: mode selection fixes
Date: Mon, 1 Oct 2007 22:49:44 +0200 [thread overview]
Message-ID: <20071001204943.GA2017@localhost.localdomain> (raw)
In-Reply-To: <20071001194345.cd5d609d.krzysztof.h1@poczta.fm>
[-- Attachment #1.1: Type: text/plain, Size: 1669 bytes --]
On Mon, Oct 01, 2007 at 07:43:45PM +0200, Krzysztof Helt wrote:
> > > - sets r,g,b length field from the bits_per_pixel value otherwise
> > > the fbset fails in simple case like switching depths:
> > > 8bpp ->32bpp -> 8bpp
> >
> > When some depth and some color lengths are requested then this driver
> > (or precisely svga_match_format() ) only changes them up (which is correct
> > behavior according to some previous email from A. Daplas).
> >
> > But if you do some partial change of mode using fbset, then fbset uses
> > previous values for unspecified values of var structure in
> > FBIOPUT_VSCREENINFO call. For example if you use 32bpp and do
> > fbset -depth 16, then fbset calls FBIOPUT_VSCREENINFO with arguments
> > requesting depth 16 but color length 8 for each channel. Better way
> > is to put zeroes to color lengths (which is what fbset does when you
> > do something like 'fbset 640x480-60 -depth 16') - workaround is to use
> > argument -rgba 0,0,0,0 with -depth change using fbset.
> >
>
> What is a difference if certain color depths allow only specific color lengths?
No difference. svga_match_format() interprets color lengths in
FBIOPUT_VSCREENINFO as minimal requests.
Perhaps svga_match_format() could be changed to choose any mode with
matching depth in case there is no mode with matching depth and color
lengths. I will send patch.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 228 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
[-- Attachment #3: Type: text/plain, Size: 182 bytes --]
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
prev parent reply other threads:[~2007-10-01 20:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-30 14:10 [PATCH] s3fb: mode selection fixes Krzysztof Helt
2007-09-30 20:31 ` Ondrej Zajicek
2007-10-01 17:43 ` Krzysztof Helt
2007-10-01 20:49 ` Ondrej Zajicek [this message]
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=20071001204943.GA2017@localhost.localdomain \
--to=santiago@crfreenet.org \
--cc=krzysztof.h1@poczta.fm \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.