GNU bug report logs - #69762
X11 versions of Emacs 29 on sparc fail at startup

Previous Next

Package: emacs;

Reported by: ali_gnu2 <at> emvision.com

Date: Tue, 12 Mar 2024 20:38:02 UTC

Severity: normal

Done: Po Lu <luangruo <at> yahoo.com>

Bug is archived. No further changes may be made.

Full log


Message #56 received at 69762 <at> debbugs.gnu.org (full text, mbox):

From: Ali Bahrami <ali_gnu2 <at> emvision.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 69762 <at> debbugs.gnu.org
Subject: Re: bug#69762: X11 versions of Emacs 29 on sparc fail at startup
Date: Sat, 16 Mar 2024 19:13:34 -0600
On 3/16/24 12:28 AM, Po Lu wrote:
> Ali Bahrami <ali_gnu2 <at> emvision.com> writes:
>> With that in place, Lucid emacs starts, and runs normally.
>> This is clearly not a proper fix, but it is an effective
>> workaround, and presumably, no worse that using emacs 28.2,
>> which completely lacks sync fence support.
>>
>> I wonder if we might be looking at a problem with the
>> sync fence extension on sparc?
> 
> That's more than likely, yes, though one wonders why Emacs is the first
> program to call attention to this problem.  The only role of the
> drawable parameter to SyncCreateFence is as a reference to its screen,
> which is completely defeated if not even the screen's root window is
> deemed valid.

It's a good question, and I don't know the answer.
However, it's worth noting that it's been 20 years
since sparc machines came in desktop form, with a
display, so the number of people running X11 clients
on them likely isn't large. I myself usually use the
plain tty version in those contexts.

> 
>> Although I now have usable way around the issue, I'm willing
>> to continue with any experiments you want to try. Let me
>> know...
> 
> I don't think such a drastic measure is necessary under the
> circumstances.  We should (please test) put this down as a bug in the
> X.Org server and install an error trap around SyncCreateFence requests,
> thus:

> Scratch that,
>
> diff --git a/src/xterm.c b/src/xterm.c
> index c8a43785564..2358918ac5b 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -7292,6 +7292,7 @@ x_sync_init_fences (struct frame *f)
>   	  && dpyinfo->xsync_minor < 1))
>       return;
>
> +  x_ignore_errors_for_next_request (dpyinfo, 0);
>     output->sync_fences[0]
>       = XSyncCreateFence (FRAME_X_DISPLAY (f),
>   			/* The drawable given below is only used to
> @@ -7303,6 +7304,7 @@ x_sync_init_fences (struct frame *f)
>       = XSyncCreateFence (FRAME_X_DISPLAY (f),
>   			FRAME_X_WINDOW (f),
>   			False);
> +  x_stop_ignoring_errors (dpyinfo);
>
>     XChangeProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
>   		   dpyinfo->Xatom_net_wm_sync_fences, XA_CARDINAL,

The x_ignore_errors_for_next_request() in 29.2 only
takes the dpyinfo argument. I dropped the second argument
from this patch, applied it, and it works. We could go with this,
rather than my

    #ifdef __sparc
	return
    #endif

construct. It probably amounts to the same thing,
except that should a fixed XSyncCreateFence() come
along, this version would start using it.

Thanks!

- Ali







This bug report was last modified 1 year and 45 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.