Re: [git pull] drm fixes

[Michel Dänzer]

[ Removing Linus from CC, I doubt he's that interested in this anymore ]

On Fre, 2011-03-25 at 09:52 -0500, Ilija Hadzic wrote: 
> 
> * 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.

It's not possible to synchronize correctly in this case, that's the
whole point. When userspace calls the ioctl for a different CRTC than
the one it's really interested in, that's (when it doesn't hang)
essentially making up a sequence number which doesn't necessarily have
any direct meaning for the CRTC userspace wants to synchronize to. I
suggested several other possibilities for making up sequence numbers in
that case without risking[0] a hang. But even if you don't want to go
into that, which is understandable to some degree, there's always the
simple option of not exposing this functionality to the X server at all
in this case.

[0] Or rather deliberately triggering, as userspace should know when
CRTC 1 is disabled.


> * 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.

Will they? As Dave pointed out, a new xf86-video-ati release with the
fix could be out at any time, but the kernel change could still take
months to make it into a distro kernel.


> * Saying that "kernel was not supposed to work with more two CRTCs" is
>    just plain wrong

That's not what I said.

There's no question that the kernel change will be necessary for all the
functionality to work perfectly on all CRTCs. But the hangs are mostly a
userspace issue and can be fixed there alone.


> 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).

That's your point of view. Mine is that your (certainly appreciated)
fixes had flaws that could have been easily and quickly resolved if you
had so chosen. Instead, you wasted a lot of everybody's time pushing
back and justifying the flaws rather than cooperating on a better
solution.

You won't have any trouble finding plenty of examples of newcomers
having a better experience, as most of them thankfully don't come in
with such a bad attitude and conduct.


-- 
Earthling Michel DÃnzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/