Re: libinput TabletToolAreaRatio pins cursor to 0,0

Hi Edmund, Please file a bug against the xorg libinput driver here: https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/ This feature is implemented in that driver so any bug will be in that code. Description is good enough, you can copy/paste that in there but it'll be easier to hand

Re: buillding error xorg-server 21.1.4

On 11/1/24 03:50, Fungal-net wrote: Thank you very much, the patch worked. Initially I misinterpreted that you were still working on more patches. I assume this fix will be included in >= 21.1.15 I was working on another patch that I found was needed to build with IPv6 disabled on Solaris -

Re: buillding error xorg-server 21.1.4

On 10/30/24 12:28, Fungal-net wrote: I get the following error trying to build version 21.1.4 same build dependencies used for 21.1.3 (4/13/24) but different versions gcc 14.2.1+r134 glibc 2.40+r16 binutils 2.43+r4 libtool 2.5.3 arch linux like system without systemd ../xorg-server/os/access.c:

Re: buillding error xorg-server 21.1.4

On 10/30/24 10:52, Fungal-net wrote: I get the following error trying to build version 21.1.4 same build dependencies used for 21.1.3 (4/13/24) but different versions gcc 14.2.1+r134 glibc 2.40+r16 binutils 2.43+r4 libtool 2.5.3 arch linux like system without systemd ../xorg-server/os/access.

Re: buillding error xorg-server 21.1.4

On 10/30/24 05:38, Fungal-net wrote: I get the following error trying to build version 21.1.4 same build dependencies used for 21.1.3 (4/13/24) but different versions gcc 14.2.1+r134 glibc 2.40+r16 binutils 2.43+r4 libtool 2.5.3 arch linux like system without systemd ../xorg-server/os/access.

Re: AW: XORG_CHECK_MALLOC_ZERO: stop testing malloc, assume the worst

On Tue, Oct 29, 2024 at 09:13:57AM -0700, Alan Coopersmith wrote: > On 10/29/24 04:29, Walter Harms wrote: > > hello, > > if i rember correctly there is a whole wrapper for malloc in libX11. > > It's a pretty thin wrapper - just a #define which varies depending on the > setting of XORG_CHECK_MALLO

Re: AW: XORG_CHECK_MALLOC_ZERO: stop testing malloc, assume the worst

On 10/29/24 04:29, Walter Harms wrote: hello, if i rember correctly there is a whole wrapper for malloc in libX11. It's a pretty thin wrapper - just a #define which varies depending on the setting of XORG_CHECK_MALLOC_ZERO: https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/libX11-1.8.10/in

Re: XORG_CHECK_MALLOC_ZERO: stop testing malloc, assume the worst

> It's been sitting in gitlab for 2 weeks without comment - I figured I'd > give a larger audience a chance to chime in before I go ahead and merge > it - but if I don't hear anything soon, I'll do just that. I'm down for this plan. I poked the 'approved' button and everything. -- -keith sign

Re: XORG_CHECK_MALLOC_ZERO: stop testing malloc, assume the worst

On Thu, Oct 24, 2024 at 03:14:01PM -0700, Alan Coopersmith wrote: > After a recent conversation on Mastodon about how checking if a malloc() > implementation returns NULL for malloc(0) at build time can give different > answers than you may get at runtime if an application or LD_PRELOAD has > inter

Re: CI hardware sponsoring for Xorg / Freedesktop

Hi Enrico We'd need to check with fd.o admins whether this technically makes sense, and they expect from CI runners. Adding sitewranglers for that. Also I guess a rough guesstimate of the power costs would be needed for the board to approve. Cheers, Sima On Fri, 6 Sept 2024 at 16:32, Enrico Weig

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

On 8/15/24 01:15, Matthieu Herrb wrote: On Tue, Aug 13, 2024 at 01:56:14PM +0200, Enrico Weigelt, metux IT consult wrote: On 08.08.24 13:37, Matthieu Herrb wrote: But also try to avoid gratuitous churn. I'm opposed to commit to just move variable declaration around "because we can". You're

Re: X11 Specification process

