| Summary: | xcompmgr doesnt work on my ppc64 of gentoo 2004.2 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Yang Dehua <yangdh> | ||||||||||
| Component: | App/xcompmgr | Assignee: | Xorg Project Team <xorg-team> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||
| Severity: | blocker | ||||||||||||
| Priority: | high | CC: | pip, rene | ||||||||||
| Version: | unspecified | ||||||||||||
| Hardware: | PowerPC | ||||||||||||
| OS: | Linux (All) | ||||||||||||
| Whiteboard: | |||||||||||||
| i915 platform: | i915 features: | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Yang Dehua
2004-09-20 03:55:14 UTC
in the future, please attach large files like the X log or config file as attachments to the bug, rather than pasting them in as a comment. what xcompmgr version are you using? the one in portage is fairly old; could you grab a fresh version from CVS and try again? I am sorry for the inconvenience while I didnt know how to attach a file. Yes, I downloaded the latest version from the CVS site(tarball) and did the following: 1. uncompress the gz file 2. Execute sh autogen.sh in dir xcompmgr. The process finished with error of "automake requires AM_CONFIG_HEADER, not AC_CONFIG_HEADER", but related files are generated. 3.Execute ./configure 4.Execute make 5.Execute ./xcompmgr The things happened as I reported. Created attachment 1694 [details]
screenshot.png
I can confirm this behaviour. I'm running 6.8.1.902 and xcompmgr is 1.1.1. This
screenshot shows, what I get, when I run "xcompmgr -c".
Please tell us, what information you need, to fix this problem.
Composite extension loads by the way without any errors.
Is xcompmgr built as a 64 bits binary ? What if you build it as a 32 bits binary ? I don't remember any problem except slowness the last time I tried on the G5 but it was a 32 bits X and a 32 bits xcompmgr Yes, I built it as 64-bit program. I am afraid the 32-bit xcompmgr cann't be executed under my 64-bit system. I'll try very soon. Thank you. xcompmgr doesn't compile under my gentoo ppc64 linux. Same here, nv driver ppc64, I guess it is a 64bit bigendian bug or so somewhere, since the same version works on x86-64. Hi, I tracked it down to defect B32 defines for at leat ppc64.
/extensions/compositeproto.h defines:
Window window B32;
Pixmap pixmap B32;
But on ppc B32 is not set, because int is sized 32 but long is 64 bit.
Window and Pixmap are both long:
typedef unsigned long XID;
typedef XID Window;
typedef XID Pixmap;
and B32 only defined for, word == int == 64:
#ifdef WORD64
typedef long INT64;
typedef unsigned long CARD64;
#define B32 :32
#define B16 :16
I lack historic X decisions to decide whether to just define B32 to :32 in this
case as well or if the underlying XID type should be changed and so on.
Anyone?
Created attachment 4543 [details] [review] Proposed fix. See proposed patch to set B16 / B32 for INT64 or LONG64. Hm, the proposed patch does not work globally, since some code here and there does want to take the address of those B* marked members. Created attachment 4569 [details] [review] My current patch that does not cause regressions like the B32 one ... My current patch that survives a system build on ppc64, but garrison reports runtime regressions due to XRead32 with some keyboard symbols on x86-64. Created attachment 4574 [details] [review] Final least invasive fix. The last patch showed some breakage due to gtk+, qt and kdelibs even assuming Window Pixmap and friends are long (what the heck?) - thus here goes the least invasive patch possive, extending the clutch already there in the file. Btw., on x86-64 the structure is miss-sized as well, it only accidently works due to little-endianess ... the Pixmap member also needs to be undefined at the end of compositeproto.h, to avoid redefinition warnings later on. added to compositeproto-0.3.1, thanks! |
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.