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&Sgr;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
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
