ubuntu bulletproof x

[Jeff Spaleta]

On 9/2/07, Douglas McClendon <dmc.fedora at filteredperception.org> wrote:
> Cmon man.  The fact that you see so much press about 'bulletproof-x'
> does give you "an idea" about how much "energy" ubuntu is investing in this.

Nope.
>
> No, it doesn't tell you $1k, or $5k, or $250k, but it does tell you
> something.

Yes, it tells me that people are interested in the problem space.. and
that perception counts for a lot.
> Is there something in there describing how that work can automagically
> recreate the information that cannot be retrieved from a 'broken' edid
> hardware implementation, in which the data in the inf is correct?  Going
> beyond 'speculation', I did a little googling, and found these two
> posts, which seem to suggest that the situation Olivier Galibert
> described, and which I have speculated, is a real scenario-
>
> http://lists.freedesktop.org/pipermail/xorg/2005-October/010716.html

Perhaps you missed some very important points in this specific url you
posted. First of all that post is from Mike Harris, who was employed
by red hat at the time of that post. So approximately 2 years ago at
least one redhatter, who was working with Xorg upstream development
was thinking hard about this problem.  This is noteworthy and
significant concerning the history of developing a solution in the
problem space. Again I'll point out that Mike references the same inf
parsing script that Adam referenced.

More importantly he said in that very posting that you qoute that
using the inf information in the specific case being looked at in the
thread didn't actually solve the issue. Because the information in the
inf file is not sufficient to correct the issue being experienced. And
that's the main thrust here in this thread.

Inf information is not sufficient.  Mr. Jackson is working to solve
the issue of dealing with hardware detection, even working around
broken EDID, in a more general way..as part of the ongoing Xorg
development process.

>
> http://www.nvnews.net/vbulletin/showthread.php?t=83575

Please avoid referencing binary only drivers. It only complicates
matters because we can't actually examine the code.

> Again, I could be wrong, but I really do think your telling me to STFU
> was uncalled for.

I asked you to bring technical arguments to the discussion so that we
can move it forward. Continuing to re-iterate that you feel a certain
technical implementation is appropriate doesn't move things forward. I
did not ask you to shut up... I asked you to start providing
information which moves the discussion forward.

> And perhaps, if fedora actually respected ubuntu, and kept up with their
> advances, rather than exclusively playing catch up, they wouldn't be
> having their asses handed to them.

I'm not convinced Fedora is playing catch-up in technical
achievements. What we are playing catch-up in is perception, no doubts
about that.  And for all the Fedora developers who are currently
reading this thread. I want to take this opportunity to make sure I
stress the importance of making the time to use the evolving Fedora
Feature Roadmapping process, for as much of the work that you are
doing in Fedora and upstream. I realize that some of you may consider
the Feature roadmapping process as a distraction from getting the hard
technical work done. But its one of our best tools to praise the work
you are doing in the context of the larger distribution goals.

-jef