On Sun, 23 Jun 2002, Jason Craddock wrote:

Can someone please unsubscribe Jason here, so we don't receive a 
vacation bounce every time someone posts a message?  It would be 
much appreciated.  I've got 12 or so vacation messages in my 
xpert folder currently in 2-3 days.

TTYL

>Date: Sun, 23 Jun 2002 17:32:07 -0600
>From: Jason Craddock <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=ISO-8859-1
>List-Id: General X Discussion <xpert.XFree86.Org>
>Subject: Re: Xpert digest, Vol 1 #1943 - 1 msg (OUT OF THE OFFICE)
>
>This message has been automatically generated.  
>
>Jason will be out of the office from June 24th through July 1st.
>If you need immediate assistance please contact Alisa Ott at 
>[EMAIL PROTECTED] or by calling 801-225-6080.
>
>Thank you,
>Jason Craddock
>
>>>> "[EMAIL PROTECTED]" 06/23/02 17:25 >>>
>
>Send Xpert mailing list submissions to
>       [EMAIL PROTECTED]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       http://XFree86.Org/mailman/listinfo/xpert
>or, via email, send a message with subject or body 'help' to
>       [EMAIL PROTECTED]
>
>You can reach the person managing the list at
>       [EMAIL PROTECTED]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Xpert digest..."
>
>
>Today's Topics:
>
>   1. Re: Xpert digest, Vol 1 #1942 - 3 msgs (OUT OF THE OFFICE) (Jason Craddock)
>
>--__--__--
>
>Message: 1
>Date: Sun, 23 Jun 2002 16:51:45 -0600
>From: "Jason Craddock" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: [Xpert]Re: Xpert digest, Vol 1 #1942 - 3 msgs (OUT OF THE OFFICE)
>Reply-To: [EMAIL PROTECTED]
>
>This message has been automatically generated.  
>
>Jason will be out of the office from June 24th through July 1st.
>If you need immediate assistance please contact Alisa Ott at 
>[EMAIL PROTECTED] or by calling 801-225-6080.
>
>Thank you,
>Jason Craddock
>
>>>> "[EMAIL PROTECTED]" 06/23/02 16:45 >>>
>
>Send Xpert mailing list submissions to
>       [EMAIL PROTECTED]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       http://XFree86.Org/mailman/listinfo/xpert
>or, via email, send a message with subject or body 'help' to
>       [EMAIL PROTECTED]
>
>You can reach the person managing the list at
>       [EMAIL PROTECTED]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Xpert digest..."
>
>
>Today's Topics:
>
>   1. Re: RE VGA-Out (Michel =?ISO-8859-1?Q?D=E4nzer?=)
>   2. Re: Trident bug (Egbert Eich)
>   3. Re: Xpert digest, Vol 1 #1941 - 6 msgs (OUT OF THE OFFICE) (Jason Craddock)
>
>-- __--__-- 
>
>Message: 1
>Subject: Re: [Xpert]RE VGA-Out
>From: Michel =?ISO-8859-1?Q?D=E4nzer?= <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Date: 23 Jun 2002 23:59:34 +0200
>Reply-To: [EMAIL PROTECTED]
>
>On Fri, 2002-06-21 at 20:59, Zhicong Liang wrote:
>> Thanks it works, but one more question. Where can I get the document for 
>> these "Option" setting for XConfigure??
>
>They should be documented in the driver manpage, unfortunately the
>radeon driver doesn't have one yet. (Help would be appreciated there,
>hint, hint)
>
>The config file generated by XFree86 -configure (usually
>/root/XF86Config.new) should also contain a list of all driver supported
>options, but the ati driver used to always put the options for the
>atimisc driver there, don't know if this has been fixed in the meantime.
>
>
>-- 
>Earthling Michel D*nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
>XFree86 and DRI project member   /  CS student, Free Software enthusiast
>
>-- __--__-- 
>
>Message: 2
>Date: Sun, 23 Jun 2002 11:08:37 +0200
>From: Egbert Eich <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [Xpert]Trident bug
>Reply-To: [EMAIL PROTECTED]
>
>Alan Hourihane writes:
> > 
> > Just checked, and it's still the same for the XP series.
> > 
>
>Well, then I'm out of ideas. I'd need a box with a 1400 wide display
>for testing.
>
>Egbert.
>
>-- __--__-- 
>
>Message: 3
>Date: Sun, 23 Jun 2002 16:11:41 -0600
>From: "Jason Craddock" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: [Xpert]Re: Xpert digest, Vol 1 #1941 - 6 msgs (OUT OF THE OFFICE)
>Reply-To: [EMAIL PROTECTED]
>
>This message has been automatically generated.  
>
>Jason will be out of the office from June 24th through July 1st.
>If you need immediate assistance please contact Alisa Ott at 
>[EMAIL PROTECTED] or by calling 801-225-6080.
>
>Thank you,
>Jason Craddock
>
>>>> "[EMAIL PROTECTED]" 06/23/02 16:05 >>>
>
>Send Xpert mailing list submissions to
>       [EMAIL PROTECTED]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       http://XFree86.Org/mailman/listinfo/xpert
>or, via email, send a message with subject or body 'help' to
>       [EMAIL PROTECTED]
>
>You can reach the person managing the list at
>       [EMAIL PROTECTED]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Xpert digest..."
>
>
>Today's Topics:
>
>   1. Re: Xpert digest, Vol 1 #1940 - 8 msgs (OUT OF THE OFFICE) (Jason Craddock)
>   2. Compaq Presario 2800 (info @ saudiabm)
>   3. Re: Re: 10-bits per colour (Detlef Grittner)
>   4. Re: Re: 10-bits per colour ([EMAIL PROTECTED])
>   5. Re: Re: 10-bits per colour ([EMAIL PROTECTED])
>   6. Re: Help about woking of X-server (Michel =?ISO-8859-1?Q?D=E4nzer?=)
>
>--  __--__--  
>
>Message: 1
>Date: Sun, 23 Jun 2002 12:51:48 -0600
>From: "Jason Craddock" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: [Xpert]Re: Xpert digest, Vol 1 #1940 - 8 msgs (OUT OF THE OFFICE)
>Reply-To: [EMAIL PROTECTED]
>
>This message has been automatically generated.  
>
>Jason will be out of the office from June 24th through July 1st.
>If you need immediate assistance please contact Alisa Ott at 
>[EMAIL PROTECTED] or by calling 801-225-6080.
>
>Thank you,
>Jason Craddock
>
>>>> "[EMAIL PROTECTED]" 06/23/02 13:00 >>>
>
>Send Xpert mailing list submissions to
>       [EMAIL PROTECTED]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       http://XFree86.Org/mailman/listinfo/xpert
>or, via email, send a message with subject or body 'help' to
>       [EMAIL PROTECTED]
>
>You can reach the person managing the list at
>       [EMAIL PROTECTED]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Xpert digest..."
>
>
>Today's Topics:
>
>   1. Radeon 7500 TV out works partially... (Nils Philippsen)
>   2. Re: Trident bug (Egbert Eich)
>   3. Re: is ATI Radeon 7000 Video w/ 64MB  supported with xfree86 for
>       redhat Linux 7.1 (Mike A. Harris)
>   4. Re: Trident 9660 Xv bug? (Alan Hourihane)
>   5. Re: Radeon 7500 QW and sgi 1600sw with MLA (Michel =?ISO-8859-1?Q?D=E4nzer?=)
>   6. Re: Trident bug (kiss the sun and walk on air)
>   7. Re: Re: 10-bits per colour ([EMAIL PROTECTED])
>
>--   __--__--   
>
>Message: 1
>From: Nils Philippsen <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Date: 23 Jun 2002 09:42:38 +0200
>Subject: [Xpert]Radeon 7500 TV out works partially...
>Reply-To: [EMAIL PROTECTED]
>
>
>--=-oXlCRW3t8eTIaatvCxrl
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>... well, for the 80x25 text console anyway when enabling TV out with
>atitvout.
>
>I have spent the better part of yesterday afternoon to come up with a
>modeline that would display my screen to the TV and got as far as having
>a screen with proper vsync, i.e. the lines didn't run through, stayed at
>the places they were. AFAICS the hsync isn't working, because the
>individual lines are "too short" and each one is offset in relation to
>the preceding line.
>
>I got these best results with NTSC modes even though my TV is really a
>PAL one (that only happens to display NTSC as well if I guess
>correctly). This seems consistent with the text console showing properly
>as it's got 60Hz vsync also.
>
>Now my maybe uninformed idea is, should I get hold of a modeline with
>the same parameters as the 80x25@60Hz text console, I should get a valid
>picture on the TV. I tried to get the necessary information to do this
>yesterday but to no avail, so: Does anyone know a modeline that
>resembles the text console? Or pursuing another direction: I know that
>there's some Windows tool which tells you the modeline for the currently
>set graphics mode (I don't know its URL at the moment, does anyone
>else?), can anyone with Windows run it when the TV out is working?
>
>Ah yes, other details: Red Hat Linux 7.3, packaged XFree86-4.2.0-8,
>atitvout-0.2b
>
>TIA,
>Nils
>--=20
> Nils Philippsen / Berliner Stra=DFe 39 / D-71229 Leonberg //
>+49.7152.209647
>[EMAIL PROTECTED] / [EMAIL PROTECTED] /
>[EMAIL PROTECTED]
>        Ever noticed that common sense isn't really all that common?
>
>--=-oXlCRW3t8eTIaatvCxrl
>Content-Type: application/pgp-signature; name=signature.asc
>Content-Description: This is a digitally signed message part
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.6 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQA9FXvuR9ibZWlRMBERAsKfAJ9dEpqQsJZc01kfNgtbz53nWplCZQCgkbdI
>b+AoNSBCWD/nD6kPx99Zjeo=
>=DGw6
>-----END PGP SIGNATURE-----
>
>--=-oXlCRW3t8eTIaatvCxrl--
>
>
>--   __--__--   
>
>Message: 2
>Date: Sun, 23 Jun 2002 10:19:47 +0200
>From: Egbert Eich <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [Xpert]Trident bug
>Reply-To: [EMAIL PROTECTED]
>
>kiss the sun and walk on air writes:
> > 
> > Agreed. A positive value exacerbates the the problem. The ability to
> > go farther in the negative direction is needed to find the best value.
> > 
>
>OK. Well like I've said already. I added this using some older manuals
>taking some educated guesses.
>
>Egbert.
>
>--   __--__--   
>
>Message: 3
>Date: Sun, 23 Jun 2002 06:12:20 -0400 (EDT)
>From: "Mike A. Harris" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Organization: Red Hat Inc.
>Subject: [Xpert]Re: is ATI Radeon 7000 Video w/ 64MB  supported with xfree86 for
> redhat Linux 7.1
>Reply-To: [EMAIL PROTECTED]
>
>On Sun, 23 Jun 2002, Walter Logeman wrote:
>
>>Date: Sun, 23 Jun 2002 15:35:19 +1200
>>From: Walter Logeman <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>Content-Type: text/plain; charset=us-ascii
>>List-Id: General X Discussion <xpert.XFree86.Org>
>>Subject: Re: is ATI Radeon 7000 Video w/ 64MB  supported with xfree86 for
>>    redhat Linux 7.1
>>
>>
>>Dr Andrew C Aitchison,
>>
>>
>>> IIRC xf86config is obsolete in 4.2, and should have been removed.
>>> 
>>> Try configuring with either
>>>     X -configure
>>> or
>>>     xf86cfg
>>> instead.
>>
>>
>>Really?  I have been trying to get Mandrake 8.2 running on my
>>Dell i8100 trying all sorts of configuration of
>>/etc/X11/XF86config-4
>>
>>They make a difference (eg without an Option "noaccel" the whole
>>thing crashes the screen.)  But i cant get it to use my ATI
>>Radeon card well at all.  Am i configuring the wrong file?
>
>Red Hat Linux 7.1 comes with XFree86 4.0.3 which doesn't support 
>this card.  The latest update for 7.1 is XFree86 4.1.0 which does 
>support the Radeon VE which allegedly the Radeon 7000 is.
>
>However I am unaware of what specific differences if any that the 
>Radeon 7000 may have from the VE.  Since the Radeon 7000 came out 
>after 4.1.0 came out, it isn't "officially" supported but IMHO it 
>should work just fine.  I've not received any bug reports from 
>Radeon 7000 users yet.
>
>I do have a Radeon VE, and it works perfectly however.
>
>Hope this helps.
>
>
>-- 
>Mike A. Harris                  Shipping/mailing address:
>OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
>XFree86 maintainer              Ontario, Canada, P6C 5B3
>Red Hat Inc.
>http://www.redhat.com           ftp://people.redhat.com/mharris
>
>
>--   __--__--   
>
>Message: 4
>Date: Sun, 23 Jun 2002 09:06:31 +0100
>From: Alan Hourihane <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [Xpert]Trident 9660 Xv bug?
>Reply-To: [EMAIL PROTECTED]
>
>Get the later driver from http://www.xfree86.org/~alanh
>
>It fixes this problem.
>
>Alan.
>
>On Sat, Jun 22, 2002 at 11:15:15 -0500, David D. Hagood wrote:
>> I believe there may be a bug in the XFree86 4.2 Xv drivers for Trident 
>> 9660 chips. I have a laptop with a Trident 9660 graphics controller, and 
>> when I try to run Xine using Xv, this is what I get:
>> 
>> xine menace_480.mov
>> This is xine (X11 gui) - a free video player v0.9.11
>> (c) 2000-2002 by G. Bartsch and the xine project team.
>> Built with xine library 0.9.11 [Sat 22 Jun 2002 20:14:54]-[gcc version 
>> 2.96 20000731 (Red Hat Linux 7.1 2.96-98)]-[Linux 2.4.18-xfs i586].
>> Found xine library version: 0.9.11 (0.9.11cvs).
>> XServer Vendor: The XFree86 Project, Inc. Release: 40200000,
>>         Protocol Version: 11, Revision: 0,
>>         Available Screen(s): 1, using 0
>>         Depth: 16.
>> tvmode: cannot connect to nvtvd - no TV mode switching available
>> Display is not using Xinerama.
>> tvmode: not connected to nvtvd for switching
>> video_out_xv: using Xv port 55 from adaptor Trident Backend Scaler for 
>> hardware colorspace conversion and scaling.
>> video_out_xv: port attribute XV_COLORKEY value is 0
>> X Error of failed request:  BadMatch (invalid parameter attributes)
>>   Major opcode of failed request:  141 (XVideo)
>>   Minor opcode of failed request:  14 ()
>>   Serial number of failed request:  1110
>>   Current serial number in output stream:  1110
>> 
>> I beleive the bug to be in X, rather than xine, because after I've done 
>> this, any attempt to access the Xv system gives an error:
>> 
>> 
>> [wowbaggr@wanderer animations.2]$ xvinfo
>> X-Video Extension version 2.2
>> screen #0
>>   Adaptor #0: "Trident Backend Scaler"
>>     number of ports: 1
>>     port base: 55
>>     operations supported: PutImage
>>     supported visuals:
>>       depth 16, visualID 0x23
>>       depth 16, visualID 0x24
>>     number of attributes: 6
>>       "XV_COLORKEY" (range 0 to 16777215)
>>               client settable attribute
>>               client gettable attribute (current value is 0)
>>       "XV_SATURATION" (range 0 to 187)
>>               client settable attribute
>> X Error of failed request:  BadMatch (invalid parameter attributes)
>>   Major opcode of failed request:  141 (XVideo)
>>   Minor opcode of failed request:  14 ()
>>   Serial number of failed request:  14
>>   Current serial number in output stream:  14
>>               client gettable attribute[wowbaggr@wanderer animations.2]$
>> [wowbaggr@wanderer animations.2]$
>> 
>> For reference, here's what's on the bus:
>> 
>> 
>>  lspci
>> 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 85C501/2
>> 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 01)
>> 00:01.1 IDE interface: Silicon Integrated Systems [SiS] 85C601 (rev 01)
>> 00:06.0 VGA compatible controller: Trident Microsystems TGUI 
>> 9660/968x/968x (rev d3)
>> 00:0d.0 PCMCIA bridge: Omega Micro Inc. 82C092G (rev 02)
>> 00:0e.0 PCMCIA bridge: Omega Micro Inc. 82C092G (rev 02)
>> 
>> 
>> This is with the binaries available from XFree86.org - not a CVS pull.
>> 
>> Has anybody else seen this? Is there any other info I can provide?
>> 
>> _______________________________________________
>> Xpert mailing list
>> [EMAIL PROTECTED]
>> http://XFree86.Org/mailman/listinfo/xpert
>
>--   __--__--   
>
>Message: 5
>Subject: Re: [Xpert]Radeon 7500 QW and sgi 1600sw with MLA
>From: Michel =?ISO-8859-1?Q?D=E4nzer?= <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Date: 23 Jun 2002 15:38:36 +0200
>Reply-To: [EMAIL PROTECTED]
>
>On Thu, 2002-06-20 at 21:25, Nate Pearlstein wrote: 
>> Hi,
>> 
>> Well, I've recently upgrade to RH7.3 + xfs1.1, xfree86 4.2, and also 
>> upgraded to a Radeon 7500 QW AGP from a Radeon VE QYAGP.
>> 
>> I've noticed that the performance is much better and that it also 
>> claims, in the xfree86 log that dpms is on as opposed to rh7.1; xfree86 
>> 4.1which complained.  I use xinerama and so now at least my 21" crt does 
>> actually go into powersave mode and xfree86 does suspend processing of 
>> the screensaver.  However, the 1600sw in digital mode doesn't go into 
>> power saving; it goes dark but the backlight is still on.  I believe the 
>>  radeon driver classifies the 1600sw as a DFP, Primary Display == Type 
>> 3, as opposed to CRT or LCD.  Does Radeon 7500 xf 4.2 actually do dpms 
>> for DFP?
>
>I don't think so, current CVS should though.
>
>
>-- 
>Earthling Michel D*nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
>XFree86 and DRI project member   /  CS student, Free Software enthusiast
>
>--   __--__--   
>
>Message: 6
>Date: Sun, 23 Jun 2002 09:46:46 -0400
>From: kiss the sun and walk on air <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [Xpert]Trident bug
>Reply-To: [EMAIL PROTECTED]
>
>
>--ReaqsoxgOBHFXBhH
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Sun, Jun 23, 2002 at 10:19:47AM +0200, Egbert Eich wrote:
>> kiss the sun and walk on air writes:
>>  >=20
>>  > Agreed. A positive value exacerbates the the problem. The ability to
>>  > go farther in the negative direction is needed to find the best value.
>>=20
>> OK. Well like I've said already. I added this using some older manuals
>> taking some educated guesses.
>
>Thanks for trying :) Perhaps we can try pushing the value beyond the
>spec? Or is there possibly something in the modeline that could be
>tweaked?
>
>I'm just trying to help brainstorm. Before I installed linux on this
>machine windows 2000 had a perfect 1400x1050 display, so its possible,
>somehow.
>
>Thanks for all your effort.
>-peter
>
>--=20
>(peter.royal|osi)@pobox.com - http://fotap.org/~osi
>jabber/ [EMAIL PROTECTED] - icq/ 153025 - aim/ osifx - yahoo/ osi_fx
>your brain on life - http://fotap.org - incubating
>
>--ReaqsoxgOBHFXBhH
>Content-Type: application/pgp-signature
>Content-Disposition: inline
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (GNU/Linux)
>
>iD8DBQE9FdFGhxNyr2g6PGURAtsLAJ9lPjjwHdJyoEiKgJ8GwV9xhYpJjwCeIlE2
>i4ejhjiCVaTXX4gI27bkUjM=
>=oH9s
>-----END PGP SIGNATURE-----
>
>--ReaqsoxgOBHFXBhH--
>
>--   __--__--   
>
>Message: 7
>Date: Sun, 23 Jun 2002 13:09:15 -0400 (EDT)
>From: [EMAIL PROTECTED]
>Subject: Re: [Xpert]Re: 10-bits per colour
>To: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>
>On 21 Jun, Dr Andrew C Aitchison wrote:
>> On Thu, 20 Jun 2002, Christoph Koulen wrote:
>>> The delimiting factor, I agree, would be the human eye! I wonder, if it
>>> is capable of distinguishing between 1024 shades of a primary color?
>
>Yes it is.  There is scientific work on the eye-brain vision system and
>one of the results is a clear answer yes.  At this level of detail you
>must also be precise about the meaning of the word "distinguish".  I've
>experienced several definitions of it:
>
> 1) Able to differentiate two halves of a split circle contrast target
>  on a neutral background.
> 2) Able to correctly identify the polarity of a 3x3 checkboard target.  I.e., 
> correctly identify the center square as darker or lighter.
> 3) Able to correctly locate a contour line at a "flat spot" in an image.
>
>The tests I worked with were done in grey and blue (because those are
>what radiology works in).  When alert and wearing glasses my vision
>quits somewhere around 1500-2000 levels.  In the semi-random sample of
>several thousand field service engineers we found none that were below
>300 levels.  Most were 500 or better in the mid-greys.
>
>> 
>> Probably not, especially since there are colours too bright and too dim
>> for a monitor to show. However with only 256 shades the steps between 
>> adjacent colors are not always even (gamma mapping can reduce this problem)
>> and it isn't difficult to find single steps which are very obvious,
>> especially on a gray ramp. 1024 shades makes it easer to make the steps
>> even, and maybe allow all of them to be invisible.
>> 
>
>The luminance (the kind in cd/m^2) of image and environment are key
>parameters in defining the number of visible levels.  The key parameters
>when the display covers the full field of view are the brightness of
>"black" (which includes reflection of ambient lighting) and the
>brightness of "white".  Typically lit ordinary CRT monitors are often in
>a range where the eye is limited to under 256 levels.  As you mentioned,
>constraining these 256 levels to be points of equal voltage to a monitor
>further eliminates levels because these levels are not placed uniformly
>in perceptual space.  
>
>The natural CRT gamma curve is a fair approximation to the eye's
>response, which is why CRTs have been successful.  It is not perfect.
>Increasing the DAC resolution to 10-bits voltage puts sufficient
>adjustment into the exact positioning of luminance levels so that all of
>the roughly 256 visible levels can be displayed.  This is one of the
>major reasons for the need for 10-bit video output resolution.  Note
>that a 10-bit DAC is enough.  8-bit RGB pixel storage remains sufficient
>because the purpose of the 10-bit DAC is presentation using the eye's
>response curve rather than the CRT's gamma curve.
>
>For specific examples of how this can be used, see  
>http://medical.nema.org/dicom/2001.html/01_14PU.PDF  or Barten's book
>Contrast Sensitivity of the Human Eye and Its Effects on Image Quality
>
>Then follow the references to track down other major researchers on this
>topic.
>
>R Horn
>
>
>
>--   __--__--   
>
>_______________________________________________
>Xpert mailing list
>[EMAIL PROTECTED]
>http://XFree86.Org/mailman/listinfo/xpert
>
>
>End of Xpert Digest
>
>
>--  __--__--  
>
>Message: 2
>From: "info @ saudiabm" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
>   <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
>   <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
>   <[EMAIL PROTECTED]>
>Date: Wed, 2 Jan 2002 23:03:39 +0300
>Subject: [Xpert]Compaq Presario 2800
>Reply-To: [EMAIL PROTECTED]
>
>
>Hi all,
>
>I have tried to install Redhat Linux 7.2 and  7.3 w/ XFree86 4.2 onto my
>Compaq Presario 2800 laptop. During the installation, I got no problem
>with the screen, but after the installation, from the graphical login
>screen and onwards, the screen got screwed up. There are vertical bars
>cutting up the icons, fronts, and dialog boxes. My Presario 2800 uses
>ATI Radeon M7 card.
>
>I have browse thru several newsgroup, but of no help. Can anyone please
>help?
>
>Thanks,
>
>
>By the way , someone tell me this solution but I don't think this is the
>really solution :
>
>
>I have an ASUS laptop with a different video card, However, I have 
>faced a similar problem. What happens is that, probably, anaconda (RH 
>installer) uses a generic SVGA server during installation.
>
>I have solved it by using this generic SVGA server from Xfree 3.3.6 
>instead of the XFree86 4.2 driver. Sometimes (in my case, e.g.) the 
>driver that comes with version 4.2 is worst than the generic SVGA 
>driver. I use RH 7.3 as well.
>
>My video is silicon motion and there is a driver, named 
>*siliconmotion*, that comes with XFree86 4.2. However, it doesn't work. 
>What I do is to use the generic SVGA driver that is also included in v. 
>4.2 through a driver of v. 3.3.6. This may be a suggestion for you.
>
>You may have to change the driver. I have sent the steps I used (and 
>explained them in case you're new to Linux). Use them at your own risk.
>
>1. Check to where link /etc/X11/X points. If it is:
>
>    X -> ../../usr/X11R6/bin/XFree86
>
>    than you're really using the v.4.2. Probably that's you're case. 
>Than:
>
>2. Check if you have packages:
>
>    XFree86-SVGA3.3.6-44
>    XFree86-compat-modules3.3.6-44
>
>    in User Interface/X Hardware Support. If not, install them. This 
>will install the old generic SVGA driver. I have checked in XFree86 
>site (http://www.xfree86.org/4.2.0/Status6.html#6) that it works with 
>your card.
>
>3. Check if you have:
>
>    /etc/X11/XF86Config
>    /etc/X11/XF86Config-4
>
>4. The first file relates to the use of the SVGA server. This was most 
>probably generated by anaconda (type: head /etc/X11/XF86Config). Edit 
>this file now (vi, kedit etc). In the section *screen* you need to have 
>this driver:
>
>Section "Screen"
>     Driver      "svga"    <= ************
>     Device      "Silicon Motion Lynx (generic)"
>     Monitor     "Generic Laptop Display Panel 1024x768"
>     DefaultColorDepth 16
>     Subsection "Display"
>         Depth       16
>         Modes       "1024x768"
>         ViewPort    0 0
>     EndSubsection
>EndSection
>
>*Verify other aspects as keyboard, mouse and monitor configuration. 
>Compare with what is set in the XF86Config-4 file (this is the file 
>used by v. 4.2). Probably, you'll find that XF86Config file has the 
>configurations you have given at installation time.
>
>5. As root:
>
>    $ cd /etc/X11
>    $ mv X X~
>    $ ln -s /usr/X11R6/bin/XF86_SVGA X
>    $ cd /usr/X11R6/bin
>    $ mv X X~
>    $ ln -s XF86_SVGA X
>
>6. That should do. In your desktop press Ctrl + Alt + BackSpace to 
>restart X server. If everything went fine, you're now using the SVGA 
>server.
>   _______________________
>http://www.SaudiABM.com
> _______________________
>About Islam :
>http://home2.swipnet.se/~w-20479/Audio.htm
>http://sultan.org
>  _______________________
>
>
>--  __--__--  
>
>Message: 3
>Date: Sun, 23 Jun 2002 22:01:43 +0200
>From: [EMAIL PROTECTED] (Detlef Grittner)
>To: xpert <[EMAIL PROTECTED]>
>Subject: Re: [Xpert]Re: 10-bits per colour
>Reply-To: [EMAIL PROTECTED]
>
>>For specific examples of how this can be used, see  
>>http://medical.nema.org/dicom/2001.html/01_14PU.PDF  or Barten's book
>>Contrast Sensitivity of the Human Eye and Its Effects on Image Quality
>>
>>Then follow the references to track down other major researchers on this
>>topic.
>>
>>R Horn
>
>I found the correct link at http://medical.nema.org/dicom/2001/01_14PU.PDF 
>
>Thank you for the information. As I'm working on medical viewers people often ask me 
>how many gray scales are needed.
>Some people even doubt that more than 8 Bit (256) gray scales are necessary.
>But typical radiological images often come with 10 Bit (1024) gray scales.
>If you have a display and a video card that can display distinguishable 1024 grays 
>that would be invaluable.
>
>BTW I have read that Matrox's Parhelia supports "Gigacolor" with 10 bit per color 
>channel. And Martox claims that you can view over 1 billion colors (it was "*ber eine 
>Milliarde" in German, that's one billion in American English, isn't it?).
>
>And Sun's XVR 1000 has a 30 bit color deep frame buffer, but that's for Sparcs only.
>
>My investigations in OpenGL have revealed that there is a graphics format that 
>supports 10 bit per color channel and 2 bit for the alpha channel, that is 32 bit 
>altogether. So I don't know whether that can be used for the framebuffer and how 
>drivers could support that.
>
>Detlef
>
>
>
>
>
>
>
>--  __--__--  
>
>Message: 4
>Date: Sun, 23 Jun 2002 17:23:16 -0400 (EDT)
>From: [EMAIL PROTECTED]
>Subject: Re: [Xpert]Re: 10-bits per colour
>To: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>
>On 23 Jun, Detlef Grittner wrote:
>>>For specific examples of how this can be used, see  
>>>http://medical.nema.org/dicom/2001.html/01_14PU.PDF  or Barten's book
>>>Contrast Sensitivity of the Human Eye and Its Effects on Image Quality
>>>
>>>Then follow the references to track down other major researchers on this
>>>topic.
>>>
>>>R Horn
>> 
>> I found the correct link at http://medical.nema.org/dicom/2001/01_14PU.PDF 
>> 
>> Thank you for the information. As I'm working on medical viewers people often ask 
>me how many gray scales are needed.
>> Some people even doubt that more than 8 Bit (256) gray scales are necessary.
>> But typical radiological images often come with 10 Bit (1024) gray scales.
>> If you have a display and a video card that can display distinguishable 1024 grays 
>that would be invaluable.
>
>Sorry about the typo.  If you are working in medical you must also take
>a look at  http://www.rsna.org/IHE/tf/ihe_tf_index.shtml
>
>In particular, it is becoming a market necessary to comply with the
>Consistent Presentation of Images (CPI) profile.  At present it only
>applies to greyscale images.  Calibrating color monitor presentation to
>comply with the greyscale standard makes a significant improvement to
>the quality of a color presentation.  The further work on color space
>calibration remains in committee.  This came up very briefly at last
>weeks DICOM WG-6 meeting, mostly as a question regarding when was the
>color standard going to be ready, with a response of "Don't know".  One
>of the issues is the weakness of the scientific literature regarding the
>diagnostic requirement for color consistency.  
>
>The minimum realistic requirement for medical work is a high quality
>monitor and a 10-bit DAC.  This lets you adjust the output LUT so that
>you can comply with the display standard while using 8-bit data.
>Assuming that there is compliance with the CPI profile, you can degrade
>10-bit to 8-bit image data with a minimum loss of utility.
>
>There are a number of vendors for medical quality displays.  These are
>all quite expensive because they provide both 10-bit input and 12+bit
>DAC controls so that they can both calibrate the system to comply with
>the display standard and convey 10-bit image data.  They also
>incorporate the very high luminance required to achieve 10-bit
>viewability.  Unfortunately from an XFree perspective, most of the
>medical vendors will not disclose the programming information for the
>display controllers.
>
>The actual requirement for resolution depends on the imaging modality
>and the purpose of viewing.  For many purposes, an 8-bit display that
>meets the display standard will be sufficient.  For other purposes it
>will not.  I would never consider doing general radiographic diagnosis
>of a chest with anything under 10-bit.  I would never consider doing it
>in without controlled ambient lighting and the very high brightness of a
>radiology oriented monitor.  These are the norm in any reading room. But
>for ultrasound an 8-bit display with calibration and proper lighting
>should suffice.  
>
>There is also a big difference between diagnosis and other uses.
>
>Further, just a warning about safety regulations.  The FDA regulates
>medical devices under the Safe Medical Device Act.  You might be an
>unwitting manufacturer. The definitions of device and manufacturer are
>very broad. So check whether these safety laws apply to you. It is a
>very serious crime to ship a medical device without a serious effort to
>comply with the laws. It is a far less serious crime to make mistakes in
>compliance. The website at http://www.fda.gov/cdrh/overview.html is a
>good starting point.  FDA regulations include efficacy rules, and
>questions about necessary display quality might be an efficacy question.
>
>R Horn 
>
>
>--  __--__--  
>
>Message: 5
>Date: Sun, 23 Jun 2002 22:50:25 +0100
>From: [EMAIL PROTECTED]
>Organization: L.S.Caine Electronic Services
>To: [EMAIL PROTECTED]
>Subject: Re: [Xpert]Re: 10-bits per colour
>Reply-To: [EMAIL PROTECTED]
>
>> The minimum realistic requirement for medical work is a high quality
>> monitor and a 10-bit DAC.  This lets you adjust the output LUT so that
>> you can comply with the display standard while using 8-bit data.
>> Assuming that there is compliance with the CPI profile, you can degrade
>> 10-bit to 8-bit image data with a minimum loss of utility.
>
>The digital imaging systems that I have been linking to
>provide raw 12 and 14 bit grey scale, this is then processed
>to provide contrast enhancement so that medical inserts can
>easily be seen even with low dosage X-ray monitoring. The
>advantage is that only one ADC/DAC pair is required. Colour
>is added to the processed image, when a drop to 8 bit can be
>accepted. 
>
>The x-ray systems had to be very high resolution 12 bit
>before acceptable as a replacement to film in a number of
>situations. 
>
>-- 
>Lester Caine
>-----------------------------
>L.S.Caine Electronic Services
>
>--  __--__--  
>
>Message: 6
>Subject: Re: [Xpert]Help about woking of X-server
>From: Michel =?ISO-8859-1?Q?D=E4nzer?= <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Date: 23 Jun 2002 23:51:55 +0200
>Reply-To: [EMAIL PROTECTED]
>
>On Wed, 2002-06-12 at 06:21, Anticipating Reply wrote: 
>> 
>>      I have been stuck up with a problem of
>> Xfbdev regarding the improper display of
>> colors in the pictures , and have not
>> got any suggestions which could resolve
>> my problem form this 'Xpert' mailing list .
>
>I must have missed the earlier posts. Can you summarize the problem again?
>
>>     Now I have no option but to sit and
>> understand the complete working of X-windows
>> to try and figure out my probelm & find a
>> solution .
>
>Well, the first suspect would be the framebuffer device (depending on
>the problem, of course).
>
>
>-- 
>Earthling Michel D*nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
>XFree86 and DRI project member   /  CS student, Free Software enthusiast
>
>
>--  __--__--  
>
>_______________________________________________
>Xpert mailing list
>[EMAIL PROTECTED]
>http://XFree86.Org/mailman/listinfo/xpert
>
>
>End of Xpert Digest
>
>
>
>-- __--__-- 
>
>_______________________________________________
>Xpert mailing list
>[EMAIL PROTECTED]
>http://XFree86.Org/mailman/listinfo/xpert
>
>
>End of Xpert Digest
>
>
>
>--__--__--
>
>_______________________________________________
>Xpert mailing list
>[EMAIL PROTECTED]
>http://XFree86.Org/mailman/listinfo/xpert
>
>
>End of Xpert Digest
>
>_______________________________________________
>Xpert mailing list
>[EMAIL PROTECTED]
>http://XFree86.Org/mailman/listinfo/xpert
>



-- 
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer              Ontario, Canada, P6C 5B3
Red Hat Inc.
http://www.redhat.com           ftp://people.redhat.com/mharris

_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to