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/22/02 07: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 VGA-Out (Zhicong Liang)
2. Re: Re: 10-bits per colour (Ross Vandegrift)
3. Re: Xpert digest, Vol 1 #1928 - 5 msgs (Dean S. Messing)
4. Re: Xpert digest, Vol 1 #1930 - 2 msgs (Olivier Fourdan)
5. Re: startx works, but xdm fails (Matthieu Herrb)
6. Static Color setting (=?iso-8859-1?q?sanal=20kumar?=)
7. Re: Trident bug (Egbert Eich)
8. Re: Re: Xpert digest, Vol 1 #1930 - 2 msgs (Egbert Eich)
9. Re: Trident bug (Norman Walsh)
10. Slow opaque window resizing (Lukas Molzberger)
11. Re: AW: Re: again firegl8700 (Mike A. Harris)
12. Re: Re: again firegl8700 (Mike A. Harris)
13. keyboard on IBook (Christian Berger)
14. dual head on a Radeon VE (Geoffrey)
--__--__--
Message: 1
From: "Zhicong Liang" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Fri, 21 Jun 2002 18:59:46 +0000
Subject: [Xpert]RE VGA-Out
Reply-To: [EMAIL PROTECTED]
Thanks it works, but one more question. Where can I get the document for
these "Option" setting for XConfigure??
Thanks again!
>I guess the problem with it is, the radeon chip always think the monitor
>attach to it is a LCD, hence it refuses to work in higher frequency.... any
>ideas??
>>Try Option "CRTScreen"
_________________________________________________________________
Join the worldÆs largest e-mail service with MSN Hotmail.
http://www.hotmail.com
--__--__--
Message: 2
From: Ross Vandegrift <[EMAIL PROTECTED]>
Date: Fri, 21 Jun 2002 16:20:24 -0400
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Re: 10-bits per colour
Reply-To: [EMAIL PROTECTED]
> > 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?
>
> 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.
Also, I've heard that the eyes different responsiveness to various parts
of the light spectrum can affect it. For example, two shades of blue in
8 bits that are one bit apart will be completely indistinguishable. But
some greens that are one bit apart are discernable. Phenomeneoa like
this make 10-bit color sound like a very cool idea to me.
Ross Vandegrift
[EMAIL PROTECTED]
--__--__--
Message: 3
From: "Dean S. Messing" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Fri, 21 Jun 2002 13:47:42 -0700 (PDT)
Subject: [Xpert]Re: Xpert digest, Vol 1 #1928 - 5 msgs
Reply-To: [EMAIL PROTECTED]
Christoph Koulen writes:
:: >
:: > You do realize that potentially no monitor, and certainly no LCD screen,
:: > can output this level of color, right? (Perhaps they dither it down?)
:: > 10 bits per channel is primarily useful for internal calculations, as
:: > far as I know.
:: >
:: > So you'd better start your investigation with: "can I even see 10 bits
:: > per channel?" rather than "how?".
:: >
:: > -ray skoog
:: >
::
:: To my knowledge, a monitor is an analogous device, that can potetially
:: display _any number_ of intermediate shades of each primary colour.
I take it you mean "analogue" when you write "analogous"?
If so, then you need to consider the existence of _digital_ flat panel (FP)
displays, most of which are, today, LCD devices of some sort.
Though one could argue that (ultimately) these, too, are analogue at bottom,
it is not usually useful to think in these terms unless you are a device
physicist or a LCD driver circuit designer.
:: Isn't the RAMDAC (Digital-Analog Converter) the chip, that converts a
:: digital value (i.e. a 10bit color value) into a voltage that ultimatly
:: drives the intensity of each of the monitor's color guns? I cannot see a
:: reason, why a color gun wouldn't respond to any intermediate voltage
:: level. If it weren't driven by a RAMDAC of inherently limited resolution
:: but a power supply capable of outputting a continuous voltage range...
If the FP is digital then you must send spatially discrete amplitude-quantised
signals to it (usually via a DVI-I or DVI-D interface) to drive the thing.
:: 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?
::
:: Christoph Koulen
The eye _can_ see the grey level transitions in a corrected (both
gamma and device S-curve) 8-bit grey ramp if (i) the display is wide
enough or (ii) you zoom in on a just a portion of the ramp. These do
disappear when you have "1024 shades of a primary colour". But I'm
talking LCD panel here.
On a CRT it's possible to see the transitions though it is much harder
and you need a high-end (== expensive) CRT.
The reasons are several. W/o getting into details, the beam spot tends to
smear the transition edges and the CRT is inherently spatially noisy.
With a digital LCD panel, there _is_ no "spot", and there is an _exact_
spatial correspondence between what is in the framebuffer and what is
on the monitor.
By the bye, the latter fact is also the reason why the "sub-triad
addressing" (a.k.a subpixel subsampling) used in M$ Cleartype doesn't
"work" on a CRT or an analogue LCD panel.
Dean S. Messing
Center for Displayed Appearance
Information Systems Technologies Laboratory
Sharp Laboratories of America
E-Mail: [EMAIL PROTECTED]
--__--__--
Message: 4
From: Olivier Fourdan <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: 21 Jun 2002 22:58:10 +0200
Subject: [Xpert]Re: Xpert digest, Vol 1 #1930 - 2 msgs
Reply-To: [EMAIL PROTECTED]
> > Sorry, but... Nope, it's worst.
>
> Is it purely Xvideo stuff that's broken now ?
Yes, the rest is fine as far as I can tell. I obviously cannot take a
snapshot of what I get (because all I get on the screenshot is the
chromakey). I may try taking a picture with my digital camera if you
want.
Cheers,
--
Olivier <[EMAIL PROTECTED]> http://www.xfce.org
-----------------------------------------------------------------------
XFce is a lightweight desktop environment for various *NIX systems.
Designed for productivity, it loads and executes applications fast,
while conserving system resources. XFce is all free software, released
under GNU General Public License. Available from http://www.xfce.org
--__--__--
Message: 5
From: Matthieu Herrb <[EMAIL PROTECTED]>
Date: Sat, 22 Jun 2002 01:08:35 +0200
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]startx works, but xdm fails
Reply-To: [EMAIL PROTECTED]
Zak Johnson wrote (in a message from Monday 17)
> [Please CC me on replies, as I am not subscribed to this list.]
>
> I just installed XFree86 4.2.0 while upgrading one of my workstations to
> FreeBSD 4.6. After fiddling with xf86cfg for a bit and getting a proper
> XF86Config file set up, startx worked like a champ. Unfortunately, xdm
> does not. I have searched the list archives and the web to no avail. I
> have attached my xdm-errors file; please let me know if I should supply
> more information.
You're probably running in 8 bits depth on your card. There's a small
problem with the Xrender extension at 8 bpp on XFree86 4.2.0 that
doesn't leave enough free color cells to display the XFree86 logo in
xdm. If your card has enough memory and bandwith to support 16 or 24
bpp, switch to that . (Add "DefaultDepth 16" or "DefaultDepth 24" to
the "Display" section of your rXF86Config file).
If you can't do that, use an icon with less colors in
/etc/X11/xdm/Xresource for the xlogin*logoFileName resource.
This problem is fixed in -current XFree86.
Matthieu
--__--__--
Message: 6
Date: Sat, 22 Jun 2002 04:56:07 +0100 (BST)
From: =?iso-8859-1?q?sanal=20kumar?= <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Xpert]Static Color setting
Reply-To: [EMAIL PROTECTED]
Hello,
I didn't get any reply from mailing list about my
previos mail, thats why i am resending this.Can
anybody help me on this
I am not at all using any config file for running the
Xfbdev .I have compiled it for iPaq . Does it really
requires any config file.
Will it be a reason why I am not getting a proper
color map in PseudoColor.Moreover I didn't find any
document stating that we have to use XF86config file
for TinyX for arm.It will be helpful if you can give
me a proper feedback regarding this issue
TIA
Best Regards
Sanal
Date: Wed, 19 Jun 2002 07:58:14 +0100 (BST)
From: Dr Andrew C Aitchison
Sanal Kumar <[EMAIL PROTECTED]> asked:
> How to change the default visual from PseudoColor to
> Static color in Xfbdev
What happens if you put the line
Visual "StaticColor"
into the "Device" Section of your config file ?
--
Dr. Andrew C. Aitchison Computer Officer,
DPMMS, Cambridge
[EMAIL PROTECTED]
http://www.dpmms.cam.ac.uk/~werdna
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--__--__--
Message: 7
Date: Sat, 22 Jun 2002 09:23:13 +0200
From: Egbert Eich <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Trident bug
Reply-To: [EMAIL PROTECTED]
Norman Walsh writes:
> / Alan Hourihane <[EMAIL PROTECTED]> was heard to say:
> | That driver is up now. Please test it.
>
> Might one gently inquire if this version supports the manual override for
> that pixel-shift bug?
>
It is not a bug. Or at least not in the driver. It is the BIOS that's
doing things wrong.
Yes, the option is in there, now.
It is called "FpDelay" and can have the range -2 to 5.
Please let us know which values work for you best.
Egbert.
--__--__--
Message: 8
Date: Sat, 22 Jun 2002 00:31:16 +0200
From: Egbert Eich <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Re: Xpert digest, Vol 1 #1930 - 2 msgs
Reply-To: [EMAIL PROTECTED]
Olivier Fourdan writes:
> > > Sorry, but... Nope, it's worst.
> >
> > Is it purely Xvideo stuff that's broken now ?
>
> Yes, the rest is fine as far as I can tell. I obviously cannot take a
> snapshot of what I get (because all I get on the screenshot is the
> chromakey). I may try taking a picture with my digital camera if you
> want.
>
I was hoping to fix your problem. Now it got worse. I don't see
anything in the changed code that would make it worse for you.
Could you please try if you get the same problem if you play a
video that is less than 384 pixels wide?
Unfortunately I introduced a bug there.
Egbert.
--__--__--
Message: 9
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Trident bug
From: Norman Walsh <[EMAIL PROTECTED]>
Date: Sat, 22 Jun 2002 10:22:13 +0000
Reply-To: [EMAIL PROTECTED]
/ Egbert Eich <[EMAIL PROTECTED]> was heard to say:
| It is not a bug. Or at least not in the driver. It is the BIOS that's
| doing things wrong.
I really appreciate your efforts to help work around the problem.
| Yes, the option is in there, now.
| It is called "FpDelay" and can have the range -2 to 5.
|
| Please let us know which values work for you best.
-2 works best, but it's not enough. If those are pixel values, I think
something like -12 would work better.
Be seeing you,
norm
--
Norman Walsh <[EMAIL PROTECTED]> | Is your cucumber bitter? Throw it away.
http://nwalsh.com/ | Are there briars in your path? Turn
| aside. That is enough. Do not go on to
| say, 'Why were things of this sort ever
| brought into the world?'--Marcus
| Aurelius
--__--__--
Message: 10
From: Lukas Molzberger <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Sat, 22 Jun 2002 11:34:34 +0200
Subject: [Xpert]Slow opaque window resizing
Reply-To: [EMAIL PROTECTED]
Hello,
I'm using Linux and XFree for quite some time now and I'm a big fan of it.
However, there is one bug that has always annoyed me. When I resize a window
under XFree then it can take a long time until the content of this window is
redrawn.
I've also looked into the Mailing List archieves and found an discussion about
this topic earlier, but it seemed to be without a result:
http://www.xfree86.org/pipermail/render/2001-March/000829.html
I think that it would be good to have this issue fixed for two reasons. First,
it looks ugly and second, for many people resizing a window is a simple way
of testing the performance of a new OS like Linux.
First I also thought that this is an performance problem but I've tested it on
really fast hardware and that didn't make much difference. Now I've looked a
little bit closer and noticed that it more kind of an synchronization problem
between X, the WM and the App, than an performance problem. While resizing a
window it's frame is redrawn at a very high rate. Only the window contents is
redrawn very slowly. It sometimes even takes seconds to redraw. I think the
problem is like this: First the window manager gets an event from the mouse
and decides that the window needs to be resized. For every new mouse position
it receives, the WM draws a new window decoration. At the same time the WM
sends a message through X to the application that the window content needs to
be refreshed. Unfortunately, the application needs more time to redraw than
the WM and is also running at a lower priority. Therefore the application
throws many redraw requests away. In my opinion, the solution would be that
after the WM has send the redraw request to the application it should wait
until the application has finished redrawing the window before processing the
next mouse event. I had a look into the X api but I didn't figure out how the
WM could detect if the redawing is finished or not. But it might be that I've
overlooked it. One way of getting this information would be to let the WM and
the application talk directly to each other, but I think that this would be a
hack. I would have tried to come up with a patch on my own, but I really
don't know enough about XFree to do that.
Another thing that I've noticed is that when moving a window from left to
right or vice versa the window is split along a line and the upper part of
the window is drawn at a slightly different position than the lower part.
This splitting line is always at a different position. I think this happens
because X doesn't synchronize with the horizontal screen refresh. X should
wait until the screen refresh is finished before changing the frame buffer so
that only a consistent picture is brought to the screen.
In case I got something wrong here than I would like to apologize for it.
Cheers,
Lukas
--__--__--
Message: 11
Date: Sat, 22 Jun 2002 05:33:31 -0400 (EDT)
From: "Mike A. Harris" <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc: Johannes Rath <[EMAIL PROTECTED]>
Organization: Red Hat Inc.
Subject: [Xpert]Re: AW: Re: again firegl8700
Reply-To: [EMAIL PROTECTED]
On Fri, 21 Jun 2002, Johannes Rath wrote:
>Date: Fri, 21 Jun 2002 11:20:05 +0200
>From: Johannes Rath <[EMAIL PROTECTED]>
>To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
>Content-Type: text/plain;
> charset="iso-8859-1"
>List-Id: General X Discussion <xpert.XFree86.Org>
>Subject: AW: Re: again firegl8700
>
>Mike,
>
>that's not correct.
>
>1002:5148 is the chip ID for the r200 (used on both boards)
>
>The boards can be found in the subdevice ID:
>
>ATI FireGL 8700
>1002:0172
>
>ATI FireGL 8800
>1002:0152
Even better. Thanks John, I will update the list to detect both
of these cards now. No idea if both cards work with the open
source driver or not, but it doesn't hurt to find out. ;o)
At least it wont show up autodetected improperly, or not at all
in an lspci listing.
Thanks again.
--
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: 12
Date: Sat, 22 Jun 2002 06:10:00 -0400 (EDT)
From: "Mike A. Harris" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Organization: Red Hat Inc.
Subject: [Xpert]Re: Re: again firegl8700
Reply-To: [EMAIL PROTECTED]
On Fri, 21 Jun 2002, Dr Andrew C Aitchison wrote:
>> >01:00.0 Class 0300: 1002:5148 (rev 80)
>> >thank you
>>
>> No, thank you! ;o) I've just updated our hardware database to
>> autodetect the FireGL 8700 as 1002:5148
>>
>> Does anyone know what the ATI FireGL 8800's PCI ID is? I'll add
>> that one too.
>
>Is there enough pattern to the ATI PCI chip ids to guess which
>driver to use for unknown chips?
The ATI hardware documentation provides enough information to
know what family (Mach64/R128/Radeon R100/RV100/R200/RV200)
wether or not it is a Mobility chip, and which one, etc. I
haven't noticed anywhere in the docs which show the actual board
names used to market the video hardware such as "Xpert@Work 98",
"FireGL 8700", etc. A fair number of these ID's we can
autodetect and point to the right driver, since if XFree86
supports the card, then it has the PCI ID listed internally, and
we can just use that info to provide the right driver.
If I'm unsure if a card will work or not, and don't have one, I
look at the docs, and the code, and try to add support that will
hopefully work (and mostly has so far). However I may not know a
given card is a "ATI Radeon 7200" per se. (random example). So
users wont actually see "ATI Radeon 7200" show up as
autodetected currently, they'll see "ATI Radeon QD" or whatever
it happens to be.
By the way... what is the "lspci -vn" output of a Radeon 7000,
7200 so I can make these autodetect with proper names. ;o)
>For example we could have guessed that the 1002:5148 would user
>the same driver as 1002:5144 - 1002:5148. When we add the ID to
>the hardware database it isn't as if we actually change the
>driver in any way.
Well, when it is added to XFree86 xf86PciInfo.h, the driver does
need to change, so whoever is making those changes needs to know
if it is a Radeon or whatever, or what driver it should get added
to, as the conditional code paths in the given driver will need
to be updated for the new card.
That coupled with the ATI tech specs allows me to set up the
PCItable to choose the right driver. For some hardware we may
not know if it _works_, but that is what beta testing is for. If
something doesn't work, it can be fixed and/or disabled, or the
"vesa" driver used temporarily instead.
I'm looking into getting a more proper official list of the PCI
ID's and the marketing names they map into, so users will see the
name of their actual card as it says on the box rather than
seeing "ATI Radeon QW" or similar in dialogs, etc.
Take care!
TTYL
--
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: 13
Date: Sat, 22 Jun 2002 15:16:30 +0200
From: Christian Berger <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Xpert]keyboard on IBook
Reply-To: [EMAIL PROTECTED]
Servus
Well I have Xfree 4.2.0 running on my IBook.
It works fine except for some problems with the keyboard. All the
special characters like @ don't work anymore. For example @ worked with
Alt+Shift+1 It worked with an older version.
Any ideas what it could be?
Servus
Casandro
--__--__--
Message: 14
Date: Sat, 22 Jun 2002 09:23:46 -0400
From: Geoffrey <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Xpert]dual head on a Radeon VE
Reply-To: [EMAIL PROTECTED]
I've been trying to get dual head working on my retail Radeon VE. I've
toggled between Xfree 4.2 and the Gatos stuff. I know some folks have
this working, both retail and oem cards.
I keep getting the message:
Please use only one Device/Screen section in your XFConfig file
Which doesn't make sense from the examples I've found on the xinerama
howto and two articles on dual head I've reviewed from Linux Journal.
When my box first boots, the two monitors mirror the boot output and
console output afterwards. My card has vga, flat screen, and tv
outputs. I've got a Viewsonic 20G on the vga and a small converter that
came with the card on the flat screen output with a 15" Nec monitor.
I'm running kernel 2.4 Mandrake 8.0.
Any assistance would be appreciated.
--
Until later: Geoffrey [EMAIL PROTECTED]
I didn't have to buy my radio from a specific company to listen
to FM, why doesn't that apply to the Internet (anymore...)?
--__--__--
_______________________________________________
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
