Date: Thu, 20 Nov 1997 11:57:03 +1100 From: David Dawes <dawes@rf900.physics.usyd.edu.au> To: Pierre Beyssac <Pierre.Beyssac@hsc.fr> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Acrobat problems? Message-ID: <19971120115703.37544@rf900.physics.usyd.edu.au> In-Reply-To: <19971119190230.YE53218@mars.hsc.fr>; from Pierre Beyssac on Wed, Nov 19, 1997 at 07:02:30PM %2B0100 References: <199711170737.BAA03677@zuhause.mn.org> <199711181756.JAA05389@user2.teleport.com> <19971120010935.32146@rf900.physics.usyd.edu.au> <19971119190230.YE53218@mars.hsc.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 19, 1997 at 07:02:30PM +0100, Pierre Beyssac wrote:
>According to David Dawes:
>> The current 24bpp implementation in XFree86 is quite different from most
>> others in that it uses a depth 24 pixmap format with bits-per-pixel also
>> 24 (most others -- including Xig's X server -- have bits-per-pixel 32
>> for their depth 24 pixmap format). Checking the output of xdpyinfo will
>
>I recently had similar problems when playing with shared pixmaps and
>gathered a few xdpyinfos from friends, and consistently got 32
>bits-per-pixel on 24 bits depths with XFree (they all got Matrox
>cards however I believe, so take this with a grain of salt) :
>
>vendor string: The XFree86 Project, Inc
>vendor release number: 3310
>supported pixmap formats:
> depth 1, bits_per_pixel 1, scanline_pad 32
> depth 24, bits_per_pixel 32, scanline_pad 32
I was referring only to the case when the framebuffer is operating in
packed 24bpp mode. For drivers (or chipsets) which don't support that
mode, or when using '-bpp 32', you'll see the above. One exception to
this is the S3V server in 3.3.1. It has code to do 32bpp pixmaps for
packed 24bpp (and this is even newer and more experimental than the
other code). A Millennium with '-bpp 24' shows:
vendor string: The XFree86 Project, Inc
vendor release number: 3310
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 24, bits_per_pixel 24, scanline_pad 32
and that was the case under discussion.
>This one was under FreeBSD, I got others under Linux with the same
>results.
XFree86 is the same on all platforms in this regard.
>I don't know much about XFree internals, maybe it might depend on
>differences between the S3 server and others?
The 3.3.1 S3 (non ViRGE) server doesn't yet support packed 24bpp
framebuffer operation. Also the S3 chips older than the [89]68 family
don't do packed 24bpp anyway.
>
>> Doing what the XFree86 servers currently do in this regard is quite
>> valid from an X11 point of view, but many clients cannot cope with it.
>
>I agree. Many clients were written when 8 bits or monochrome displays
>were the norm and were never tested on 16, 24 or 32 bits displays.
>The more general implementation of this stuff I have seen so far is
>the libxpm.
Yes. 16bpp still causes problems for some clients (anyone tried IDL on
a 16bpp display?) because it is relatively rare in the traditional Unix
workstation world. Pixmap bpp of 24 is even rarer.
David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971120115703.37544>