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

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

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/ <mej@...>
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

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

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/ <mej@...>
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"

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

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/ <mej@...>
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

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details