Re: [V2] modesetting: Fix X crash in ms_dirty_update()

[Alex Deucher]

On Sun, Aug 5, 2018 at 10:40 PM, Jim Qu  wrote:
> On some Intel iGPU + AMD dGPU platform, when connect extern display
> from dGPU, X will crash, show the log like:
>
> randr: falling back to unsynchronized pixmap sharing
> (EE)
> (EE) Backtrace:
> (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e)
> (EE) 1: /usr/lib/xorg/Xorg (0x55cb0151a000+0x1b5ce9)
> (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1587a1d000+0x11390)
> (EE)
> (EE) Segmentation fault at address 0x0
> (EE)
>
> There is NULL pointer accessing on ent->slave_dst->drawable.pScreen->
> SharedPixmapNotifyDamage.
>
> On the platform, since the dGPU is GPU device, so that the iGPU is
> output master device. SharedPixmapNotifyDamage() should be called when
> current device is output master.
>
> Change-Id: I8fa6922a4f75b5e068970fc4d362f778052379f2
> Signed-off-by: Jim Qu 

Reviewed-by: Alex Deucher 


> ---
>  hw/xfree86/drivers/modesetting/driver.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/driver.c 
> b/hw/xfree86/drivers/modesetting/driver.c
> index 9362370..37fafb1 100644
> --- a/hw/xfree86/drivers/modesetting/driver.c
> +++ b/hw/xfree86/drivers/modesetting/driver.c
> @@ -640,19 +640,21 @@ ms_dirty_update(ScreenPtr screen, int *timeout)
>  xorg_list_for_each_entry(ent, >pixmap_dirty_list, ent) {
>  region = DamageRegion(ent->damage);
>  if (RegionNotEmpty(region)) {
> -msPixmapPrivPtr ppriv =
> -msGetPixmapPriv(>drmmode, ent->slave_dst);
> +if (!screen->isGPU) {
> +msPixmapPrivPtr ppriv =
> +msGetPixmapPriv(>drmmode, 
> ent->slave_dst->master_pixmap);
>
> -if (ppriv->notify_on_damage) {
> -ppriv->notify_on_damage = FALSE;
> +if (ppriv->notify_on_damage) {
> +ppriv->notify_on_damage = FALSE;
>
> -ent->slave_dst->drawable.pScreen->
> -SharedPixmapNotifyDamage(ent->slave_dst);
> -}
> +ent->slave_dst->drawable.pScreen->
> +SharedPixmapNotifyDamage(ent->slave_dst);
> +}
>
> -/* Requested manual updating */
> -if (ppriv->defer_dirty_update)
> -continue;
> +/* Requested manual updating */
> +if (ppriv->defer_dirty_update)
> +continue;
> +}
>
>  redisplay_dirty(screen, ent, timeout);
>  DamageEmpty(ent->damage);
> --
> 2.7.4
>
> ___
> 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
___
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

gitlab archives (was Re: [PATCH app/luit] Retire this fork of luit)

[Adam Jackson]

On Tue, 2018-08-07 at 12:03 -0400, Adam Jackson wrote:
> We're not seriously maintaining this tool, we should stop pretending.
> 
> Signed-off-by: Adam Jackson 

Merged (and archived the project):

remote: remote: I: patch #243108 updated using rev 
2aaa5d75f1b92a5383af676dbd7f0998e26023ac.
remote: remote: I: 1 patch(es) updated to state Accepted.
remote: To ssh://kemper.freedesktop.org/git/xorg/app/luit
remote:e209207..2aaa5d7  2aaa5d75f1b92a5383af676dbd7f0998e26023ac -> master
To gitlab.freedesktop.org:xorg/app/luit.git
   e209207..2aaa5d7  master -> master

I've only cc'd the list about this patch because it's pointing people
elsewhere and not just archiving. Future archivals will be tracked with
gitlab issues. gitlab doesn't make it easy to see archived projects
recursively through subgroups, so there is a centralized list here:

https://gitlab.freedesktop.org/xorg/meta/wikis/archives

That page (and wiki) is also probably temporary, we should eventually
move off the old wiki and restructure a lot of our documentation
anyway.

- ajax
___
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] dix: check_modmap_change() returns Success, not true

[Keith Packard]

Peter Hutterer  writes:

> Not sure what if anything calls XSetDeviceModifierMapping() but this would've
> failed all the time. check_modmap_change() returns Successs but we were
> treating it like a boolean. Fix this.

Yeah, and check_modmap_change_slave *does* return a boolean; I see no
possibility for confusion here.

I saw that check_modmap_change returns -1 for BadValue and then checked
to make sure this odd value is fixed up in both
ProcXSetDeviceModifierMapping and ProcSetModifierMapping so that this
value doesn't get back to the client.

Reviewed-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
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