Re: "Modern C" and the X.Org software

[Jeremy Sequoia]

> On Dec 11, 2023, at 14:29, Alan Coopersmith  
> wrote:
> 
> I also added -std=gnu23 to my build flags, which found one more issue
> due to C23 defining "true" as an rvalue, not an lvalue:
> 
> Fix C23 build by renaming variable 'true'
> https://gitlab.freedesktop.org/xorg/util/imake/-/merge_requests/8


Hey Alan, this looks to be the wrong URL ^^

BadValue from X_OpenFont with some TrueType fonts

[Jeremy Sequoia]

Hi folks,

I'm trying to track down an issue reported against XQuartz related to fonts.  
I'm a bit out of my depth in this area, so I'm hoping to get some advice from 
others that know more about this than me.

   https://github.com/XQuartz/XQuartz/issues/216 


Essentially, folks are hitting BadValue from X_OpenFont when trying to use some 
fonts.  I've been able to reproduce this with XQuartz and macOS from about 4-5 
years ago, so it's not a new issue... but it'd be nice to track it down and fix 
it for folks.

Here's an example:

$ xlsfonts -fn '-*-monaco-*' 
-misc-monaco-medium-r-normal--0-0-0-0-p-0-adobe-standard
-misc-monaco-medium-r-normal--0-0-0-0-p-0-ascii-0
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso10646-1
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-1
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-10
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-13
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-15
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-16
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-2
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-3
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-4
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-5
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-9
-misc-monaco-medium-r-normal--0-0-0-0-p-0-koi8-e
-misc-monaco-medium-r-normal--0-0-0-0-p-0-koi8-r
-misc-monaco-medium-r-normal--0-0-0-0-p-0-koi8-ru
-misc-monaco-medium-r-normal--0-0-0-0-p-0-koi8-u
-misc-monaco-medium-r-normal--0-0-0-0-p-0-koi8-uni
-misc-monaco-medium-r-normal--0-0-0-0-p-0-microsoft-cp1252

$ xlsfonts -l -fn '-*-monaco-*'
DIR  MIN  MAX EXIST DFLT PROP ASC DESC NAME
-->0  255  some0   36  184 
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-1
-->0  255  some0   36  184 
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-2
-->0  255  some0   36  144 
-misc-monaco-medium-r-normal--0-0-0-0-p-0-iso8859-5

^^^ Where did al the others go... ?

$ xlsfonts -ll -fn '-*-monaco-*'
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
 Major opcode of failed request:  45 (X_OpenFont)
 Value in failed request:  0xa1
 Serial number of failed request:  9
 Current serial number in output stream:  10

^^^ 

Unfortunately, I'm having some troubles getting xscope working on darwin right 
now, but I was able to reproduce it on Ubuntu with Monaco.ttf 
(https://github.com/XQuartz/XQuartz/files/9024564/Monaco.ttf.gz) through xscope.

0.00: Client (pid 7136 xlsfonts) -->   12 bytes
  byte-order: LSB first
   major-version: 000b
   minor-version: 
0.00:   12452 bytes <-- X11 Server (pid 6304 
Xorg)
protocol-major-version: 000b
protocol-minor-version: 
  release-number: 00b74dc8
resource-id-base: 0200
resource-id-mask: 001f
  motion-buffer-size: 0100
image-byte-order: LSB first
bitmap-format-bit-order: LSB first
bitmap-format-scanline-unit: 20
bitmap-format-scanline-pad: 20
 min-keycode: 8 (^H)
 max-keycode: 255 (\377)
  vendor: "The X.Org 
 Foundation"
  pixmap-formats: (7)
   roots: (1)
0.00: Client (pid 7136 xlsfonts) -->   20 bytes
 REQUEST: QueryExtension
name: "BIG-REQUESTS"
0.00: 32 bytes <-- X11 Server (pid 6304 
Xorg)
 ..REPLY: QueryExtension
 present: True
major-opcode: 85
 first-event: 00
 first-error: 00
0.00: Client (pid 7136 xlsfonts) -->4 bytes
 REQUEST: BigreqRequest
   BIGREQREQUEST: BigreqEnable
0.00: 32 bytes <-- X11 Server (pid 6304 
Xorg)
 ..REPLY: BigreqReply
max-request-size: 003f
0.00: Client (pid 7136 xlsfonts) -->   44 bytes
 REQUEST: CreateGC
  graphic-context-id: GXC 0200
drawable: DWB 06e9
  value-mask: background
 

Re: xserver: Branch 'master' - 3 commits

[Jeremy Sequoia]

> On Jun 21, 2022, at 2:19 AM, Michel Dänzer  wrote:
> 
> On 2022-06-21 05:37, Jeremy Sequoia wrote:
>> I reverted
> 
> Thanks.
> 
> Note that "make dist" is still broken on server-22.1-branch: 
> https://gitlab.freedesktop.org/xorg/xserver/-/jobs/24330392 (I don't 
> personally care about this, but the 22.1 branch maintainer might :)

