Les Mikesell <lesmikesell <at> gmail.com> writes:
> It's not typical to update products to match a new standard before the
> standard in question is finalized, wireless-N notwithstanding.

Yet this is normally how things work in the Free Software world, especially for
drivers, one is supposed to track upstream development and keep one's driver
updated for it as things change, not wait for a release. The fact that NVidia
can't adapt to this is only their fault, or the fault of the non-Free license
and the closed development model they have chosen. If their driver was released
under an acceptable license for the upstream project their driver is for and
developed in the upstream repository (as drivers are supposed to), we wouldn't
have this problem.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Kevin Kofler wrote:

Les Mikesell <lesmikesell <at> gmail.com> writes:
It's not typical to update products to match a new standard before the
standard in question is finalized, wireless-N notwithstanding.


Yet this is normally how things work in the Free Software world, especially for
drivers, one is supposed to track upstream development and keep one's driver
updated for it as things change, not wait for a release.


It seems unique to fedora to me. When has RHEL shipped pre-release code
expected to be incompatible with other popular software?


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, 2008-05-22 at 00:34 -0500, Les Mikesell wrote:
> It seems unique to fedora to me. When has RHEL shipped pre-release code
> expected to be incompatible with other popular software?
_____
| |
| o|
| -| /
|_____| / |\___/|
| / | |
|-----/ |x x|
| | |
| | . . |
| \___/
/
/
/

I think this horse has had enough.

Jonathan
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jonathan Dieter wrote:

On Thu, 2008-05-22 at 00:34 -0500, Les Mikesell wrote:

It seems unique to fedora to me. When has RHEL shipped pre-release code
expected to be incompatible with other popular software?


_____
| |
| o|
| -| /
|_____| / |\___/|
| / | |
|-----/ |x x|
| | |
| | . . |
| \___/
/
/
/

I think this horse has had enough.

Jonathan


To put it another way:

sage

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, May 22, 2008 at 2:01 AM, Kevin Kofler <kevin.kofler@chello.at> wrote:

Les Mikesell <lesmikesell <at> gmail.com> writes:

> It's not typical to update products to match a new standard before the

> standard in question is finalized, wireless-N notwithstanding.



Yet this is normally how things work in the Free Software world, especially for

drivers, one is supposed to track upstream development and keep one's driver

updated for it as things change, not wait for a release. The fact that NVidia

can't adapt to this is only their fault, or the fault of the non-Free license

and the closed development model they have chosen. If their driver was released

under an acceptable license for the upstream project their driver is for and

developed in the upstream repository (as drivers are supposed to), we wouldn't

have this problem.



* * **
I am pretty sure RedHat new exactly what it was doing when choosing Xorg 1.5.
The users would be used as a "mass of manoeuvre" to press Nvidia to catch up.

It is a valid strategy in my opinion. Certainly, the customers of RHEL would never have

to be exposed this way, but they pay for a special treatment.

Those who can use the nv driver, good. Others like me, who write code to be run on Nvidia graphics boards and/or use CUDA, have no option but wait. Furthermore, I like F8 very much...

*

--
Paulo Roma Cavalcanti
LCG - UFRJ
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2008-05-21 at 14:09 -0400, Adam Jackson wrote:
> On Wed, 2008-05-21 at 20:03 +0200, Nicolas Mailhot wrote:
> > Le Mer 21 mai 2008 19:32, Les Mikesell a écrit :
> >
> > > I don't have a problem with Xorg taking any amount of time they want.
> > > The problem is in fedora shipping a pre-release - or perhaps even more
> > > so in their claim of knowing that the ABI is finalized before it is in
> > > fact published as a standard.
> >
> > I suggest you complain to the xorg 1.5 release engineer the Fedora
> > xorg maintainer is not coordinating with him closely. And then that
> > you follow the advice of the xorg 1.5 release engineer on this issue.
>
> You know I'm both, right?

