Re: When starting Evolution /usr/lib/gdm3/gdm-x-session[2309]: (II) modeset information is printed to syslog

2018-09-05 Thread Chris
On Wed, 2018-09-05 at 15:16 -0400, Adam Jackson wrote: > On Sat, 2018-09-01 at 10:24 -0500, Chris wrote: > > > When starting Evolution this is output to syslog and periodically > > after it's running: > > > > https://pastebin.com/zndBukUG > > Evolution, or something it provokes, is asking the

Re: When starting Evolution /usr/lib/gdm3/gdm-x-session[2309]: (II) modeset information is printed to syslog

2018-09-05 Thread Adam Jackson
On Sat, 2018-09-01 at 10:24 -0500, Chris wrote: > When starting Evolution this is output to syslog and periodically after it's > running: > > https://pastebin.com/zndBukUG Evolution, or something it provokes, is asking the server for the list of available video modes. It's doing so with

Re: Smooth gdm -> GNOME3 session transition broken with 1.20 modesetting driver

2018-09-05 Thread Daniel Stone
Hi Hans, On Wed, 5 Sep 2018 at 19:23, Hans de Goede wrote: > Under Fedora 29 (xserver-1.20) the transition from GDM to > the GNOME3 session is no longer smooth, it seems that the > screen is cleared to black when the Xserver starts instead > of inheriting the framebuffer contents from GDM as

Smooth gdm -> GNOME3 session transition broken with 1.20 modesetting driver

2018-09-05 Thread Hans de Goede
Hi All, Under Fedora 29 (xserver-1.20) the transition from GDM to the GNOME3 session is no longer smooth, it seems that the screen is cleared to black when the Xserver starts instead of inheriting the framebuffer contents from GDM as before. Changing the DDX driver from modesetting to intel

Re: WebKit failing to find GLXFBConfig, confusion around fbconfigs + swrast

2018-09-05 Thread Emil Velikov
Hi Daniel, On 27 August 2018 at 09:07, Daniel Drake wrote: > Questions: > > 1. What should webkit be doing in event of it not being to find a > GLXFBConfig that corresponds to the X visual of it's window? > > Attempt another config that user(webkit) knows how to work with? > 2. Why is swrast

[Bug 107838] kernel mode setting detects unsupported screen resolutions

2018-09-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107838 Michel Dänzer changed: What|Removed |Added Assignee|xorg-driver-ati@lists.x.org |xorg-t...@lists.x.org

[PATCH xserver] glx: check for indirect context in CreateContextAttribsARB()

2018-09-05 Thread Olivier Fourdan
Commit 99f0365b "Add a command line argument for disabling indirect GLX" added a test to check if indirect context are enabled in `DoCreateContext()` but `__glXDisp_CreateContextAttribsARB()` doesn't use `DoCreateContext()` and doesn't check if indirect context is enabled. As a result, clients

[Bug 107838] New: kernel mode setting detects unsupported screen resolutions

2018-09-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107838 Bug ID: 107838 Summary: kernel mode setting detects unsupported screen resolutions Product: xorg Version: unspecified Hardware: Other OS: All

Re: [PATCH v2] present: fix freed pointer access

2018-09-05 Thread Olivier Fourdan
Hi, On Tue, Sep 4, 2018 at 6:28 PM Lionel Landwerlin wrote: > > Oh well... > I'm sure you'll be able to fix it faster than me :) > > - > Lionel > > On 04/09/2018 16:27, Roman Gilg wrote: > > Ok, I just got a failing assert in xwl_present_flips_stop with the patch when > opening a context menu

Re: [PATCH xserver v3] xwayland: Remove xwl_present_window from privates on cleanup

2018-09-05 Thread Lionel Landwerlin
On 05/09/2018 11:44, Olivier Fourdan wrote: Hi, On Wed, Sep 5, 2018 at 12:05 PM Lionel Landwerlin wrote: On 05/09/2018 09:49, Olivier Fourdan wrote: [...] This is because `xwl_present_cleanup()` frees the memory but does not remove it from the window's privates, and