On 8/23/24 03:40, Enrico Weigelt, metux IT consult wrote: hi folks, I'm curious how the protocol specification process practically works these days. Demi proposed some interesting things (*1), which IMHO should be formally specificed. How's the decision exact process for such proposals ? I

Re: xcb docs @x.org broken

On Tue, Aug 20, 2024 at 08:12:16AM -0700, Alan Coopersmith wrote: > On 8/20/24 02:46, Enrico Weigelt, metux IT consult wrote: > > Hi folks, > > > > > > I've seen the xcb docs at x.org are pretty broken, eg. > > > > https://www.x.org/releases/current/doc/man/man3/xcb_query_font.3.xhtml > > > > I

Re: xcb docs @x.org broken

On 8/20/24 02:46, Enrico Weigelt, metux IT consult wrote: Hi folks, I've seen the xcb docs at x.org are pretty broken, eg. https://www.x.org/releases/current/doc/man/man3/xcb_query_font.3.xhtml It is still maintained ? It's been many years since I last updated them, and I don't remember how

Re: xcb docs @x.org broken

On Tue, Aug 20, 2024 at 11:46:25AM +0200, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > > I've seen the xcb docs at x.org are pretty broken, eg. > > https://www.x.org/releases/current/doc/man/man3/xcb_query_font.3.xhtml > > It is still maintained ? There is a spurious "" line 77. Th

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

On 15.08.24 10:15, Matthieu Herrb wrote: There have been enough security issues in the past in this area (and I sure there are still a lot waiting to be "discovered", because there is no currently active effort beside yours to and the work by ZDI to audit and fix issues actively. Well, that's

Re: Found and fixed a 20 years old bug in Xserver :)

On 8/15/24 06:40, Enrico Weigelt, metux IT consult wrote: Seriously, I don't have any clue what that really supposed to mean. Unfortunately, we don't have any explaination in the git history - it came from a big X11R6.6 snapshot, 20 years ago. We don't have full history for all of X, but for th

RE: xcb: list & padding

>> https://gitlab.freedesktop.org/xorg/lib/libxcb/-/merge_requests/14 changes >> it so that lists always require explicit padding (and therefore allows >> unpadded lists). This MR is stalled. With a little review, I think it can be >> merged. > > oh, it's laying around there for 3 years now, nob

Re: xcb: list & padding

On 13.08.24 15:29, Peter Harris wrote: Hi, https://gitlab.freedesktop.org/xorg/lib/libxcb/-/merge_requests/14 changes it so that lists always require explicit padding (and therefore allows unpadded lists). This MR is stalled. With a little review, I think it can be merged. oh, it's laying a

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

On Tue, Aug 13, 2024 at 01:56:14PM +0200, Enrico Weigelt, metux IT consult wrote: > On 08.08.24 13:37, Matthieu Herrb wrote: > > > But also try to avoid gratuitous churn. I'm opposed to commit to just > > move variable declaration around "because we can". > > You're referring to me, right ? Not

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

On 08.08.24 13:37, Matthieu Herrb wrote: But also try to avoid gratuitous churn. I'm opposed to commit to just move variable declaration around "because we can". You're referring to me, right ? See my other mail and ticket #1701: the MRs in question are preparational work for other things in

RE: Does anyone still feel strongly about -Wdeclaration-after-statement ?

> Using __attribute__((cleanup)) plus a bit macro magic gives us a little taste > of > golang's defer. > > Is there any strong reason for not using it ? Not all compilers support __attribute__((cleanup)). I don't know if anybody still uses Sun Studio or IBM's XLC, but I still use MSVC to build.

RE: xcb: list & padding

https://gitlab.freedesktop.org/xorg/lib/libxcb/-/merge_requests/14 changes it so that lists always require explicit padding (and therefore allows unpadded lists). This MR is stalled. With a little review, I think it can be merged. As long as you're looking at xkb, see also https://gitlab.freede

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

On 08.08.24 05:32, Peter Hutterer wrote: I feel fairly strongly about removing that warning, i.e. allowing declarations after statements. There's a reason all modern languages allow this. It makes the code clearer and less buggy in many instances, esp. in regards to variables that don't need to

Re: merge requests to Geode

