> > No. > I'd also like to apologise for the formatting, gmail great for typing, crap for editing. So I've thought about it a bit more and Daniel mentioned something useful I thought I should add. Merging this code as well as maintaining a trust relationship with Linus, also maintains a trust relationship with the Linux graphics community and other drm contributors. There have been countless requests from various companies and contributors to merge unsavoury things over the years and we've denied them. They've all had the same reasons behind why they couldn't do what we want and why we were wrong, but lots of people have shown up who do get what we are at and have joined the community and contributed drivers that conform to the standards. Turning around now and saying well AMD ignored our directions, so we'll give them a free pass even though we've denied you all the same thing over time. If I'd given in and merged every vendor coded driver as-is we'd never have progressed to having atomic modesetting, there would have been too many vendor HALs and abstractions that would have blocked forward progression. Merging one HAL or abstraction is going to cause pain, but setting a precedent to merge more would be just downright stupid maintainership. Here's the thing, we want AMD to join the graphics community not hang out inside the company in silos. We need to enable FreeSync on Linux, go ask the community how would be best to do it, don't shove it inside the driver hidden in a special ioctl. Got some new HDMI features that are secret, talk to other ppl in the same position and work out a plan for moving forward. At the moment there is no engaging with the Linux stack because you aren't really using it, as long as you hide behind the abstraction there won't be much engagement, and neither side benefits, so why should we merge the code if nobody benefits? The platform problem/Windows mindset is scary and makes a lot of decisions for you, open source doesn't have those restrictions, and I don't accept drivers that try and push those development model problems into our codebase. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
