Den 23 okt. 2016 14:36 skrev "Dominik Vogt" <dominik.v...@gmx.de>:
>
> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote:
> > On Sat, Oct 22, 2016 at 23:29 (+0100), Thomas Adam wrote:
> >
> > > On Sat, Oct 22, 2016 at 07:26:50PM -0300, zli...@ns.sympatico.ca
wrote:
> > >> On Sun, Jul 17, 2016 at 15:08 (+0100), Thomas Adam wrote:
> >
> > >>> On Sun, Jul 17, 2016 at 08:38:10AM -0300, zli...@ns.sympatico.ca
wrote:
> > >>>> On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote:
> >
> > >>>>> On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca
wrote:
> > >>>>>> I recently upgraded a computer from Slackware64 14.1 to 14.2,
which
> > >>>>>> bumped by fvwm version from 2.6.5 to 2.6.6.
> >
> > >>>>>> With the new system, when I ask Adobe reader 9.5.5 to go
full-screen,
> > >>>>>> I get a window with no decorations, but it only occupies about
3/4 of
> > >>>>>> the screen, off to the lower right.
>
> I've found the problem but I don't know how to fix it in a proper,
> i.e. portable way. In FEvent.c we have this function
>
> void fev_sanitise_configure_request(XConfigureRequestEvent *cr)
> {
> if (cr->value_mask & CWX)
> {
> cr->x = (((int)cr->x) & 0xffff);
> }
> ...
> if (cr->value_mask & CWHeight)
> {
> cr->height = (((unsigned int)cr->height) &
0xffff);
> }
> ...
> }
>
> This tries to deal with an inconsistency between the X protocol
> and the Xlib structures: In the X protocol, in the
> ConfirureWindow request, X and Y are signed "INT16" quantities and
> WIDTH and HEIGT are unsigned "CARD16" quantities, while in the
> Xlib structures they are "int" or "unsigned int".
>
> The code tries to cut off the excess bits from X and Y and does it
> wrong. With 32-bit integers, if cr->x is -1:
>
> ((int)-1) & 0xffff = 0xffffffff & 0xffff
> = 0xffff
> = 65535
>
> I'm not sure how to fix this. The easiest approach would be to
> cast these values to int16_t or uint16_t from stdint.h, but I
> vaguely remember there are some portability issues with the
> inttypes.s/stdint.h headers.
Instead of setting the excess bits to 0 we need to set them to 1 for the
negative case.
What about
if (cr->x & 0x8000)
{
cr->x = (((int)-1) ^ 0x7fff) | (((int)cr->x) & 0x7fff);
}
else
{
cr->x = (((int)cr->x) & 0xffff);
}
The negative case could be simplified to
(((int)-1) ^ 0x7fff) | ((int)cr->x)
Or
((int)-1)<<16|((int)cr->x)
>
> Ciao
>
> Dominik ^_^ ^_^
>
> --
>
> Dominik Vogt
>
