Re: [E-devel] Eterm amd64 / 64 bit fix
On Tuesday, 26 April 2005, at 17:00:36 (-0600), Tres Melton wrote: > This was actually my patch but vapier (Mike Frysinger) submitted it > through Gentoo for me. Don't worry; you were properly credited in the ChangeLog. > It is not a 64/32 bit thing so much as it is a 32 bits/pixel thing. > I'm not as familiar with the code as I'd like to be but this code > snippet seems hard coded for 32bpp. Has this been tried using other > color depths? If icon_data is a pointer to a 16bpp image and we > divide it by CARD32 won't the nelements parameter be half of what it > should be? This has nothing to do with the depth of the display. icon_data is defined in icon.h and is a 32bpp ARGB array of Imlib2 image data. This is true irrespective of the Xdepth setting. Further, the format for the property is set to 32-bit values, so it will be properly handled on 64-bit systems (assuming the WM in question does it right). Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "Would the congregation please note that the bowl at the back of the church labeled 'For the Sick' is for monetary donations only." -- Churchdown Parish Magazine, Gloucestershire, England --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eterm amd64 / 64 bit fix
This was actually my patch but vapier (Mike Frysinger) submitted it through Gentoo for me. It is not a 64/32 bit thing so much as it is a 32 bits/pixel thing. I'm not as familiar with the code as I'd like to be but this code snippet seems hard coded for 32bpp. Has this been tried using other color depths? If icon_data is a pointer to a 16bpp image and we divide it by CARD32 won't the nelements parameter be half of what it should be? Just asking. :-) On Tue, 2005-04-26 at 13:26 -0400, Michael Jennings wrote: > On Thursday, 21 April 2005, at 18:17:26 (-0400), > Mike Frysinger wrote: > > > the patch i committed applied against src/command.h and that's it > > ... i was just checking other things to see if similar fixes could > > be used elsewhere and i noticed pixmap.c ... so i'm asking for > > someone else to verify that this code is 32bit/64bit clean since i > > know nothing of X functions > > Your patch did not change the definition of CARD32. It is still 32 > bits. Rather, it changed the structure for MWM hints to use CARD64 > and INT64 instead of CARD32 and INT32. > > Michael > -- Tres --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eterm amd64 / 64 bit fix
On Thursday, 21 April 2005, at 18:17:26 (-0400), Mike Frysinger wrote: > the patch i committed applied against src/command.h and that's it > ... i was just checking other things to see if similar fixes could > be used elsewhere and i noticed pixmap.c ... so i'm asking for > someone else to verify that this code is 32bit/64bit clean since i > know nothing of X functions Your patch did not change the definition of CARD32. It is still 32 bits. Rather, it changed the structure for MWM hints to use CARD64 and INT64 instead of CARD32 and INT32. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "I feel wonderful because I see the love light in your eyes, and the wonder of it all is that you just don't realize how much I love you." -- Eric Clapton, "Wonderful Tonight" --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eterm amd64 / 64 bit fix
On Thursday 21 April 2005 05:08 pm, Michael Jennings wrote: > On Wednesday, 20 April 2005, at 19:05:18 (-0400), > Mike Frysinger wrote: > > windows.c and screen.c look fine, but pixmap.c looks a little fishy: > > XChangeProperty(Xdisplay, TermWin.parent, > > props[PROP_EWMH_ICON], XA_CARDINAL, 32, PropModeReplace, > > (unsigned char *) icon_data, sizeof(icon_data) / > > sizeof(CARD32)); i dont really know anything about X functions, so you > > guys would know whether this is fine too ... > > The fix went into a header file, though, right? (I'm on a hella slow > connection right now, so I can't check myself.) :( the patch i committed applied against src/command.h and that's it ... i was just checking other things to see if similar fixes could be used elsewhere and i noticed pixmap.c ... so i'm asking for someone else to verify that this code is 32bit/64bit clean since i know nothing of X functions > On Wednesday, 20 April 2005, at 21:47:28 (-0400), > Mike Frysinger wrote: > > Roland B=E4r submitted this patch: > > http://bugs.gentoo.org/attachment.cgi?id=3D52947&action=3Dview > > via this bug: > > http://bugs.gentoo.org/show_bug.cgi?id=3D84520 > > > > in an attempt to get the code working for amd64 ... patch is not ok as > > is, = but=20 > > if the x86-specific code is wrapped in #ifdef __i386__ and then amd64 > > code = is=20 > > wrapped in #ifdef __x86_64__, this shoud be ok to commit ? > > My policy: Test it on i386. If it doesn't break that, commit it, > because that's all I have to test with and can't yell at you if it > Works For Me(tm). *grin* > > Your approach sounds fine. I always watch commits to make sure the > patches that go in are acceptable, so don't worry about "sneaking one > past the goalie." ok, i'll clean it up and commit it -mike --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eterm amd64 / 64 bit fix
On Wednesday, 20 April 2005, at 19:05:18 (-0400), Mike Frysinger wrote: > rather get permission first than have you yell at me later ;) ... committed As a rule, I don't yell at people for committing small, clean patches that fix bugs. Particularly bugs I can't test, like those on 64-bit systems. > along the same lines, a quick grep for CARD32 shows: > src/pixmap.c > src/screen.c > src/windows.c > > windows.c and screen.c look fine, but pixmap.c looks a little fishy: > XChangeProperty(Xdisplay, TermWin.parent, > props[PROP_EWMH_ICON], XA_CARDINAL, 32, PropModeReplace, > (unsigned char *) icon_data, sizeof(icon_data) / sizeof(CARD32)); > i dont really know anything about X functions, so you guys would know whether > this is fine too ... The fix went into a header file, though, right? (I'm on a hella slow connection right now, so I can't check myself.) :( On Wednesday, 20 April 2005, at 21:47:28 (-0400), Mike Frysinger wrote: > Roland B=E4r submitted this patch: > http://bugs.gentoo.org/attachment.cgi?id=3D52947&action=3Dview > via this bug: > http://bugs.gentoo.org/show_bug.cgi?id=3D84520 > > in an attempt to get the code working for amd64 ... patch is not ok as is, = > but=20 > if the x86-specific code is wrapped in #ifdef __i386__ and then amd64 code = > is=20 > wrapped in #ifdef __x86_64__, this shoud be ok to commit ? My policy: Test it on i386. If it doesn't break that, commit it, because that's all I have to test with and can't yell at you if it Works For Me(tm). *grin* Your approach sounds fine. I always watch commits to make sure the patches that go in are acceptable, so don't worry about "sneaking one past the goalie." Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "A leader takes people where they want to go. A great leader takes people where they don't necessarily want to go, but ought to be." -- Rosalynn Carter --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eterm amd64 / 64 bit fix
On Wednesday 20 April 2005 04:24 pm, Michael Jennings wrote: > On Wednesday, 20 April 2005, at 15:45:28 (-0400), > > Mike Frysinger wrote: > > users were having issues turning off eterm borders on amd64: > > http://bugs.gentoo.org/show_bug.cgi?id=76324 > > > > so a user proposed a patch which worked for him: > > http://bugs.gentoo.org/attachment.cgi?id=56738 > > > > what do you think mej ? > > I think you should commit it now that you've been given access. :-) rather get permission first than have you yell at me later ;) ... committed along the same lines, a quick grep for CARD32 shows: src/pixmap.c src/screen.c src/windows.c windows.c and screen.c look fine, but pixmap.c looks a little fishy: XChangeProperty(Xdisplay, TermWin.parent, props[PROP_EWMH_ICON], XA_CARDINAL, 32, PropModeReplace, (unsigned char *) icon_data, sizeof(icon_data) / sizeof(CARD32)); i dont really know anything about X functions, so you guys would know whether this is fine too ... -mike --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eterm amd64 / 64 bit fix
Michael Jennings wrote: On Wednesday, 20 April 2005, at 15:45:28 (-0400), Mike Frysinger wrote: users were having issues turning off eterm borders on amd64: http://bugs.gentoo.org/show_bug.cgi?id=76324 so a user proposed a patch which worked for him: http://bugs.gentoo.org/attachment.cgi?id=56738 what do you think mej ? I think you should commit it now that you've been given access. :-) Michael Hello ! This patch works great, but strangely, it works even without it under e17... :s (Gentoo amd64, e16 and e17) Cheers. ilLogict --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eterm amd64 / 64 bit fix
On Wednesday, 20 April 2005, at 15:45:28 (-0400), Mike Frysinger wrote: > users were having issues turning off eterm borders on amd64: > http://bugs.gentoo.org/show_bug.cgi?id=76324 > > so a user proposed a patch which worked for him: > http://bugs.gentoo.org/attachment.cgi?id=56738 > > what do you think mej ? I think you should commit it now that you've been given access. :-) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "Shh! Be vewy quiet, I'm hunting wuntime errors!" -- Not Elmer Fudd --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Eterm amd64 / 64 bit fix
users were having issues turning off eterm borders on amd64: http://bugs.gentoo.org/show_bug.cgi?id=76324 so a user proposed a patch which worked for him: http://bugs.gentoo.org/attachment.cgi?id=56738 what do you think mej ? -mike --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
