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 18: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: Xpert digest, Vol 1 #1944 - 1 msg (OUT OF THE OFFICE) (Jason Craddock)
--__--__--
Message: 1
Date: Sun, 23 Jun 2002 18:12:09 -0600
From: "Jason Craddock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [Xpert]Re: Xpert digest, Vol 1 #1944 - 1 msg (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 18: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 #1943 - 1 msg (OUT OF THE OFFICE) (Jason Craddock)
-- __--__--
Message: 1
Date: Sun, 23 Jun 2002 17:32:07 -0600
From: "Jason Craddock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [Xpert]Re: Xpert digest, Vol 1 #1943 - 1 msg (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 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
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
