On Wed, Aug 13, 2014 at 01:12:12PM +0530, Sharma, Shashank wrote: > On 8/13/2014 11:46 AM, Chris Wilson wrote: > >On Wed, Aug 13, 2014 at 11:34:02AM +0530, Sharma, Shashank wrote: > >>5. We want this code routine only to be executed for commercial (like > >> android) platforms, whereas others get the routine code. > > > >In other words, you want to ignore years of real world compatibity testing > >and larger user bases. > > > I do not mean this for sure, in fact we would be happy if the community > accepts this for regular code flow also, but due to their previous > objections and stand for not to go for a live_status based solution, made to > to come via this route. Please suggest how can we do this in better way. So I'm grumpily ok with a special validation mode to get a sticker. Occasionally there's a business need for those stickers, and it kinda makes sense to merge that code upstream. But in the end reality in the form of existing broken hdmi screens out there wins. Always. And you actually learned that already by adding hacks to your validation-only path to make it actually work in reality. Sooner or later you need to add all the other crap we've accumulated too, or the driver will simply not work. Which means we'll actually not end up with a restricted validation-only hack, but duplicated code&bugs. I'm _not_ going to have 2 separate paths with real-world quirks. If there's anything actually broken with the current code in upstream, we need to fix that one, not add a new one because that's easier. Because it's not. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