Done.  Sorry I missed that.  That’s what I get for jumping on the meson 
bandwagon.  I didn’t realize the autotools build was still there. ><

I’ll use the gitlab workflow for future changes to catch issues like this, 
thanks!

>> and created a pull request to track getting this in once the pipelines are 
>> updated:
>> 
>> https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/913 
> 
> I commented there how the CI failure could be solved.

Thanks.  Seems easy enough to start pulling at that thread...

>>> On Jun 20, 2022, at 17:41, Jeremy Sequoia >> <mailto:jerem...@apple.com>> wrote:
>>>> On Jun 20, 2022, at 02:09, Michel Dänzer >>> <mailto:michel.daen...@mailbox.org>> wrote:
>>>> 
>>>> [0] That said, if the Xquartz build could be tested as part of the GitLab 
>>>> CI pipeline, that could be useful for you as well.
>>> 
>>> Could you point me at documentation for setting that up?
> 
> I don't know of any documentation about how to do builds for macOS in GitLab 
> CI, which might be the main challenge here. I'd suggest joining the 
> #freedesktop channel on OFTC IRC and asking the gstreamer folks there how 
> they're doing it. Or maybe take a look at the macos job definitions in 
> https://gitlab.freedesktop.org/gstreamer/cerbero/-/blob/main/.gitlab-ci.yml .
> 
> FWIW, the general GitLab CI/CD documentation is at 
> https://docs.gitlab.com/ee/ci/ and the documentation for the CI templates 
> we're using at https://freedesktop.pages.freedesktop.org/ci-templates/ . I'm 
> afraid this may be overwhelming at first though, it certainly was for me. :)

Yeah, I’l definitely up to my neck in custom CI-foo for my day job as well =).

I’ll take a look!

> 
> 
> -- 
> Earthling Michel Dänzer|  https://redhat.com
> Libre software enthusiast  | Mesa and Xwayland developer

Re: xserver: Branch 'master' - 3 commits

[Jeremy Sequoia]

I reverted and created a pull request to track getting this in once the 
pipelines are updated:

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/913

Also, a plug for the PR I just put up to get Xorg and Xnest building again on 
darwin:

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/912

Thanks, and sorry for the noise.

