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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
19 matches
Mail list logo