[PATCH xserver] modesetting: Remove ms_crtc_msc_to_kernel_msc().

Mario Kleiner mario.kleiner.de at gmail.com
Sat May 5 05:12:30 UTC 2018


I wrote a little program to simulate how ms_kernel_msc_to_crtc_msc()
is implemented in servers 1.16 - 1.20
and how it responds to msc's delivered by the kernel.

If i didn't make a mistake, then according to the compiler it turns
out that ms_kernel_msc_to_crtc_msc is broken in all servers.
The wraparound handling never triggers when it should, so the function
is essentially a no-op. If it would, it wouldn't deal with vblank
events that arrive with slightly out-of-order msc's (ie. sometimes not
monotonically increasing), as probably can happen during dpms off/on
or suspend/resume cycles, when the kernel blasts out all pending
vblank events in fifo order. If it would, it would be more broken on
server 1.20 due to improper handling of true 64-bit msc input from the
new sequence api's of Linux 4.15+.

The attached program simulates the different variants. I'll try to
write a patch later today that implements the spirit of the
"mapit_good" function in the program.

The method of 32-bit wraparound handling is stolen from mesa commit
cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence
swap completion events correctly. (v2)") which happens to solve the
same problem for mapping 32-bit sbc to 64-bit sbc and dealing with
wraparound.

Just to say, maybe wait a little bit longer with server 1.20 release
to get this fixed.

thanks,
-mario


On Fri, May 4, 2018 at 2:41 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi Mario,
>
> On 4 May 2018 at 13:14, Mario Kleiner <mario.kleiner.de at gmail.com> wrote:
>> Indeed, i found a Mesa bug yesterday which can cause Mesa's
>> PresentPixmap request to spuriously feed garbage targetMSC's
>> into the driver under some conditions. However, while other
>> video drivers seem to cope relatively well with that, modesetting
>> ddx causes KDE-5's plasmashell to lock up badly quite frequently,
>> and my suspicion is that the code removed in this commit is one
>> major source of the extra fragility.
>
> Thanks a lot for tracking this down! Adding Eero to Cc, who I think
> stumbled on this very problem.
>
> Cheers,
> Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vblankcalc.c
Type: text/x-csrc
Size: 3667 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180505/a777fa3b/attachment.c>


More information about the xorg-devel mailing list