[git pull] drm fixes

[Michel Dänzer]

On Fre, 2011-03-25 at 17:51 +1000, Dave Airlie wrote: 
> 2011/3/25 Michel Dänzer <michel at daenzer.net>:
> > On Fre, 2011-03-25 at 17:21 +1000, Dave Airlie wrote:
> >> On Fri, Mar 25, 2011 at 10:17 AM, Linus Torvalds
> >> <torvalds at linux-foundation.org> wrote:
> >> > On Thu, Mar 24, 2011 at 5:07 PM, Dave Airlie <airlied at gmail.com> wrote:
> >> >>
> >> >> Like seriously you really think VFS locking rework wasn't under
> >> >> development or discussion when you merged it? I'm sure Al would have
> >> >> something to say about it considering the number of times he cursed in
> >> >> irc about that code after you merged it.
> >> >
> >> > Umm. That code was basically over a year old by the time it was merged.
> >> >
> >> > How old was the code we're talking about now? Seriously?
> >>
> >> It was 30 lines of clean code, that really was fine to be merged in
> >> its first form it was merely a future maintaince issue to clean up the
> >> interface before it was released as stable.
> >
> > From my POV the real failure here was that the change made it to *any*
> > tree while there were outstanding review issues from when it was
> > initially discussed a few weeks earlier. Then when the change was
> > submitted — more or less unchanged — I was on my birthday weekend
> > enjoying some time away from computers, and when I had caught up with
> > things, it was already in drm-next.
> 
> Thats the problem really I read all the discussion and there wasn't
> much that seemed bad, I think the problem with your suggestions was
> there was a lot of latitude to disagree with them and I read the
> comments and disagreed with them as well, and it fixed the problem so
> I decided it should be pushed or we'd end up waiting another 6 months
> to fix it for the people who it actually affects. This isn't the
> message that I'd like to send to people who get off their arses and
> fix our fuckups.

The fuckup is in userspace trying to use a kernel interface which never
pretended to work for more than 2 CRTCs for the third and above CRTCs.


> >> In this case, if you had a >2 monitor setup connected to an evergreen
> >> card, and you tried to do 3D on the 3rd monitor it would just hang the
> >> app in a loop forever, the fix needs 3 pieces, one in the kernel, and
> >> two userspace fixes.
> >
> > Actually, the hangs could be fixed in the X driver alone, but the author
> > seems uninterested in contemplating that. Maybe because he seems to
> > think it's easier to get the kernel fix to users, but I'm with you on
> > that it's quite clearly the opposite.
> 
> I can't see how you can actually fix the hangs in userspace, 

By not calling the kernel interface when you know it won't do what you
want.

> you can hack around the hangs so the user just gets a less useful behaviour
> and make maintaining the userspace hack forever, or you can fix the
> insufficient kernel interface and get it out quick. I'm not really
> into the whole put a userspace hack in and maintain it for years thing
> either, and I'd rather nobody else ever decided it was a good idea.

Userspace has to check for the presence of the fixed kernel interface
anyway. In the absence of it, the currently proposed fix just keeps the
same old broken behaviour, risking hangs in some circumstances, when it
could avoid them with possibly not too much effort.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer