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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
