From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753898Ab1CYOwW (ORCPT ); Fri, 25 Mar 2011 10:52:22 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]:36998 "EHLO ihemail3.lucent.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753701Ab1CYOwU (ORCPT ); Fri, 25 Mar 2011 10:52:20 -0400 Date: Fri, 25 Mar 2011 09:52:08 -0500 (CDT) From: Ilija Hadzic X-X-Sender: ihadzic@umail To: Michel =?ISO-8859-1?Q?D=E4nzer?= cc: Dave Airlie , Linus Torvalds , linux-kernel@vger.kernel.org, DRI mailing list Subject: Re: [git pull] drm fixes In-Reply-To: <1301040045.12159.64.camel@thor.local> Message-ID: References: <1300864998.3522.71.camel@thor.local> <1300868532.3522.81.camel@thor.local> <1300880747.16522.13.camel@thor.local> <1301039010.12159.56.camel@thor.local> <1301040045.12159.64.camel@thor.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This thread turned into much more than what its scope is and I hoped I would stay out of the "fight" (especially after the vocabulary got very "liberal"). Yet, my code (as trivial as it is) has sparked up some old issues and seems to be referred to over and over again, so I want to make a few technical points straight: * There is no way for an application to see the VBLANK events without crossing into the kernel. VBLANKs are interrupts from the hardware and only kernel knows them. Any userspace-only fix would be an ugly hack (as Dave pointed) and maybe the application would look like it's not stuck but it would not be doing the right thing no matter what you do in the user space. So if I was fixing this, I figured I would do it right. If anyone knows better than me and can technically prove (in code, not in words) that an application can synchronize to (a correct) VBLANK without calling the kernel, be my guest: submit your code and evict mine. I have no problem with that, but if something breaks then, it *will* be a regression. * Most comments about DDX pertained to old-kernel/new-userland situation, which for most users using distros won't happen because distros will make sure they have they have consistent packages. Still, even that situation was taken care of in the sense that it does not cause bogus errors (BTW, that comment was made and was legitimate and I took care of it) nor any other "damage" to the kernel. Discussing whether visual behavior in this case (a case that is actually an installation/dependency problem) should be the same as in old versions or still broken but masked out in appearance is a waste of time and bandwidth. * Saying that "kernel was not supposed to work with more two CRTCs" is just plain wrong (and probably based on superficial understanding of the kernel code). I spent considerable time analyzing the kernel from the driver up and the userland from the application down and found that *everything* in the kernel is capable of supporting up to 32 CRTCs and so is in the userland. It's only that one ioctl was stopping the information flow between the userland and the kernel so I fixed it. That may have been the legacy from old days when kernel didn't support multiple CRTCs, but now it does. Also, there is now hardware with multiple CRTCs, so kernel (and associated ioctls) should better support it. * My fix alone, does not justify introducing a new ioctl and nobody can convince me that it does. In fact, being too liberal on introducing new ioctls is just bad programming. Recognizing that the existing ioctl has other shortcomings and coming up with a totally new ioctl with many other features and then adjusting the userland to use it is a long term project. My fix was a short term thing to get things that are broken working. And just a few non-technical things in conclusion and a few of my own thoughts and views: Although I didn't mention any names so far, everyone smart enough reading this will know that most of my responses are a) directed to Michel and b) are just a repeat of what I have already said on the list (in response to his repeat of what was also already said). Let me just say that I value everyone's comments and I respect the knowledge, work and time effort of everyone in this group. However, in every development model (including the open-source) there is a point after which you have to move on (even if the proposed thing is not perfect) and there is someone whose word should be final. My understanding is that for the DRM, the final say comes from Dave. So, fine, there were imperfections in my proposed modification to the ioctl, there was one comment that I (mistakenly) oversaw and that Michel found utterly important (although I still think that it wasn't that much of a big deal), but if Dave accepted the original change, that implicitly meant that he took into accounts the discussion, follow-up modifications and rebuttals and that the issue should be behind us. Continuing to insist after that point is just plain destructive (and could be in part the reason why DRM, besides the lack of resources, is behind closed-source drivers). And there is another point that Dave made that I fully support. To all of you, I am a newcomer, and a plain garden-variety user who instead of whining on Bugzilla and hoping that some hacker out there will show some "mercy", actually stepped up to fix the problem (and to be allowed to do that, I had to convince a few higher-ups that this would actually be in the interest of those who write my paycheck). Some of you have shown appreciation for that (thanks!), but some of you have seen it as an opportunity to publicly prove that you are smarter than me (for which I frankly don't care, as long as it does not impact the progress of the development, but in this case it did). I may be new to Linux/DRM "club", but I am not new to the large system development (including a wide variety of kernels and other very complex subsystems). Now if I can get my own (very reasonable, technically correct, generally well written, and useful for the community) fixes into open-source without sparking up major fights, then in my day-job, I have a strong case to present to a bunch of MBAs in three-piece suits that we should be basing more of our products on open-source code. That alone, in the long run helps the community, which is, I presume, a common interest of all of us. 'nuff said -- Ilija