On 13.08.24 08:41, Martin-Éric Racine wrote: Enrico, do you think that you could help Connor finalize this MR? last time I checked (any replied), i've been fine with this. just been a bit naggling about esthetic aspects - suggested splitting it a bit to make it easier for the reader of the pa

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

> > Having said that, sticking with the local code style still trumps > > anything, if you have 6 temp variables declared at the top mixed with 5 > > declared later that's more confusing than if all were at the top. > > But also try to avoid gratuitous churn. I'm opposed to commit to just > move

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1601 > > > > Do we want to keep insisting on this as part of our style, or have people > > gotten used to it from other languages/projects now and are willing to > > accept it in X.Org code? > > > > Is i

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

ed a number of merge requests that use it to > simplify some of our previous code, such as: > https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1601 > > Do we want to keep insisting on this as part of our style, or have people > gotten used to it from other language

Re: difference between XFillRectangles() and xcb_poly_fill_rectangle()

Sorry, wrong subject. Am Montag, dem 05.08.2024 um 01:44 +0200 schrieb Goran: > Is this good or bad for X? > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30400 > > Am Freitag, dem 02.08.2024 um 14:54 +0200 schrieb Enrico Weigelt, > metux > IT consult: > > On 01.08.24 20:36, Enrico

Re: difference between XFillRectangles() and xcb_poly_fill_rectangle()

Is this good or bad for X? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30400 Am Freitag, dem 02.08.2024 um 14:54 +0200 schrieb Enrico Weigelt, metux IT consult: > On 01.08.24 20:36, Enrico Weigelt, metux IT consult wrote: > > ... answering myself: >   > Is there something subtle in

Re: difference between XFillRectangles() and xcb_poly_fill_rectangle()

On 01.08.24 20:36, Enrico Weigelt, metux IT consult wrote: ... answering myself: > Is there something subtle in here that I've overseen ? (something XGC's internal state maybe ?) Xlib indeed has a write-back cache for GC attributes, which is written out by all functions that need (server side

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

Hey, On Mon, Jul 29, 2024 at 2:49 AM Alan Coopersmith < alan.coopersm...@oracle.com> wrote: > […] > Do we want to keep insisting on this as part of our style, or have people > gotten used to it from other languages/projects now and are willing to > accept it in X.Org code? > I reckon having the

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

On 31/Jul/2024 00:31, Jeremy Sequoia wrote: <...> > I'd even go farther and say that we should allow code that requires C11. C11 might be slightly problematic in some platforms, but C99 is currently widely available and has 99% of the interesting stuff...

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

if someone happens to re-order some code and doesn't realize that they introduced a read before initialization. Yes, that can be caught with static analysis, but still... don't rely on complex solutions when simpler solutions are available. > On Jul 28, 2024, at 17:48, Alan Coopersmi

Re: Adding a new label "Regression" to xorg/xserver gitlab project

On 23.07.24 11:44, Olivier Fourdan wrote: Hi all, The master branch of the xserver is seeing a lot of changes, and people are sometimes reporting regressions. I am proposing to add a new label "Regression" that would help quickly identifying such issues in gitlab so the relevant people can focu

Re: Does anyone still feel strongly about -Wdeclaration-after-statement ?

> Do we want to keep insisting on this as part of our style, or have people > gotten used to it from other languages/projects now and are willing to > accept it in X.Org code? Yeah, a lot of style comments and one worry about older toolchains. Are all of the *BSDs are on C99 compilers now? Linux

Re: Adding a new label "Regression" to xorg/xserver gitlab project

On Wed, Jul 24, 2024 at 12:20 PM Peter Hutterer wrote: > On Tue, Jul 23, 2024 at 11:44:11AM +0200, Olivier Fourdan wrote: > > Hi all, > > > > The master branch of the xserver is seeing a lot of changes, and people > are > > sometimes reporting regressions. > > > > I am proposing to add a new labe

Re: Adding a new label "Regression" to xorg/xserver gitlab project

On Tue, Jul 23, 2024 at 11:44:11AM +0200, Olivier Fourdan wrote: > Hi all, > > The master branch of the xserver is seeing a lot of changes, and people are > sometimes reporting regressions. > > I am proposing to add a new label "Regression" that would help quickly > identifying such issues in git

Re: Announce: Xorg testing ground v0.0.4 -- adding Illumos/OpenSolaris support

Hello friends, I've just released v0.0.4 of the Xorg testing ground kit, which is now also supporting Illumos (OpenIndiana). [ Special call out to the Solaris community: I'd love to also support other distros (eg. Tribblix), as well as the commerial Solaris, but that's a bit overreaching my

Re: [PATCH] fbdevhw: fix sysfs path PCI device detection

On 18.07.24 09:47, Thomas Zimmermann wrote: Hi, Reviewed-by: Thomas Zimmermann by me, too. He's absolutely right: the current implementation relies on an accidential artifact of the older kernel versions - this aspect has never been any part of uapi. It might be more effective to open a m

Re: [PATCH] fbdevhw: fix sysfs path PCI device detection

Hi Am 15.07.24 um 12:21 schrieb Tj: Linux kernel v6.9 has changed the symlink to point to the parent device. This breaks fbdev_open() detection logic. Change it to use the subsystem symlink instead which will remain stable. Kernel v6.8: [14.067] (II) fbdev_open() sysfs_path=/sys/class/gr

Re: FixesSelectSelectionInput

On 2024-06-30 09:30, Po Lu wrote: > A recent "security fix" in ProcXFixesSelectSelectionInput hamstrings > this request in the event that no ownership has yet been asserted over > the selection. > > The proximate cause is thus: dixLookupSelection returns error > indications when no selection data

Re: [PING^3] xcbproto Meson added, CI passed

On Fri, Jun 28, 2024 at 03:05:45PM -0700, Alan Coopersmith wrote: > You might get more attention by mailing the xcb-specific mailing list, > as noted on https://xcb.freedesktop.org/ and in the xcbproto/README.md. > > But then again, you may just find that there are so few developers left, > that t

Re: [PING^3] xcbproto Meson added, CI passed

You might get more attention by mailing the xcb-specific mailing list, as noted on https://xcb.freedesktop.org/ and in the xcbproto/README.md. But then again, you may just find that there are so few developers left, that there is no one who has both the knowledge and time to review something like

Re: Do we still need server generations ?

> Date: Wed, 26 Jun 2024 18:36:16 +0200 > From: "Enrico Weigelt, metux IT consult" > > Hi folks, > > I wonder whether we really still need server generations. > > I've always fonud that *very* confusing that it does some internal > restart (including VT switch, because graphics also reinitializ

Re: [PING] xcbproto Meson added, CI passed

Hello, Could I have some feedback please ? TIA On Tue, Jun 18, 2024 at 09:33:21AM +0200, tlaro...@kergis.com wrote: > Is it OK? If there are things that someone doesn't think I have done > right, please give feedback---I have, I think, answered about Python > handling knowing that on OSes python

Re: Announce: Xorg testing ground v0.0.3 -- adding OpenBSD support

Hello friends, I've just released v0.0.3 of the Xorg testing ground kit, which is now also supporting OpenBSD 7.5. As like with the other platforms, it automatically detects the host type via uname and automatically selects OpenBSD as target platform (unless explicitly configured otherwise). Cu

Re: [PING] Merge request: xcbproto Meson added, CI passed

On 18.06.24 09:33, tlaro...@kergis.com wrote: Hi, Is it OK? If there are things that someone doesn't think I have done right, please give feedback---I have, I think, answered about Python handling knowing that on OSes python third partie packages handling is not a simple matter. sorry, didn't

Re: announce: canonical CI pipelines for drivers + FreeBSD builds

Update: There's no need for having an own copy of the scripts in each individual driver repo anymore - all pulled from a central location now. Here's an MR for putting this into `modular` repo. If it should go to somewhere else instead, just let me know: https://gitlab.freedesktop.org/xorg/

Re: [PING] Merge request: xcbproto Meson added, CI passed

Hello, On Tue, Jun 18, 2024 at 10:46:27AM +0200, Enrico Weigelt, metux IT consult wrote: > On 18.06.24 09:33, tlaro...@kergis.com wrote: > > Hi, > > > Is it OK? If there are things that someone doesn't think I have done > > right, please give feedback---I have, I think, answered about Python >

Re: Merge request for auto-meson-pc-cmp.sh + Meson and CI for xcbproto

I have closed the merge request since this wasn't the problem: I made a blunder in the directories passed as arguments. Since one was not foudn (the script tests), if failed as it should. For Meson with python and the rest (for xcbproto), I have debugged several blunders (setting prefix instead of

Re: consolidating CI builds

On Tue, Jun 11, 2024 at 10:49:35AM +0200, Enrico Weigelt, metux IT consult wrote: > On 11.06.24 09:09, Peter Hutterer wrote: > > hi folks, > > > With my ci-templates maintainer hat on: no to xorg-specific templates in > > there, it gets too messy. > > Indeed that would be the most wrong place.

Re: consolidating CI builds

On 11.06.24 10:49, Enrico Weigelt, metux IT consult wrote: As things are now, moving that all out to separate repo just doesn't work: cbuild (when building the container images) makes it's own git clone of the project's repo, and we don't have any means for injecting extra steps. So, when $FDO

Re: X11 crashes

On 11.06.24 14:41, Rathnavel J N wrote: Tried build the master branch stuck compiling it , Throws ../include contains GC already defined in /usr/include/xlib/xlib.h Can you send us a complete log ? thx. --mtx On Tue, 11 Jun 2024 at 18:08, Enrico Weigelt, metux IT consult mailto:i...@met

Re: X11 crashes

On 11.06.24 10:39, Rathnavel J N wrote: Hi, Xsererver version is X -version X.Org X Server 1.20.13 Maybe try building from master branch. https://gitlab.freedesktop.org/xorg/xserver I believe that should alreay been fixed there. See: https://gitlab.freedesktop.org/xorg/xserver/-/commit/8c

Re: consolidating CI builds

On 11.06.24 09:09, Peter Hutterer wrote: hi folks, With my ci-templates maintainer hat on: no to xorg-specific templates in there, it gets too messy. Indeed that would be the most wrong place. Note that you can include any file from another repo (I think) so in theory we could ship the temp

Re: consolidating CI builds

On Mon, Jun 10, 2024 at 12:11:56PM -0700, Alan Coopersmith wrote: > On 5/24/24 03:12, Enrico Weigelt, metux IT consult wrote: > > So, I'm thinking about creating some standard templates that all drivers > > can use. The interesting question now becomes: where to put these ? > > > > Abuse xorg/util

Re: consolidating CI builds

On 5/24/24 03:12, Enrico Weigelt, metux IT consult wrote: So, I'm thinking about creating some standard templates that all drivers can use. The interesting question now becomes: where to put these ? Abuse xorg/util/cf or xorg/util/macros or create an entirely new repo ? I wouldn't use either o

Re: consolidating CI builds

Hello, On Fri, May 24, 2024 at 12:12:06PM +0200, Enrico Weigelt, metux IT consult wrote: > Hello friends, > > I'm thinking about consolidating the CI stuff, especially of drivers. > > For now, most are building against master, few using a version matrix. > Most are built only on Linux, few (tho

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

On 24.03.24 21:58, Alan Coopersmith wrote: On 12/11/23 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/app/x

Re: xcbproto: Meson added + doc

On Thu, Jun 06, 2024 at 07:46:11PM +, Peter Harris wrote: > > For the python related utilities: find_vpython.sh (find a python > > interpreter matching a version condition) and compile_py.sh (self > > explanatory), they have to be distributed. > > I haven't looked at your repository, so please

RE: xcbproto: Meson added + doc

> For the python related utilities: find_vpython.sh (find a python > interpreter matching a version condition) and compile_py.sh (self > explanatory), they have to be distributed. I haven't looked at your repository, so please forgive me if I've missed something important. But shouldn't these be h

Re: Anything depending on non-libpciaccess ?

On Wed, May 15, 2024 at 01:04:43PM +0200, Enrico Weigelt, metux IT consult wrote: > Hello folks, > > are there still some platforms that can't be built w/o libpciaccess ? > > Rationale: we've got lots of #ifdef's on that in the drivers, and I > wonder whether that's still really needed. Hi, On

Re: gitlab ssh down ?

* Enrico Weigelt, metux IT consult (i...@metux.net) wrote: > Hi folks, > > I'm just having trouble pushing to my own forks via ssh. It's also > really slow, so I suspect some overload problem. Remaining for some > hours now. > > Anybody else noticing similar problems ? Yeh, I'm seeing that (on t

Re: Code source of libX11

On 5/7/24 02:38, Ismael Luceno wrote: On 06/May/2024 09:59, Aaron Gomez | Rother Industries & Technology wrote: I have checked out libX11 on gitlab and would like to known the code source of libX11? How is it possible to obtain it? Hi Aaron, You canfind the main repository here:

Re: Code source of libX11

On 06/May/2024 09:59, Aaron Gomez | Rother Industries & Technology wrote: > I have checked out libX11 on gitlab and would like to known the code > source of libX11? > > How is it possible to obtain it? Hi Aaron, You canfind the main repository here:

Re: [ANNOUNCE] rendercheck 1.6

On Wed, Apr 24, 2024 at 7:12 AM wrote: > > In the commits, I note this: > > On Tue, Apr 23, 2024 at 03:53:39PM -0400, Matt Turner wrote: > >[...] > > Eric Anholt (10): > > [...] > > Remove the autotools build system. > > There are OSes that do not ship with Python. During an intermim >

Re: [ANNOUNCE] rendercheck 1.6

On 4/24/24 04:12, tlaro...@kergis.com wrote: In the commits, I note this: On Tue, Apr 23, 2024 at 03:53:39PM -0400, Matt Turner wrote: [...] Eric Anholt (10): [...] Remove the autotools build system. There are OSes that do not ship with Python. During an intermim period, couldn'

Re: [ANNOUNCE] rendercheck 1.6

In the commits, I note this: On Tue, Apr 23, 2024 at 03:53:39PM -0400, Matt Turner wrote: >[...] > Eric Anholt (10): > [...] > Remove the autotools build system. There are OSes that do not ship with Python. During an intermim period, couldn't we provide _both_ autotools and meson? in

Re: compensatory fixes for xf86-video-intel driver

On 15.04.24 17:15, J Lumby wrote: Well,    thanks for mentioning that, but that seems to raise a question. I git cloned from https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel.git/ on 2 April. Isn't the git repository supposed to be up-to-date every night? seems my patches weren't pi

Re: compensatory fixes for xf86-video-intel driver

On 4/15/24 02:59, Enrico Weigelt, metux IT consult wrote: On 06.04.24 20:00, John Lumby wrote: Hi John, Some tidying-up changes made in xorg/xserver in the last few months,   e.g. some shuffling in render/picturestr.h,   and one other elsewhere,   appear to have broken building of xf86-video-

Re: compensatory fixes for xf86-video-intel driver

Well,    thanks for mentioning that, but that seems to raise a question. I git cloned from https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel.git/ on 2 April. Isn't the git repository supposed to be up-to-date every night? Where you say "cleaned up in xfree86-video-intel"  --    wher

Re: compensatory fixes for xf86-video-intel driver

On 06.04.24 20:00, John Lumby wrote: Hi John, Some tidying-up changes made in xorg/xserver in the last few months, e.g. some shuffling in render/picturestr.h, and one other elsewhere, appear to have broken building of xf86-video-intel. (Am I the last one standing who actually buil

Re: [PATCH] Move xtrans.pc to /usr/share/pkg-config

Ok, thanks for the reply. Vào 22:50, T.5, 31 Th8, 2023 Alan Coopersmith đã viết: > On 8/29/23 14:48, Lam Le wrote: > > Your message came through with no body - no patch file was included. > > But we generally don't do patches by email in X.Org any more, instead > we take merge requests in our pr

Re: 2024 X.Org Foundation Membership deadline for voting in the election

On Tue, 26 Mar 2024 11:42:48 -0400 Christopher Michael wrote: > The 2024 X.Org Foundation membership renewal period has been extended > one additional week and elections will start the following week on 01 > April 2024. > > Please note that only current members can vote in the upcoming electio

Re: 2024 X.Org Foundation Membership deadline for voting in the election

Hi Pekka, On Tue, Apr 02, 2024 at 10:46:08AM +0300, Pekka Paalanen wrote: > On Tue, 26 Mar 2024 11:42:48 -0400 Christopher Michael wrote: > > > The 2024 X.Org Foundation membership renewal period has been extended > > one additional week and elections will start the following week on 01 > > Apr

Re: 2024 X.Org Foundation Membership deadline for voting in the election

This is a reminder that the membership renewal period ends in 2 days, and elections will start after that. Please register as an X.Org Foundation member to be able to vote in the upcoming elections. Thanks! -Ricardo Garcia, on behalf of the X.Org elections committee. On Tue, 2024-03-26 at 11:42

Re: CI/yaml: inlining or providing an "upstream" utility

On Wed, Mar 27, 2024 at 09:00:12PM +1000, Peter Hutterer wrote: > On Mon, Mar 25, 2024 at 11:19:49AM +0100, tlaro...@kergis.com wrote: > > On Mon, Mar 25, 2024 at 08:07:24PM +1000, Peter Hutterer wrote: > > > On Mon, Mar 25, 2024 at 08:36:44AM +0100, tlaro...@kergis.com wrote: > > > > In a previous

Re: CI/yaml: inlining or providing an "upstream" utility

On Mon, Mar 25, 2024 at 11:19:49AM +0100, tlaro...@kergis.com wrote: > On Mon, Mar 25, 2024 at 08:07:24PM +1000, Peter Hutterer wrote: > > On Mon, Mar 25, 2024 at 08:36:44AM +0100, tlaro...@kergis.com wrote: > > > In a previous mail, I proposed, when autotools and meson are both > > > provided to b

Re: CI/yaml: inlining or providing an "upstream" utility

On Mon, Mar 25, 2024 at 08:07:24PM +1000, Peter Hutterer wrote: > On Mon, Mar 25, 2024 at 08:36:44AM +0100, tlaro...@kergis.com wrote: > > In a previous mail, I proposed, when autotools and meson are both > > provided to build a module, to not verify what they provide by simply > > diffing the resu

Re: CI/yaml: inlining or providing an "upstream" utility

On Mon, Mar 25, 2024 at 08:36:44AM +0100, tlaro...@kergis.com wrote: > In a previous mail, I proposed, when autotools and meson are both > provided to build a module, to not verify what they provide by simply > diffing the resulting installation directories, but to treat pkgconfig > generated *.pc

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

On 12/11/23 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/app/xprop/-/merge_requests/8 Further testing tu

Re: Python byte-compiled files

On Sat, Mar 23, 2024 at 11:02:33AM -0700, Alan Coopersmith wrote: > On 3/23/24 09:24, tlaro...@kergis.com wrote: > > Furthermore, for example for xcb-proto, the python interface is one > > interface, but it is not mandatory (there is the primary C interface). > > The python files in xcb-proto are

Re: Python byte-compiled files

On 3/23/24 09:24, tlaro...@kergis.com wrote: Furthermore, for example for xcb-proto, the python interface is one interface, but it is not mandatory (there is the primary C interface). The python files in xcb-proto are not an alternative to the C interface provided in libxcb - they're the mechan

Re: Why does xf86-input-evdev ignore the xkb_rules option?

On Mon, Mar 18, 2024 at 05:55:04PM +0100, Martin Burggraf wrote: > Hi, >   > I have an input device/keyboard, which I reconfigured greatly, wrote my own > geometry files, symbols, keycodes and so on. > To make it work with X11 I wanted to write my own rules file for use with the > xf86-input-evde

Re: static libpciaccess?

https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/34 should fix this. -alan- On 2/20/24 08:33, Alan Coopersmith wrote: Sorry about that - I never build static libraries, so tend not to think about them.  I've cc'ed the other developers to see what they think - if the

Re: CI: comparing two pc files semantically

On 3/12/24 00:37, tlaro...@kergis.com wrote: But it would be better to compare, in the CI, the files semantically: just ensure that they "say" the same thing, whatever way the definitions are written. That sounds like a good idea, I think it was just easier to use diff on the plain text files w

Re: Reminder: 2024 X.Org Board of Directors Elections timeline extended, request for nominations

This is a reminder that we are still looking for candidates for the upcoming X.Org Board of Directors elections, and that today is the last day to submit personal statements for nomination. X.org membership renewals are still open and will be needed to vote on those elections. Please read bel

Re: xorg-sgml-doctools: merge request

On Mon, Mar 04, 2024 at 07:45:16PM +0100, tlaro...@kergis.com wrote: > [...] > There is one thing that will have to be decided globally. > > For now, pkgconfig files are installed in ${datadir}/pkgconfig. > > But "normally", pkgconfig files have to be installed in > ${libdir}/pkgconfig meaning th

Re: RFC: pkgconfigdir: where?

On Mon, Mar 04, 2024 at 10:41:31AM -0800, Alan Coopersmith wrote: > On 3/4/24 01:49, tlaro...@kergis.com wrote: > > As written in a previous mail, I'm trying to adjust meson to provide > > the same rope as AC. > > > > For xorg-sgml-doctools, there was a small discrepancy if the user was > > not se

Re: RFC: pkgconfigdir: where?

On 3/4/24 01:49, tlaro...@kergis.com wrote: As written in a previous mail, I'm trying to adjust meson to provide the same rope as AC. For xorg-sgml-doctools, there was a small discrepancy if the user was not selecting the defaults. This is easy to fix (diff attached), but I now wonder about pkgc

Re: meson options vs AC options:

On Sun, Mar 03, 2024 at 12:39:12PM -0800, Alan Coopersmith wrote: > > > > 1) meson.build defines: > > > > datarootdir = get_option('prefix') / get_option('datadir') > > sgmlrootdir = datarootdir / 'sgml' > > > > and generates the pkgconfig file from the template with: > > > > pc_conf = configur

Re: DRI3 damage tracking?

On 27/02/2024 17:23, Enrico Weigelt, metux IT consult wrote: But the more important part is what happens when the server would like to write to the buffer. Now I'm even more confused: why should the server want to write in the same buffer ? If I'm not completely mistaken, the client renders t

Re: meson options vs AC options:

On Sun, Mar 03, 2024 at 12:39:12PM -0800, Alan Coopersmith wrote: > On 3/3/24 12:06, tlaro...@kergis.com wrote: > > [I'm back to working on Xorg stuff]. > > > > When writing a meson.build, I realize that all the options settable > > with GNU AC are not available in meson built-ins. This does mean

Re: meson options vs AC options:

On 3/3/24 12:06, tlaro...@kergis.com wrote: [I'm back to working on Xorg stuff]. When writing a meson.build, I realize that all the options settable with GNU AC are not available in meson built-ins. This does mean that one has to add a meson_options.txt for everything used that is not a built-in

Re: gitlab: remove old pipelines ?

On 28.02.24 00:56, Peter Hutterer wrote: why do you need to remove them? since I'm frequently looking at them, I'd just like to remove old garbage which I'm sure I'll never wana look at again. (just speaking of the ones in my own fork) --mtx -- --- Hinweis: unverschlüsselte E-Mails können

Re: gitlab: remove old pipelines ?

On Tue, Feb 27, 2024 at 01:09:41PM +0100, Enrico Weigelt, metux IT consult wrote: > Hello folks, > > > Is there a way to actually remove old pipelines ? > > Gitlab offers a "delete" button, but this doens't seem to work: > when pressing it, the button just spins forever - and after reload > not

Re: DRI3 damage tracking?

On 27.02.24 16:09, Pierre Ossman wrote: To start with, what the client wants to draw (CopyArea/Present) is not the same thing as what it has actually modified. It might not have modified anything and only wants to copy from an off-screen Pixmap to a window because of an Expose event. But the mo

Re: DRI3 damage tracking?

On 27/02/2024 13:03, Enrico Weigelt, metux IT consult wrote: I'm confused: what exactly are you reading back ? To my understanding, the client renders into some buffer and at some point tells the Xserver to copy that buffer (or region of it) into the window. I'm not deep into DRI/GLX, but I'd a

Re: DRI3 damage tracking?

On 27.02.24 09:37, Pierre Ossman wrote: Hi, I'm playing around with adding DRI3 support to Xvnc, so that OpenGL and Vulkan can be accelerated for headless VNC sessions. cool :) The X server can follow what it modifies, so knowing what to push back to the GPU is fairly straightforward. But I

  1   2   3   4   5   6   7   8   9   10   >