> On Jun 20, 2022, at 17:41, Jeremy Sequoia  wrote:
> 
> Shoot, sorry about that.  Do you want me to revert it?  I figured the warning 
> meant the build wouldn't even work with older meson :/
> 
> Sent from my iPhone...
> 
>> On Jun 20, 2022, at 02:09, Michel Dänzer  wrote:
>> 
>> 
>> Hi Jeremy,
>> 
>> 
>> good to see you working on Xquartz again!
>> 
>> 
>> We are generally not pushing xserver changes directly to the main repository 
>> anymore, but using GitLab merge requests instead. While you are mostly free 
>> to ignore this for changes which affect Xquartz only[0], bumping the minimum 
>> meson version requirement does not affect only Xquartz. This change broke 
>> the GitLab CI pipeline on master & server-22.1-branch:
>> 
>> https://gitlab.freedesktop.org/xorg/xserver/-/pipelines/616828
>> https://gitlab.freedesktop.org/xorg/xserver/-/pipelines/616834 (Looks like 
>> another commit broke make dist as well)
>> 
>> Until this is resolved, it won't be possible to merge any GitLab MRs (which 
>> don't resolve the issue) to these branches.
>> 
>> 
>> [0] That said, if the Xquartz build could be tested as part of the GitLab CI 
>> pipeline, that could be useful for you as well.
> 
> Could you point me at documentation for setting that up?
> 
>>> On 2022-06-20 07:21, GitLab Mirror wrote:
>>> 
>>> commit 0a27f96d1d0e474b308be982fa7069d3ae0d9892
>>> Author: Jeremy Huddleston Sequoia 
>>> Date:   Sun Jun 19 22:18:16 2022 -0700
>>> 
>>>   meson: Bump requirement to meson-0.50.0
>>> 
>>>   WARNING: Project specifies a minimum meson_version '>= 0.47.0' but uses 
>>> features which were added in newer versions:
>>>* 0.50.0: {'install arg in configure_file'}
>>> 
>>>   Signed-off-by: Jeremy Huddleston Sequoia 
>>> 
>>> diff --git a/meson.build b/meson.build
>>> index db1d63f3e..7f9330107 100644
>>> --- a/meson.build
>>> +++ b/meson.build
>>> @@ -4,7 +4,7 @@ project('xserver', 'c',
>>>'c_std=gnu99',
>>>],
>>>version: '21.1.99.1',
>>> -meson_version: '>= 0.47.0',
>>> +meson_version: '>= 0.50.0',
>>> )
>>> release_date = '2021-07-05'
>>> 
>> 
>> 
>> -- 
>> Earthling Michel Dänzer|  https://redhat.com
>> Libre software enthusiast  | Mesa and Xwayland developer

Re: xserver: Branch 'master' - 3 commits

[Jeremy Sequoia]

Shoot, sorry about that.  Do you want me to revert it?  I figured the warning 
meant the build wouldn't even work with older meson :/

Sent from my iPhone...

> On Jun 20, 2022, at 02:09, Michel Dänzer  wrote:
> 
> 
> Hi Jeremy,
> 
> 
> good to see you working on Xquartz again!
> 
> 
> We are generally not pushing xserver changes directly to the main repository 
> anymore, but using GitLab merge requests instead. While you are mostly free 
> to ignore this for changes which affect Xquartz only[0], bumping the minimum 
> meson version requirement does not affect only Xquartz. This change broke the 
> GitLab CI pipeline on master & server-22.1-branch:
> 
> https://gitlab.freedesktop.org/xorg/xserver/-/pipelines/616828
> https://gitlab.freedesktop.org/xorg/xserver/-/pipelines/616834 (Looks like 
> another commit broke make dist as well)
> 
> Until this is resolved, it won't be possible to merge any GitLab MRs (which 
> don't resolve the issue) to these branches.
> 
> 
> [0] That said, if the Xquartz build could be tested as part of the GitLab CI 
> pipeline, that could be useful for you as well.

Could you point me at documentation for setting that up?

>> On 2022-06-20 07:21, GitLab Mirror wrote:
>> 
>> commit 0a27f96d1d0e474b308be982fa7069d3ae0d9892
>> Author: Jeremy Huddleston Sequoia 
>> Date:   Sun Jun 19 22:18:16 2022 -0700
>> 
>>meson: Bump requirement to meson-0.50.0
>> 
>>WARNING: Project specifies a minimum meson_version '>= 0.47.0' but uses 
>> features which were added in newer versions:
>> * 0.50.0: {'install arg in configure_file'}
>> 
>>Signed-off-by: Jeremy Huddleston Sequoia 
>> 
>> diff --git a/meson.build b/meson.build
>> index db1d63f3e..7f9330107 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -4,7 +4,7 @@ project('xserver', 'c',
>> 'c_std=gnu99',
>> ],
>> version: '21.1.99.1',
>> -meson_version: '>= 0.47.0',
>> +meson_version: '>= 0.50.0',
>> )
>> release_date = '2021-07-05'
>> 
> 
> 
> -- 
> Earthling Michel Dänzer|  https://redhat.com
> Libre software enthusiast  | Mesa and Xwayland developer

