Re: [ANNOUNCE] xorg-server 1.19.99.904

[Thomas Klausner]

On Fri, Apr 20, 2018 at 11:07:04AM -0400, Adam Jackson wrote:
> On Fri, 2018-04-20 at 08:18 +0200, Thomas Klausner wrote:
> 
> > extern __attribute__((visibility("default")))
> > # 112 "../../dri3/dri3.h" 3 4
> > __uint32_t
> > 
> > # 113 "../../dri3/dri3.h"
> > drm_format_for_depth(
> > 
> > 
> >
> > I don't see the problem, do you?
> 
> We're not expecting another #line expansion there.

Thanks!

We already had a patch for such a problem with pid_t in pkgsrc, and
I've extended it to uint32_t, which fixes the problem for me.

It's attached.

Let me know if it can go in like this or what else we can do to fix
this.

Thanks,
 Thomas


patch-hw_xfree86_sdksyms.sh
Description: Bourne shell script
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] present: fix msc offset calculation in window mode

[Roman Gilg]

You are right that this would prevent possible future backends
supporting window mode and with real crtcs to return consistent msc
values. But this wouldn't work anyway currently since
present_wnmd_get_ust_msc_ptr does not provide the crtc it expects to
the backend, but only the window.

I think now that this should change instead of the patch I sent in
here (add the crtc argument back to the call). This way Xwayland could
check the expected crtc and if it is not the fake one currently in its
xwl_window struct it would just return an error (and then
present_wnmd_window_to_crtc_msc would use the window_priv->msc value
instead).

On Fri, Apr 20, 2018 at 6:11 PM, Michel Dänzer  wrote:
> On 2018-04-20 05:10 PM, Roman Gilg wrote:
>> Instead of getting the current msc value from the window, which might be
>> different to old one directly take the last saved msc value saved in
>> the window_priv struct.
>>
>> Signed-off-by: Roman Gilg 
>> ---
>>  present/present_wnmd.c | 7 +--
>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/present/present_wnmd.c b/present/present_wnmd.c
>> index 72bda2f..80ffb01 100644
>> --- a/present/present_wnmd.c
>> +++ b/present/present_wnmd.c
>> @@ -518,8 +518,6 @@ present_wnmd_window_to_crtc_msc(WindowPtr window, 
>> RRCrtcPtr crtc, uint64_t windo
>>  present_window_priv_ptr window_priv = present_get_window_priv(window, 
>> TRUE);
>>
>>  if (crtc != window_priv->crtc) {
>> -uint64_t old_ust, old_msc;
>> -
>>  if (window_priv->crtc == PresentCrtcNeverSet) {
>>  window_priv->msc_offset = 0;
>>  } else {
>> @@ -527,10 +525,7 @@ present_wnmd_window_to_crtc_msc(WindowPtr window, 
>> RRCrtcPtr crtc, uint64_t windo
>>   * we'll just use whatever previous MSC we'd seen from this CRTC
>>   */
>>
>> -if (present_wnmd_get_ust_msc(window->drawable.pScreen, window, 
>> _ust, _msc) != Success)
>> -old_msc = window_priv->msc;
>> -
>> -window_priv->msc_offset += new_msc - old_msc;
>> +window_priv->msc_offset += new_msc - window_priv->msc;
>
> This is working around an issue in xwl_present_get_ust_msc (it doesn't
> return consistent MSC values for a window which has been unmapped and
> mapped again). This change might do the wrong thing with another backend
> which has real CRTCs and returns consistent MSC values for them.
>
> That said, maybe this is the best that can be done to address the
> immediate issue, but it might be good to at least add a comment saying
> this is a kludge which should be revisited after 1.20.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] present: fix msc offset calculation in window mode

[Roman Gilg]

On Fri, Apr 20, 2018 at 6:23 PM, Olivier Fourdan  wrote:
> Unfortunately, contrary to my initial tests, the black window still occurs
> randomly even with that patch applied.
That's unfortunate. How severe is it? Is it just for a short period or
longer? I believe you said on IRC that it once stayed black and never
resumed but you weren't sure if just the client froze.

One idea I have regarding the issue is, that I believe on Unrealize
the remaining queued events are not sent back to Present, but simply
discarded on xwl_present_cleanup. I think these events should still be
delivered to Present instead.

But maybe the best way forward instead would be to do what Michel
proposed: add a persistent private struct to Xwayland and not reuse
the xwl_window one, which gets destroyed on every Unrealize. This way
the window's Xwayland Present msc counter could keep running while the
window is unrealized and we could more reliable process events still
waiting for their target msc.

The problem is that I'm on a Plasma dev sprint by today till next
weekend and won't be able to work on the issue in this time. After
that I would try to setup my build enviornment for the Xserver again
and find a solution to the problem. If this is not possible in regards
to the planned Xserver release, we need to find another solution.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel