Message-ID: <Pine.GSO.4.62.1103250637570.6266@umail>
Date:	Fri, 25 Mar 2011 09:52:08 -0500 (CDT)
From:	Ilija Hadzic <ihadzic@...earch.bell-labs.com>
To:	Michel Dänzer <michel@...nzer.net>
cc:	Dave Airlie <airlied@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists