Re: xserver extensions/hooks: freeing client resources
On 2/1/24 7:03 AM, Enrico Weigelt, metux IT consult wrote: Hello folks, I'm currently writing an extension that's storing per-client data. Where's is the right place to free up all resources ? I guess the client state xace hook - but what's the difference between retained and gone ? I don't think you need xace for this: CloseDownClient calls CallCallbacks((), (void *) ) so you can register a callback on that. "Retained" means that the client's resources should remain allocated in the server even after the client is gone. It's not a super useful mechanic these days but you'll have to decide whether a "retained" client disappearing should free your per-client data or not. The other option is to use AddResource to allocate resources associated with a particular client's XIDs. Those are freed by FreeClientNeverRetainResources or FreeClientResources, depending on whether the client is supposed to be retained and whether the resource type in question is marked with the RC_NEVERRETAIN flag. -- Aaron thx --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: issues and merge requests
On Mon, Feb 05, 2024 at 09:52:50PM +0100, tlaro...@kergis.com wrote: > Alan Coopersmith has applied the merge request for libXau---thanks! > > I had written 2 issues, related, against libXau, that the patches > address, so I have closed the issues after the merge. > > It seems to me that writing issues against a module; providing patches > via a merge request; then closing the issues when the merge has been > approved and applied by a developer has the advantage of providing an > history. > > Are there guidelines set concerning this? Best approach is to add a line "Fixes #123" into the commit message and/or the merge request and gitlab will automatically link to to issue 123 in the same repo and close it when merged. Otherwise and if on the same instance, you can also link to other projects using the full path including namespace, e.g. xorg/lib/libX11!10 is merge request 10 in libX11. Note that a "Fixes #123" in a commit message will link from the issue to the commit every time you push. If you're easily embarrassed about your development flow it's best to leave that off and add it before the final push before filing a merge request ;) Cheers, Peter
Re: Meson vs. automake/autoconf
On 2/5/24 12:45, tlaro...@kergis.com wrote: I'm continuing my review and I'm now looking at libxcb and xcbproto. Is there a goal set to switch from auto* tools to meson/ninja for the maximum of projects? Yes - that's our overall direction, but progress is going slowly. There is some though - if you look at the postings from the past few days on https://lists.x.org/archives/xorg-announce/2024-February/thread.html you'll see libpciaccess dropped the autoconf files altogether after having a previous release with both, and libxkbfile & libXvMC both had their first releases with meson added and announcing plans to drop autoconf in the future. Since I have to untangle things for my own built framework, I may as well provide meson files (that are undoubtely more readable than the auto* dance) when I am at it... That'd be nice. You should be able to find a number of examples of how we've set up the .gitlab-ci.yaml files to build with both methods when both are present and test that the expected combinations work. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
issues and merge requests
Alan Coopersmith has applied the merge request for libXau---thanks! I had written 2 issues, related, against libXau, that the patches address, so I have closed the issues after the merge. It seems to me that writing issues against a module; providing patches via a merge request; then closing the issues when the merge has been approved and applied by a developer has the advantage of providing an history. Are there guidelines set concerning this? -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Meson vs. automake/autoconf
I'm continuing my review and I'm now looking at libxcb and xcbproto. Is there a goal set to switch from auto* tools to meson/ninja for the maximum of projects? Since I have to untangle things for my own built framework, I may as well provide meson files (that are undoubtely more readable than the auto* dance) when I am at it... -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
RFC: xserver release planning
Hello folks, since Xorg server didn't have a (major) release for quite some time, I'd like to discuss how to proceed here. The major problems I'm seeing right now: #1 lots of open issues and PRs, but no release planning #2 a bunch of fixes (mostly bsd) in master, which look like they could go to 21.x maintenance releases #3 lack of server-module API specification #4 xorg master and xwayland have massively diverged, pretty much a fork I'd like to propose the following steps: * gitlab: add xserver-23.2 milestone (realign w/ xwayland) * go through open PRs, decide which branches they apply (still some bugfixes for 21.x ?) and tag them accordingly * work trough differences between master and xwayland branch and try to align them to each other (at some point in the future they should be pretty much equal * document the workflow * start documenting server-module-api * potentially deprecate some unused functions --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: xserver: do we still need Fopen() ?
On 02.02.24 21:05, Alan Coopersmith wrote: Hi, I suspect for the OS'es that the xserver code builds on today, that could be replaced by #ifndef WIN32, which would then allow the first half of that #ifdef in Fopen to be deleted, leaving just the simpler case, since Fopen is already not built for WIN32. Does WIN32 still mean 32bit Windows or also more modern ones like w10/w11 ? If the Xserver is run as setuid root, On which platforms is that still the case ? And does it need to run as root all the time, instead of after opening some devices ? you don't want to let it read files with root privs that are specified by a non-root user - that way lies CVEs. Yes, of course. But can't we just have an extra permission check ? I could imagine adding a build flag to the server that said not to support running setuid, that would set a define that skipped this code and instead enabled code to check issetugid() on startup and instantly exit if it was true, That seems indeed helpful also for alerting installations that still do it even if not necessary anymore. Actually I'd enable it by default. And is there still any need to run it as root at all ? Yes. Not every OS the X server runs on has KMS support for every device. I don't know how to express that in a meson, autoconf, or #ifdef check though. Add an explicit option for that ? --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
