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 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).