And a superhumanly good job you've done for this release twice over, for
that matter.

--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Denis Leroy wrote:

Jóhann B. Guðmundsson wrote:

Denis Leroy wrote:

Jason Tang wrote:

The only problem being that this release is incompatible with current
nvidia drivers. Granted, I'm aware of the Fedora position regarding
non-OSS, but this Xorg issue has completely destroyed many user's
confidence in the dev team.


That's nothing new you know. Out of the 9 fedora releases, I think
at least 8 out of 9 didn't work with the Nvidia driver at release
time. however Nvidia is usually pretty good at playing catch up.


I'm also hostage to Nvidia's good will for my Lenovo T61's Quadro
chipset, and can't upgrade to F-9 until their next release (nv
doesn't work at all on this chipset). I wouldn't go back to a Radeon
chipset though, not until we have a working free equivalent
(emphasis on 'working') to nvidia-settings for easy dual-head
support... The good news is that with xrandr maturing, we're
probably almost there.



Interesting...

I have no "nv" problems on my Lenovo T61p with Quadro FX570M.
Running with no xorg.conf. ...
http://www.smolts.org/client/show/pub_1536ec85-61c8-49d4-aeaa-3852a20d5d29



Hmm, mine is a NVS 140M. nv yields a black screen.

With or without an xorg.conf ?

You will need an xorg.conf for dual monitors or an customised script
that you run after you

booted the laptop.

I'm not quite sure how their gonna fix the dual monitor one without an
xorg.conf,


Is xrandr capable of setting virtual resolution size?
Even if nv worked, it's unbearably slow and can't handle dual
1680x1050 screens.

True the nv driver is slow..

If 1680x1050 is not supported then you need to find the next/closest
supported one..


I have to settle with 1360x768 when hooking my T61p to my HDTV which has
1920x1080.


Since rhgb does not have proper sanity checks ( It seems to detect the
resolution of the HDTV
( 1920x1080 ) and tries to set it to that resolution, or it tries to set
the resolution if the lcd

display to the HDTV and I end up with both screens black)

I have to first start the laptop then put it in my dock
then run a xrandr script I created to change the resolution
of my T6p laptop display and set it to 1360x768 and the display sent to
the HDTV ..

( Not using any xorg.conf )

This is from my xorg.conf on my Dell workstation here at work, which has
an ati card and is running F9

Set to "panorama/spanning desktop".

I will see if I cant come up with something similar on my T61p and the
nv driver..


Section "ServerLayout"
Identifier "RandR Multihead layout"
Screen 0 "Screen0" 0 0
EndSection

Section "Monitor"
Identifier "DVI-0" # xrandr -q.. Should be DVI-0 Or DVI0
VendorName "Monitor Vendor"
ModelName "Dell 1800FP (Analog)" # Match your monitor
Option "PreferredMode" "1280x1050" # Set it to 1680x1050 or
closest match

Option "dpms" # Probably can be removed
EndSection

Section "Monitor"
Identifier "DVI-1"
VendorName "Monitor Vendor"
ModelName "Dell 1901FP (Analog)" Match your monitor
Option "PreferredMode" "1280x1050" # Set it to 1680x1050 or
closest match
Option "RightOf" "DVI-0" # Can either be LeftOf or RightOf
and change the DVI-0 to match xrandr -q output

Option "dpms" # Probably can be removed
EndSection

# Change the Device section to match NV

Section "Device"
Identifier "Videocard0"
Driver "radeon"
VendorName "Videocard Vendor"
BoardName "ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "DVI-0" # Needs to match xrandr -q output
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Virtual 2560 1024 # Set it to ( 2x1680 )x1050 or
closest match
Depth 24

EndSubSection
EndSection

But I would never criticize the Xorg developers, the only culprit for
nv being so bad is NVidia itself...




Nor was I blaming Xorg developers..

Ajax and Dave both have been doing extremely good work.

I have never understood why users always blame Fedora/Xorg for Nvidia
not catching up..


I have also never understood why hardware manufactures dont release
specs to the open source
community or atleast provide a proper functional driver even if it's an
closed one.


One would think it was in their best interest to sell as much of the
hardware they manufacture regardless of

which OS the end user is using.

JB...
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/5/22 "Jóhann B. Guðmundsson" <johannbg@hi.is>:
> I have also never understood why hardware manufactures dont release specs to
> the open source
> community or atleast provide a proper functional driver even if it's an
> closed one.
>
> One would think it was in their best interest to sell as much of the
> hardware they manufacture regardless of
> which OS the end user is using.

I'm going to hazard a guess and say that the reason that they don't
want to hand out specs is due to the fact all of their hardware is
very similar and they don't want to cannibalize sales of their high
end cards.
http://www.techarp.com/showarticle.aspx?artno=539

The only reason that I've been using their binary driver lately is for
the suspend and dual monitor support. In Feb., they finally released
a driver that would allow suspend and resume to work while my dell
laptop is docked. This is after years of it not working. I've
upgraded my two home machines to F9 and they seems to be working fine
with the nv driver other than suspend. I'm not upgrading my work
laptop until the binary driver comes out.

For past few years, I've been a supporter of Nvidia. They had always
provided the best binary drivers and eventually gotten around to
supporting the newer video cards. I've even written a spec where Dell
changed the video chips so that the better Nvidia card would be in the
laptop. (This was a large order and 3D capabilities were important.)
This was in spite of the fact, as others have pointed out, that they
are always late releasing a driver for a new distro when X has
changed.

Since, ATI/AMD have changed to providing hardware specs, I'm going to
be buying their stuff from now on. There's a bunch of stuff that
Nvidia's driver doesn't support and who knows if it will ever get
supported under Linux, i.e. hdmi audio, better power mgmt, etc. At
least with the AMD, I know that there's some hope that at some point
features will be added.

Thank you Fedora for not being held hostage to Nvidia. Sorry this has
turned into a bit of a rant.

James Hubbard

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Christopher Stone wrote:

On Wed, May 21, 2008 at 8:20 AM, Chris Adams <cmadams@hiwaay.net> wrote:

If it is so easy, why don't you do it in your own repo? Fedora is a
fully open distribution; all the necessary tools are there.


Should I make an assumption that you mean to say rpm is not a
"regular" tool. Sure, you would have to add some documentation on how
to install it by first uninstalling X. It's not so much compatibility
and support, but more a matter of convenience.


You have yet to explain how doing this effort, rebuilding the f8 xorg and
hosting it in updates-testing for f9... is going to change IN ANY WAY the method
you must follow for downgrading Xorg on F9. The version numbers are still going
to be lower than the F9 xorg unless you deliberately break everything sane about
rpm versioning in order to force them to upgrade.


Insisting that those rpms need rebuilt and specifically hosted for f9 is
stupidity. Downgrading xorg using the current F8 rpms works just fine. It
takes exactly the same effort as attempting to downgrade xorg using rpms with a
silly .fc9 in their name. You download rpms, you install them, you prevent them
from getting updated by f9 rpms.


--
Andrew Farris <lordmorgul@gmail.com> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On 2008-05-21, 16:01 GMT, Christopher Stone wrote:
> The version of the X server shipped with Fedora 9 comes with
> a new ABI which is not yet compatible with some third party
> binary drivers such as nVidia.

Just please reword it so that it doesn't like Fedora's fault.
Something along the lines:

Third party developers have not managed to port their
graphical drivers (nvidia and fglrx are the most prominent)
to the new Xorg API shipped in the current Fedora release
yet. If your use of the computer depends on these drivers,
then you are strongly advised either not to upgrade Fedora
9 yet, exclude xorg* packages from upgrade (when using yum
upgrade), or downgrade your xorg* packages back to those in
Fedora 8 after installation (when using upgrade from DVD).

What about this?

Matěj

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list