Re: [PATCH xserver v3] xwayland: Remove xwl_present_window from privates on cleanup

2018-09-05 Thread Olivier Fourdan
Hi, On Wed, Sep 5, 2018 at 12:05 PM Lionel Landwerlin wrote: > > On 05/09/2018 09:49, Olivier Fourdan wrote: > > [...] > > This is because `xwl_present_cleanup()` frees the memory but does not > > remove it from the window's privates, and `xwl_present_abort_vblank()` > > will still find it and

Re: [PATCH xserver v3] xwayland: Remove xwl_present_window from privates on cleanup

2018-09-05 Thread Lionel Landwerlin
On 05/09/2018 09:49, Olivier Fourdan wrote: Xwayland's `xwl_destroy_window()` invokes `xwl_present_cleanup()` before the common `DestroyWindow()`. But then `DestroyWindow()` calls `present_destroy_window()` which will possibly end up in `xwl_present_abort_vblank()` which will try to access data

[PATCH xserver v3] xwayland: Remove xwl_present_window from privates on cleanup

2018-09-05 Thread Olivier Fourdan
Xwayland's `xwl_destroy_window()` invokes `xwl_present_cleanup()` before the common `DestroyWindow()`. But then `DestroyWindow()` calls `present_destroy_window()` which will possibly end up in `xwl_present_abort_vblank()` which will try to access data that was previously freed by

Re: [PATCH xserver v2] xwayland: Remove xwl_present_window from privates on cleanup

2018-09-05 Thread Michel Dänzer
On 2018-09-05 10:35 a.m., Olivier Fourdan wrote: > Xwayland's `xwl_destroy_window()` invokes `xwl_present_cleanup()` > before the common `DestroyWindow()`. > > But then `DestroyWindow()` calls `present_destroy_window()` which will > possibly end up in `xwl_present_abort_vblank()` which will try

[PATCH xserver v2] xwayland: Remove xwl_present_window from privates on cleanup

2018-09-05 Thread Olivier Fourdan
Xwayland's `xwl_destroy_window()` invokes `xwl_present_cleanup()` before the common `DestroyWindow()`. But then `DestroyWindow()` calls `present_destroy_window()` which will possibly end up in `xwl_present_abort_vblank()` which will try to access data that was previously freed by

[PATCH xserver] xwayland: Remove xwl_present_window from privates on cleanup

2018-09-05 Thread Olivier Fourdan
Xwayland's `xwl_destroy_window()` invokes `xwl_present_cleanup()` before the common `DestroyWindow()`. But then `DestroyWindow()` calls `present_destroy_window()` which will possibly end up in `xwl_present_abort_vblank()` which will try to access data that was previously freed by

Re: [PATCH xserver] xwayland: Clean-up present after destroying common bits

2018-09-05 Thread Olivier Fourdan
On Wed, Sep 5, 2018 at 9:48 AM Olivier Fourdan wrote: > > Right now, `xwl_destroy_window()` invokes `xwl_present_cleanup()` before > the common `DestroyWindow()`. > > But `DestroyWindow()` calls in `present_destroy_window()` which will > then end up in `xwl_present_abort_vblank()` which will try

Re: [PATCH xserver] glamor: Add support for exporting depth 16 pixmaps.

2018-09-05 Thread Michel Dänzer
On 2018-09-05 6:00 a.m., Eric Anholt wrote: > With a patch to mesa to expose rgb565 pbuffers even on a server with > only depth 24 and 32 visuals, fixes > dEQP-EGL.functional.render.single_context.gles2.rgb565_pbuffer. Those > pbuffers (or at least something renderable with 565) are required by >

[PATCH xserver] xwayland: Clean-up present after destroying common bits

2018-09-05 Thread Olivier Fourdan
Right now, `xwl_destroy_window()` invokes `xwl_present_cleanup()` before the common `DestroyWindow()`. But `DestroyWindow()` calls in `present_destroy_window()` which will then end up in `xwl_present_abort_vblank()` which will try to access data that was previously freed by