On Tue, 22 Mar 2011, Michel [ISO-8859-1] Dänzer wrote:
Not calling the ioctl doesn't imply returning immediately. Your changes only fix the bug you found (the X radeon driver calls the ioctl when that doesn't make sense) when both the kernel and X driver are updated, but it would be possible to also fix it when only the X driver is updated.
At the risk of being called ignorant, I'll admit that I don't know how to fix it when only DDX is updated; at least not without introducing too much of the new stuff and even then, it won't be done right because for a process to properly wait on vblank it must cross into the kernel because that's where the vblank interrupts from the hardware are coming in.
If it does not return immediately, then what is the process going to wait on if glxSwap is called and DDX realizes that it does not want to call the ioctl ? Does it just sleep ? For how long ? Do we need to fake out vblank sequence numbers and/or timestamps ?
If you have a good idea, I'll listen, I'll try to understand, and I can look into implementing it in the next iteration. However, that should not be the reason for delaying this fix. There are multi-screen applications (including mine) that need proper functionality on higher-numbered CRTCs.
Then I suppose applying this patch is rock bottom of my priority list... But, as it seems you'd rather argue in your changes than adjust them to reviews, I can also just fix this part up after it goes in in the worst case.
Deciding which patch to apply based on emotions does not serve good to anybody, so let's "reboot" ourselves on this particular item.
I am not arguing in my changes, I am just saying that formatting the log message (where both formats are perfectly legitimate and it's only a matter of taste) is something that can go in later and either I can submit the follow-up patch next time something else is in the file is changed or anyone else can change it to the taste (including you).... and if it's changed I definitely won't argue it back because it won't be worth it.
-- Ilija
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel