Beryl options and nvidia

Lonni J Friedman netllama at gmail.com
Fri Jan 5 21:17:52 UTC 2007


On 1/5/07, Marc Schwartz <marc_schwartz at comcast.net> wrote:
> On Fri, 2007-01-05 at 12:19 -0800, Lonni J Friedman wrote:
> > On 1/5/07, Marc Schwartz <marc_schwartz at comcast.net> wrote:
> > > Gérard Milmeister wrote:
> > > > I have beryl running with nvidia prop. drivers with the following
> > > > options:
> > > > beryl --use-cow --force-aiglx --skip-gl-yield
> > > > There are now problems with black windows etc... that may appear with
> > > > other options. The X server is running with increased priority (set by
> > > > using schedtool), so there responsiveness is good running tvtime
> > > > smoothly even under system load.
> > > > There is one small issue however: Before a menu window is filled with
> > > > content, there may appear some artifacts in the window background. These
> > > > disappear if I use the --force-nvidia option, but then UI responsiveness
> > > > is distintively slower and tvtime does not run smoothly anymore.
> > > > Is this is a known issue?
> > >
> > > There are known problems with the current nVidia drivers and the use of
> > > Compiz/Beryl, secondary to the current incomplete implementation of
> > > texture_from_pixmap (TFP) required for compositing. Based upon the
> >
> > incomplete in what way?
>
> Quoting from the 9629 Release Highlights last November 7:
>
> "Added initial support for GLX_EXT_texture_from_pixmap."
>
> The word "initial" suggests to any reasonable reader that the
> implementation is not complete or at least not fully stable and
> certainly experience over the two months since then has born that out.
>
> There has been no further mention of TFP in any of the similar highlight
> notes for any of the subsequent stable releases, despite hundreds of
> posts on nvNews, here and elsewhere relative to ongoing problems with
> running any of the composting managers.

Sorry if the word "initial" was misleading.  It was meant as an
indication that the 1.0-9629 beta driver was the first driver to
provide support for TFP, not that the support was incomplete.  The
support that was added to a driver from November was complete with
respect to the texture_from_pixmap specification.  As you didn't
actually reference any explicit missing functionality with respect to
the TFP specification, it seems that you're just equating compositing
bugs with incomplete support.

> > > present timeline since nVidia was made aware of these issues (> 2
> > > months), a fix appears to be a low priority for them and their official
> > > line is that they are still "investigating the problem".  Taken
> > > literally, that would suggest that they have not yet even identified the
> > > problem, as opposed to "we are investigating possible solutions".
> >
> > And you know this how?
>
> Well, as paid employee of nVidia, perhaps you will do me the courtesy of
> formally correct me?  That has been your stock communication on the
> nvNews Linux forum for weeks without further elaboration or any sign of
> incremental progress.
>
> Note that I used the words _incremental progress_, not "final, stable,
> complete solution". There has been no confirmation of anyone actually
> working on the problem other than trying to read between the lines of
> the above statement. It does not mean that someone (or even more than
> one person) is even working on the problem full time given the other
> priorities that seem to be implicit in other statements also made on
> nvNews.

Ignoring your misconceptions of how software development works for any
large codebase, I can tell you that the root cause of the issue is
currently fully understood.  However, as with any bug, its
prioritization is based on a number of factors which include, but are
not limited to, the severity of the issue, the percentage of
users/customers experiencing the issue, and the available workarounds
for the issue.  The compositing "black windows" bug impacts a
relatively small percentage of people, has a clear & simple
workaround, and therefore the time being allocated to providing a
solution is less than for bugs which have a higher priority.

> > And i'm not sure why you'd want a beta
> > driver when it was replaced with a newer non-beta several weeks ago.
>
> Because, believe it or not Lonnie, there are lots of people here (me
> included) who would gladly help nVidia test beta versions of your
> drivers to help move things along here. But none have been forthcoming,
> which is why I pointed out the beta page above and why I do check it
> frequently looking for a new beta version to test.

That is understood, and why beta versions of the driver are posted
when available.  Currently the latest driver version is not a beta.
Believe it or not, people also complain quite vocally when the latest
released driver is a beta versus a non-beta.  Not everyone can be
pleased all of the time.  Additional beta drivers will be posted when
appropriate.

>
> Beta and even alpha testing are common for folks within this community
> and is something that I have done periodically with RH/FC over the past
> several years dating back to the late RH 8.0 betas and for other FOSS
> projects that I participate actively in.

Sure, but as you know the NVIDIA driver isn't a FOSS project.
Applying FOSS project standards to non-FOSS software (or vice-versa)
will always result in disapointment.

>
> Ball's in your court.

I'm not sure what that means, but sure.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
L. Friedman                                    netllama at gmail.com
LlamaLand                       http://netllama.linux-sxs.org




More information about the fedora-list mailing list