504 to gitlab.freedesktop.org

[Jeremy Sequoia]

Hey folks,

I was going to spend a little bit of time putting out an update to XQuartz to 
address a few bugs that I've been meaning to squash, but I'm having a bit of an 
issue pulling down sources.

Fetching via ssh://g...@gitlab.freedesktop.org is giving me Permission denied 
(publickey,keyboard-interactive).  I'm not sure if the latter is an infra issue 
or if the ssh key I have stored in my gitlab account are out of date (it's been 
about a year since I touched this).  Unfortunately, I can't seem to access 
https://gitlab.freedesktop.org to check as it's constantly presenting me a 504 
Gateway timeout.

Is anyone else able to pull sources via ssh://g...@gitlab.freedesktop.org right 
now?  Is someone looking into the 504 issue?

--Jeremy

Re: Repos to archive?

[Jeremy Sequoia]

Sent from my iPhone...

> On Nov 20, 2018, at 11:04, Adam Jackson  wrote:
> 
>> On Tue, 2018-11-20 at 09:34 -0800, Eric Anholt wrote:
>> Alan Coopersmith  writes:
>> 
>>> While iterating over all the /xorg/ repos to update their READMEs
>>> (which I think I've now finished - let me know if you spot one I missed),
>>> I noticed a few more to consider archiving:
>> 
>> I agree with your reasoning for all of these.
> 
> Almost all likewise. I've archived all of these except for libxcwm,
> it's both the only one with any issues filed (imported from bz) and I
> think in principle was part of some Xquartz rework that might still be
> relevant. Thanks for looking into this!

I’d really love for someone to pickup the libxcwm work as it is definitely 
relevant and needed to modernize XQuartz.  I haven’t looked at it for maybe 6+ 
years due to changing jobs within Apple, but it is still relevant.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:xserver] Use pthread_setname_np to set thread names if available

[Jeremy Sequoia]

Sent from my iPhone...

> On Oct 17, 2016, at 18:48, Alan Coopersmith  
> wrote:
> 
>> On 10/17/16 06:36 PM, Peter Hutterer wrote:
>>> On Sat, Sep 10, 2016 at 09:14:19PM -0700, Alan Coopersmith wrote:
>>> I have only tested this on Solaris, not MacOS or Linux, but since the
>>> similar code in glib works on both, hope this will too.
>> 
>> 
>> this broke a few scripts here, e.g. ps -C Xorg won't work anymore because
>> the program name is now MainThread. I understand why we'd want to label the
>> input thread but do we get any benefit out of labelling the main thread?
> 
> Oh, I didn't know it would do that on Linux - Solaris still shows the process
> name for the process, and the thread names only when looking at the threads.

On macOS, this also just changes the name of the thread, not the process.

IMO, it seems wrong that it would have such an effect on Linux.

> I just figured it was handy when libraries spawn their own threads, so we 
> could
> tell the difference between our thread and theirs, but if it's causing 
> problems,
> I don't think it's useful enough to force the issue and am okay seeing the 
> main
> thread name dropped.
> 
> -- 
>-Alan Coopersmith-  alan.coopersm...@oracle.com
> Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH x11proto] Fix typo __has_extenstion -> __has_extension

[Jeremy Sequoia]

Crap, my bad.  Sorry.

Reviewed-by: Jeremy Huddleston Sequoia 

Sent from my iPhone...

> On Sep 22, 2016, at 16:38, Keith Packard  wrote:
> 
> Signed-off-by: Keith Packard 
> ---
> Xfuncproto.h.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Xfuncproto.h.in b/Xfuncproto.h.in
> index 8715c9d..b88493d 100644
> --- a/Xfuncproto.h.in
> +++ b/Xfuncproto.h.in
> @@ -83,7 +83,7 @@ in this Software without prior written authorization from 
> The Open Group.
> # define __has_feature(x) 0/* Compatibility with non-clang compilers. */
> #endif
> #ifndef __has_extension
> -# define __has_extenstion(x) 0 /* Compatibility with non-clang compilers. */
> +# define __has_extension(x) 0  /* Compatibility with non-clang compilers. */
> #endif
> 
> /* Added in X11R6.9, so available in any version of modular xproto */
> -- 
> 2.9.3
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [ANNOUNCE] xorg-server 1.18.99.2

