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 21: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 #1935 - 2 msgs (OUT OF THE OFFICE) (Jason Craddock)

--__--__--

Message: 1
Date: Sat, 22 Jun 2002 20:31:46 -0600
From: "Jason Craddock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [Xpert]Re: Xpert digest, Vol 1 #1935 - 2 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/22/02 20: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: Documentation on XF86 extensions to X protocol? (James A. Crippen)
   2. Re: Xpert digest, Vol 1 #1934 - 2 msgs (OUT OF THE OFFICE) (Jason Craddock)

-- __--__-- 

Message: 1
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Documentation on XF86 extensions to X protocol?
From: [EMAIL PROTECTED] (James A. Crippen)
Date: 22 Jun 2002 17:33:54 -0800
Reply-To: [EMAIL PROTECTED]

[EMAIL PROTECTED] writes:

> The general answer is, the usual, "it depends".  The documentation for different
> extensions is in different places, if it exists at all.

Argh.  That's what I expected to hear.

> For the specific case of XFree86-Misc, the answer is that the documentation
> is distributed amongst:
> 
>       1) the XF86Misc man page (which documents the C interface, but
>       in so doing includes some bits that can be used to infer
>       documentation about the protocol)

Ah, of course there'd be a man page for it.  Why'd I not look there
first?  Sigh.

>       2) xc/include/extensions/xf86vm{ode,str}.h

And there second?  Should have thought about it...  Duh.

>       3) Some neurons in my brain that I haven't accessed in more
>       than half a decade

And there third?  So obvious!  ^_^

'james

-- 
James A. Crippen <[EMAIL PROTECTED]> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.

-- __--__-- 

Message: 2
Date: Sat, 22 Jun 2002 19:52:02 -0600
From: "Jason Craddock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [Xpert]Re: Xpert digest, Vol 1 #1934 - 2 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/22/02 19: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 #1933 - 5 msgs (OUT OF THE OFFICE) (Jason Craddock)
   2. Re: Documentation on XF86 extensions to X protocol? (James A. Crippen)

--  __--__--  

Message: 1
Date: Sat, 22 Jun 2002 17:31:38 -0600
From: "Jason Craddock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [Xpert]Re: Xpert digest, Vol 1 #1933 - 5 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/22/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 #1932 - 2 msgs (OUT OF THE OFFICE) (Jason Craddock)
   2. Re: Trident bug (kiss the sun and walk on air)
   3. Gotchas with NFS Root filesystem? (Skip Gaede)
   4. Re: Trident bug (Egbert Eich)
   5. Re: Trident bug (Alan Hourihane)

--   __--__--   

Message: 1
Date: Sat, 22 Jun 2002 12:51:35 -0600
From: "Jason Craddock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [Xpert]Re: Xpert digest, Vol 1 #1932 - 2 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/22/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. Re: Xpert digest, Vol 1 #1931 - 14 msgs (OUT OF THE OFFICE) (Jason Craddock)
   2. Re: Documentation on XF86 extensions to X protocol? (Jens Owen)

--    __--__--    

Message: 1
Date: Sat, 22 Jun 2002 07:52:06 -0600
From: "Jason Craddock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [Xpert]Re: Xpert digest, Vol 1 #1931 - 14 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/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


--    __--__--    

Message: 2
Date: Sat, 22 Jun 2002 08:23:34 -0600
From: Jens Owen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Documentation on XF86 extensions to X protocol?
Reply-To: [EMAIL PROTECTED]

[EMAIL PROTECTED] wrote:
> 
> The general answer is, the usual, "it depends".  The documentation for different
> extensions is in different places, if it exists at all.

Should we consider putting protocol documents in a common place under
the source tree?

Currently, the DRI extension encoding can only be found at
http://dri.sourceforge.net/doc/dri_extensions_low_level.txt

--                             /\
         Jens Owen            /  \/\ _    
  [EMAIL PROTECTED]  /    \ \ \   Steamboat Springs, Colorado


--    __--__--    

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


End of Xpert Digest


--   __--__--   

Message: 2
Date: Sat, 22 Jun 2002 15:30:06 -0400
From: kiss the sun and walk on air <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Trident bug
Reply-To: [EMAIL PROTECTED]


--BOKacYhQ+x31HxR3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 22, 2002 at 10:22:13AM +0000, Norman Walsh wrote:
> | Yes, the option is in there, now.=20
> | It is called "FpDelay" and can have the range -2 to 5.
> |
> | Please let us know which values work for you best.
>=20
> -2 works best, but it's not enough. If those are pixel values, I think
> something like -12 would work better.

Agreed. A positive value exacerbates the the problem. The ability to
go farther in the negative direction is needed to find the best value.

Thanks for the work, Egbert.
-pete

--=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

--BOKacYhQ+x31HxR3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9FNA9hxNyr2g6PGURAisNAKC9Vi3Kamy4PrVZt39C3HXP1dbFlACfY003
yBdKyo4dmAhQxhROTcq+8/Q=
=8fao
-----END PGP SIGNATURE-----

--BOKacYhQ+x31HxR3--

--   __--__--   

Message: 3
From: Skip Gaede <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Sat, 22 Jun 2002 15:38:57 -0400
Subject: [Xpert]Gotchas with NFS Root filesystem?
Reply-To: [EMAIL PROTECTED]

Folks,

I have a Mac client that's running XFree86 (4.2.0) -query + 
Mozilla and losing lots of size-2048 buffers. The rate loss 
is approximately 1000 buffers/hour. I'm seeing this loss of 
memory after I boot with an initrd, get an IP address with 
dhclient and do a pivot_root onto the read-only NFS file 
system.

I can also boot the the client to a bash prompt on the local 
hard drive and then run XFree86 -query + Mozilla as before. 
I went so far as to mung rc.sysinit and leave the local 
filesystem mounted RO and mount -t shm to /var and /tmp.
Under these conditions, both with and without the local 
filesystem mounted RO, the size-2048 buffer utilization is 
nominal.

Anyone ever seen or heard of this before? Any thoughts on 
how to isolate this to a root cause?

Thanks,
Skip

--   __--__--   

Message: 4
Date: Sat, 22 Jun 2002 15:12:50 +0200
From: Egbert Eich <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Trident bug
Reply-To: [EMAIL PROTECTED]

Norman Walsh writes:
 > 
 > -2 works best, but it's not enough. If those are pixel values, I think
 > something like -12 would work better.
 > 

According to my trident data books - which aren't on CyberBlades XP, Ai
etc - the range goes from -2 to 5. Maybe that's different on the newer
chips. Alan, do you have more informations on that?

Egbert.

--   __--__--   

Message: 5
Date: Sun, 23 Jun 2002 00:20:57 +0100
From: Alan Hourihane <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Trident bug
Reply-To: [EMAIL PROTECTED]

On Sat, Jun 22, 2002 at 03:12:50 +0200, Egbert Eich wrote:
> Norman Walsh writes:
>  > 
>  > -2 works best, but it's not enough. If those are pixel values, I think
>  > something like -12 would work better.
> 
> According to my trident data books - which aren't on CyberBlades XP, Ai
> etc - the range goes from -2 to 5. Maybe that's different on the newer
> chips. Alan, do you have more informations on that?

Just checked, and it's still the same for the XP series.

Alan.


--   __--__--   

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


End of Xpert Digest


--  __--__--  

Message: 2
To: [EMAIL PROTECTED]
Subject: Re: [Xpert]Documentation on XF86 extensions to X protocol?
From: [EMAIL PROTECTED] (James A. Crippen)
Date: 22 Jun 2002 17:32:00 -0800
Reply-To: [EMAIL PROTECTED]

Jens Owen <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
> > 
> > The general answer is, the usual, "it depends".  The documentation
> > for different extensions is in different places, if it exists at
> > all.
> 
> Should we consider putting protocol documents in a common place under
> the source tree?

Since the official X Consortium documentation is already extant in the
source tree, and since the formats aren't standardized for this anyway
(some is in text only, some is in troff+ms macros, some is in
FrameMaker (for some weird reason, and totally useless to Freenix
folk)), I think it'd be a very good idea to do so.  Maybe just add a
new xc/doc/xfree86 directory and put everything specific to XFree86 in
there.  Whatever formats are available.  Plain text, SGML/DocBook,
PostScript, troff, TeX...  It's all pretty anarchic anyway.

> Currently, the DRI extension encoding can only be found at
> http://dri.sourceforge.net/doc/dri_extensions_low_level.txt

And hunting this sort of stuff down from the existing docs, even from
the XFree86 web page, is not exactly obvious... :-(

'james

-- 
James A. Crippen <[EMAIL PROTECTED]> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.


--  __--__--  

_______________________________________________
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

Reply via email to