Bug 71110

Summary: xorg_driver.c:1030:2: error: too many arguments to function ‘DamageUnregister’
Product: Mesa Reporter: Vinson Lee <vlee>
Component: OtherAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact:
Severity: blocker    
Priority: medium CC: ajax, eric, mgorny
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: st/xorg: handle updates to DamageUnregister API

Description Vinson Lee 2013-11-01 00:33:58 UTC
mesa: 723f047a3bc21b536d27ab1c0d6cc82f93002648 (master)
xorg-x11-server-devel: xorg-x11-server-devel-1.14.99.3-1.20131021.fc21.x86_64

$ scons
[...]
  Compiling src/gallium/state_trackers/xorg/xorg_driver.c ...
src/gallium/state_trackers/xorg/xorg_driver.c: In function ‘drv_pre_init’:
src/gallium/state_trackers/xorg/xorg_driver.c:352:23: warning: variable ‘xf86_config’ set but not used [-Wunused-but-set-variable]
     xf86CrtcConfigPtr xf86_config;
                       ^
src/gallium/state_trackers/xorg/xorg_driver.c: In function ‘drv_close_screen’:
src/gallium/state_trackers/xorg/xorg_driver.c:1030:2: warning: passing argument 1 of ‘DamageUnregister’ from incompatible pointer type [enabled by default]
  DamageUnregister(&pScreen->GetScreenPixmap(pScreen)->drawable, ms->damage);
  ^
In file included from /usr/include/xorg/pixmapstr.h:53:0,
                 from /usr/include/xorg/xf86str.h:40,
                 from /usr/include/xorg/xf86.h:44,
                 from src/gallium/state_trackers/xorg/xorg_driver.c:33:
/usr/include/xorg/damage.h:77:2: note: expected ‘DamagePtr’ but argument is of type ‘struct DrawableRec *’
  DamageUnregister(DamagePtr pDamage);
  ^
src/gallium/state_trackers/xorg/xorg_driver.c:1030:2: error: too many arguments to function ‘DamageUnregister’
  DamageUnregister(&pScreen->GetScreenPixmap(pScreen)->drawable, ms->damage);
  ^
In file included from /usr/include/xorg/pixmapstr.h:53:0,
                 from /usr/include/xorg/xf86str.h:40,
                 from /usr/include/xorg/xf86.h:44,
                 from src/gallium/state_trackers/xorg/xorg_driver.c:33:
/usr/include/xorg/damage.h:77:2: note: declared here
  DamageUnregister(DamagePtr pDamage);
  ^
Comment 1 Vinson Lee 2013-11-01 00:59:19 UTC
commit d08966227e7d567df8d26eebc80f35f886e59a4a
Author: Adam Jackson <ajax@redhat.com>
Date:   Mon Aug 26 14:03:51 2013 -0400

    damage: Simplify DamageUnregister
    
    You can only register one drawable on a given damage, so there's no
    reason to require the caller to specify the drawable, the damage is
    enough.  The implementation would do something fairly horrible if you
    _did_ pass mismatched drawable and damage, so let's avoid the problem
    entirely.
    
    v2: Simplify xf86RotateDestroy even more [anholt]
    
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Adam Jackson <ajax@redhat.com>
Comment 2 Emil Velikov 2013-11-01 16:36:22 UTC
*** Bug 70403 has been marked as a duplicate of this bug. ***
Comment 3 Emil Velikov 2013-11-01 17:01:37 UTC
Created attachment 88493 [details] [review]
st/xorg: handle updates to DamageUnregister API

There are multiple ways we can handle this but I suspect that using consistent approach with all users would be preferred.

Vinson/Michał can you give this patch a try?
Thanks
Comment 4 Vinson Lee 2013-11-03 22:37:36 UTC
attachment 88493 [details] [review] fixes the build for me.

Tested-by: Vinson Lee <vlee@freedesktop.org>
Comment 5 Emil Velikov 2013-11-04 19:52:02 UTC
Pushed to master, thanks for testing Vinson.

commit 0a2bdbb76f9fecf34c6b5fb39b60fda745440e4f
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date:   Fri Nov 1 16:44:10 2013 +0000

    st/xorg: handle updates to DamageUnregister API

    xserver 1.14.99.2 simplified the DamageUnregister API, by
    dropping the drawable argument.
    Follow xf86-video-intel and xf86-video-vmware approach and
    handle the new API by checking XORG_VERSION_CURRENT.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.