[Jeremy Sequoia]

Sent from my iPhone...

> On Sep 17, 2016, at 21:43, Keith Packard  wrote:
> 
> Jeremy Huddleston Sequoia  writes:
> 
>> [ Unknown signature status ]
>> 
>>> On Sep 16, 2016, at 13:57, Keith Packard  wrote:
>>> 
>>> 
>>> I think we're ready for RC1 at this point, but wanted to give people a
>>> chance to scream about "just one more API change" until tomorrow. Let me
>>> know if there's something I'm missing; if I don't hear anything, I'll be
>>> tagging RC1 in the morning.
>> 
>> IMO, we're not quite RC quality on master, so tagging it that way
>> feels a bit premature.
> 
> And I didn't, I just set it to 99.2, which is a post-1.18, but pre-RC1
> tag in our scheme (I think).
> 
>> ASan trips over a bunch of issues still.  I'd like to land the patches
>> that I sent out over the weekend that address memory corruption issues
>> if the server is started without any screens attached.  That issue was
>> made obvious due to the input thread changes which altered our
>> initialization order to reveal the issue.
> 
>> We should also address the use-after-free in CloseDownClient that I
>> discussed in https://bugs.freedesktop.org/show_bug.cgi?id=97770 and
>> figure out what's causing replies to get stuck unsent in the first
>> place (cf 9/11: Re: XLoadQueryFont() not returning with recent xserver
>> master).
> 
> RC1 means we've got the feature set we want, but there may still be
> bugs.
> 
> Do you have any features you'd like to land for 1.19 which haven't made
> it yet? Do you think there are bugs sufficient to jeopardize the 1.19
> schedule? 

No features on my end.  I've basically just been keeping XQuartz in maintenance 
mode, so no qualms with the API or Feature Freeze.  I'd just like to try to get 
some of these bugs that I noticed squashed before the rc1 tag if possible.

> 
> -- 
> -keith
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:xorg-docs 3/4] X.man: document protocol/ syntax in display string

[Jeremy Sequoia]

Sent from my iPhone...

> On Oct 28, 2015, at 10:01, Alan Coopersmith  
> wrote:
> 
>> On 10/28/15 07:46 AM, Jeremy Huddleston Sequoia wrote:
>> Should we also mention the extension that was added for launchd support 
>> where we DISPLAY=[.]
> 
> That sounds like a good followup patch for you to submit, since I didn't even
> remember that existed, much less know how to describe it.

Yeah.  I was more posing the question of "should we mention it or not?" rather 
than suggesting you ammend your commit.

> -- 
>-Alan Coopersmith-  alan.coopersm...@oracle.com
> Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/1] list: Use offsetof() to determine member offsets within a structure

[Jeremy Sequoia]

On 08/28/12, Peter Hutterer  peter.hutte...@who-t.net wrote:

  -#define __container_of(ptr, sample, member)
  \
  -    (void *)((char *)(ptr) \
  - - ((char *)(sample)-member - (char *)(sample)))
  +#define __container_of(ptr, sample, member)\
  +    container_of(ptr, typeof(*sample), member)
 
 typeof is a gcc extension/c99 and I don't think we support that yet, do we?
 
I thought we were expecting C99 nowadays.  CCing Alan since I think he knows 
the answer to that and can chime in re: SunCC.


In any event, typeof is in *a* standard whereas the previous implementation is 
undefined (and can lead to crashes on startup).  I'd vote for doing something 
that is in a 13 year old standard over something that has undefined behavior.


If there is concern over this breaking gcc-3.2 or some ancient compiler, I'm 
happy to update it to use $ifdef guarding.  At minimum, I'd like to get this 
changed for __clang__ before 1.13 ships.


--Jeremy

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel