Jeremy Huddleston Sequoia writes:
> I've been running XQuartz with ASan+UBSan to try to catch some issues
> some users have reported, and I stumbled across something below GLUT
> (specifically, freeglut 2.8.1), which does:
>
> XConfigureEvent fakeEvent = {0};
> ...
>
Matthieu Herrb writes:
> On Thu, Nov 24, 2022 at 06:35:07PM +0800, Po Lu wrote:
>> Matthieu Herrb writes:
>>
>> > Not all systems supported by X.Org have timerfd. So please make this
>> > feàture conditional it's presence,
>>
>>
Matthieu Herrb writes:
> Not all systems supported by X.Org have timerfd. So please make this
> feàture conditional it's presence,
Sure, but isn't modesetting recent-Linux-only?
Here is a change to xf86-video-modesetting that should let PresentPixmap
copy within the vertical blanking period, as opposed to immediately
after. I'm not sure whether or not it's ok to depend on timerfd, and to
also send the PresentCompleteNotify event at vblank start time (as
opposed to the
Matthieu Herrb writes:
> My french input method has eaten the URL. here the unmangled one:
>
> https://marc.info/?l=openbsd-tech=166742060513284=2
My crystal ball says it's probably that before XInitThreads was called,
pthread stubs somehow found their way into the executable image.
If you
On November 2, 2022 1:25:06 AM GMT+08:00, Adam Jackson wrote:
>On Mon, Oct 31, 2022 at 8:46 PM Po Lu wrote:
>Again, I proposed a workaround that preserves the thread-safety guarantee I
>need, and wrote the patch implementing it. Sure would be nice if someone
>tested it.
I did
Carsten Haitzler writes:
> Sorry - but no. Motif being non-threadsafe and Xlib being threadsafe or not
> are
> different matters. A higher level lib that is not threadsafe makes use of a
> lower level one (xlib) and the latter can be threadsafe if desired.
Being thread-safe is one thing.
Carsten Haitzler writes:
> no it doesn't. the contract is simply to not use motif from multiple threads.
> it has nothing to do with xlib itself becoming threadsafe. i think the PR/MR
> for xlib has all the details you want listed in it.
No, it doesn't, see below:
> it has nothing to do with
Adam Jackson writes:
> Because XInitThreads only works if it is called before XOpenDisplay.
So why not fix that?
I think the simple fix would be to call _XInitDisplayLock in
XGetXCBConnection.
Carsten Haitzler writes:
> using motif and using xlib are different things. you are still free to use
> xlib
> separately to motif and thus use it from multiple threads... as long as you
> use
> motif and only motif from a single thread, you agree to the non-threadsafe
> contract.
Which Xlib
Keith Packard writes:
> As currently described, the fix is untested. I'd encourage you to apply
> it and see if it works; that would at least provide some evidence that
> it helps.
It helps for Motif programs.
But what about other X extensions that may want to run callbacks inside
LockDisplay?
On October 31, 2022 7:08:50 AM GMT+08:00, Alan Coopersmith
wrote:
>On 10/29/22 19:00, Po Lu wrote:
>> Motif assumes that you can call functions that lock the display inside
>> XCheckIfEvent as it never calls XInitThreads itself. It also never uses
>> threads.
>
&
Motif assumes that you can call functions that lock the display inside
XCheckIfEvent as it never calls XInitThreads itself. It also never uses
threads.
Please revert the following change to Xlib:
commit afcdb6fb0045c6186aa83d9298f327a7ec1b2cb9
Author: Adam Jackson
Date: Tue Mar 22 18:24:29
Is there documentation anywhere on glamor internals? And if there
isn't, does anyone on this list know how glamor decides whether or not
to upload pixmap contents to a texture (and/or fbo) when used as the
source Picture to a CompositePictures request?
This might end up being an X/Y question, so
attention. I hope that isn't a problem.
If these changes look good, I'd like for them to be installed. If
they're not, please tell me why, and I will try my best to fix them.
Thanks in advance.
>From 8c72d0297c1993cb2f8f121cd5bc2f5d7702bfd9 Mon Sep 17 00:00:00 2001
From: Po Lu
Date: Wed, 19
Keith Packard writes:
> I got started creating a 'semi-automatic compositing' design where the
> compositing manager could tell the X server "Hey, just composite this
> window to the screen in the 'obvious' way and don't bother me with the
> details".
Wouldn't that just be RedirectWindow with
Michel Dänzer writes:
> I'm thinking of this kind of scenario with a direct rendering compositor:
>
> 1. Compositor retrieves window pixmap, creates OpenGL texture object for it.
> 2. Client sends PresentPixmap request, which results in replacing the window
> pixmap.
> 3. Client starts drawing
Michel Dänzer writes:
> You don't need to do anything special. The effect of PresentPixmap is
> essentially the same as XCopyArea as far as the destination window
> contents are concerned, regardless of how the presentation is
> effectively performed.
Thanks.
> The problem with this is that
Po Lu writes:
> Doesn't this leak found by Valgrind sound like a bug?
> For reference, here's how I'm calling XRegisterIMInstantiateCallback:
>
> XSetLocaleModifiers ("");
> XRegisterIMInstantiateCallback (compositor.display,
>
Doesn't this leak found by Valgrind sound like a bug?
For reference, here's how I'm calling XRegisterIMInstantiateCallback:
XSetLocaleModifiers ("");
XRegisterIMInstantiateCallback (compositor.display,
XrmGetDatabase (compositor.display),
Does pixman guarantee that pixman_region16_rectangles will return
rectangles in the same X/Y banded format used by the X server?
Emacs uses the PictStandardA4 picture format to display certain kinds of
images. A "painfully slow" software fallback is not a problem, since
the important thing is for the picture to be displayed in the first
place.
So there are "users in the wild", and in any case the X.Org server
should hold
Hello. I have recently been working on a Wayland compositor that runs
on X, and have several questions about the presentation extension.
My compositor utilizes XRender for compositing subsurfaces with the
contents of a toplevel window, and _NET_WM_SYNC_REQUEST to handle frame
synchronization.
Thomas Dickey writes:
> looks okay reading the library code (src/xlibi18n/XDefaultIMIF.c, _CloseIM).
>
> xterm doesn't free that 'xim' value (and the XCloseIM manual page doesn't
> say who's responsible for that -- though it's possible that some other
> application developer read the library
Po Lu writes:
> ==67186== 408 bytes in 1 blocks are definitely lost in loss record 272 of 344
> ==67186==at 0x484A464: calloc (vg_replace_malloc.c:1328)
> ==67186==by 0x490935F: _XimOpenIM (in /usr/lib64/libX11.so.6.4.0)
> ==67186==by 0x490F386: _XimRegisterIMInstant
Alan Coopersmith writes:
> Unfortunately, there is no one left reviewing Xlib patches who knows how
> input methods work or what might be a breaking change, or who could write
> documentation of such changes. We'd love for someone to step up and
> take on such work.
How about this?
diff --git
(Resending after subscribing as the list moderator seems to be
unresponsive.)
Doesn't this leak found by Valgrind from libX11 sound like a bug? For
reference, here's how I'm calling XRegisterIMInstantiateCallback:
XSetLocaleModifiers ("");
XRegisterIMInstantiateCallback (compositor.display,
Keith Packard writes:
> Maybe something like this?
That would work, yes. Thanks.
Alan Coopersmith writes:
> Thanks - while gitlab is our preferred method, when that's not possible,
> we prefer using the xorg-devel mailing list (cc'ed) instead of trying to
> guess which individual developer to contact.
Thanks for explaining. I thought xorg-devel was shut down and replaced
29 matches
Mail list logo
