On 9/2/07, Douglas McClendon <dmc.fedora@xxxxxxxxxxxxxxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
