I had suggested something similar 13 years ago:
https://lists.x.org/archives/xorg-devel/2012-October/033883.html
Basically allowing users to put the X11 socket wherever they like.
This is even more relevant nowadays with containers, bind mounts, etc
point of discussion being -> let's sort out ho
On Fri Jul 4, 2025 at 7:33 AM BST, Carsten Haitzler wrote:
> On Fri, 04 Jul 2025 01:07:23 +0100 "Artur Manuel" said:
>
>> On Thu Jul 3, 2025 at 7:44 AM BST, Carsten Haitzler wrote:
>> > so do you propose the xserver sets up these symlinks? if x is running as
>> > $USER then putting it in the xdg r
Now you know who your enemies are.
The first woke banning of opensource code was in 2007 or 2009, I remember.
Only RMS and ESR spoke out against it. Everyone else was silent or cheered.
On Friday, June 6, 2025 at 09:52:01 AM EDT, Enrico Weigelt, metux IT consult
wrote:
Hello everybo
On Fri, 04 Jul 2025 01:07:23 +0100 "Artur Manuel" said:
> On Thu Jul 3, 2025 at 7:44 AM BST, Carsten Haitzler wrote:
> > so do you propose the xserver sets up these symlinks? if x is running as
> > $USER then putting it in the xdg runtime dir makes sense. but then... you
> > have issues with mult
On Thu Jul 3, 2025 at 7:44 AM BST, Carsten Haitzler wrote:
> so do you propose the xserver sets up these symlinks? if x is running as $USER
> then putting it in the xdg runtime dir makes sense. but then... you have
> issues
> with multiple users fighting over /tmp/.X11-unix for the compat symlinks
On Wed, 02 Jul 2025 19:40:13 +0100 "Artur Manuel" said:
> Hello, hope this email comes in good faith.
>
> I was thinking of any benefits that could arise from moving the X11
> socket from /tmp/.X11-unix to $XDG_RUNTIME_DIR/.X11-unix and I thought
> of a few. This thought was inspired by Wayland
Addendum to yesterday's X.Org Security Advisory for CVE-2025-49176:
On 17/06/2025 15:43, Olivier Fourdan wrote:
[...]
==
2) CVE-2025-49176: Integer overflow in Big Requests Extension
The Big Requests extension allows requests
[Nick: oops! I forgot to do Reply All, so you’ll see this twice.]
I’m not quite sure why you started a new thread for this.
In any case, If you use X Quartz and select the Full Screen option in the
Output tab in the settings, then you will achieve this. You may need to quit X
Quartz and restart
That’s exactly what I was looking for. xterm -fullscreen is fullscreen now
like a terminal.
Thanks!
> On May 13, 2025, at 2:55 PM, Rob Arthan wrote:
>
> [Nick: oops! I forgot to do Reply All, so you’ll see this twice.]
>
> I’m not quite sure why you started a new thread for this.
>
> In any
Comments
> On May 13, 2025, at 3:09 AM, Carsten Haitzler wrote:
>
> On Tue, 13 May 2025 02:08:49 -0400 Atod Notbora said:
>
>> When using XQuartz on MacOS is there a way to make an xterm window
>> completely full screen, without the top title bar or dock below? Like a
>> terminal?
>>
>> At t
If you want to start an xterm fullscreen, you can, from a terminal, execute:
xterm -fullscreen
Is this what you want?
cytan
On Tuesday, May 13, 2025 at 02:09:02 PM GMT+8, Atod Notbora via X11-users
wrote:
When using XQuartz on MacOS is there a way to make an xterm window
completely ful
On Tue, 13 May 2025 02:08:49 -0400 Atod Notbora said:
> When using XQuartz on MacOS is there a way to make an xterm window
> completely full screen, without the top title bar or dock below? Like a
> terminal?
>
> At the moment, it appears my XQuartz session uses an Aqua style
> WM. I'm wonderi
Hello,
On Fri, 2 May 2025 13:09:20 +0200
"Enrico Weigelt, metux IT consult" wrote:
> * https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1940
>
>-> removes probing for several sbus cards that we don't have any
> drivers anymore
>-> we (Xorg) never had a driver for MGX
On 29.04.25 15:27, Michel Dänzer wrote:
In most cases, that's really simple and straightforward, [...]
That contradicts my experience working on the X server code for over two decades.
Sorry, most cases, I've converted so far. (just speaking about what's in
that queue)
Of course there also
On 2025-04-29 13:13, Enrico Weigelt, metux IT consult wrote:
> Hello folks,
>
>
> I'm currently working on simplifying hooking into ScreenRec proc's:
>
> Instead of anybody directly manipulating the individual proc vectors
> and forming a daisy chain, now using the generic callback mechanism
> w
вт, 8 апр. 2025 г., 10:59 Pekka Paalanen :
> On Mon, 7 Apr 2025 18:31:17 +0300
> Andrew Randrianasulu wrote:
>
> > пн, 7 апр. 2025 г., 17:18 Pekka Paalanen :
> >
> > > On Mon, 7 Apr 2025 14:44:25 +0300
> > > Andrew Randrianasulu wrote:
> > >
> > > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <
> p
пн, 7 апр. 2025 г., 17:18 Pekka Paalanen :
> On Mon, 7 Apr 2025 14:44:25 +0300
> Andrew Randrianasulu wrote:
>
> > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen :
> >
> > > On Fri, 4 Apr 2025 22:14:10 +0300
> > > Andrew Randrianasulu wrote:
> > >
> > > > пт, 4 апр. 2025 г., 21:35 Andrea paz :
> > > >
On Mon, 7 Apr 2025 18:31:17 +0300
Andrew Randrianasulu wrote:
> пн, 7 апр. 2025 г., 17:18 Pekka Paalanen :
>
> > On Mon, 7 Apr 2025 14:44:25 +0300
> > Andrew Randrianasulu wrote:
> >
> > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen :
> > >
> > > > On Fri, 4 Apr 2025 22:14:10 +0300
> > > > And
пн, 7 апр. 2025 г., 14:19 Pekka Paalanen :
> On Fri, 4 Apr 2025 22:14:10 +0300
> Andrew Randrianasulu wrote:
>
> > пт, 4 апр. 2025 г., 21:35 Andrea paz :
> >
> > > @Georgy
> > > X11 supports CMS more or less well. Even I was able to profile the
> > > monitor and install it with colord. It's not f
On Mon, 7 Apr 2025 14:44:25 +0300
Andrew Randrianasulu wrote:
> пн, 7 апр. 2025 г., 14:19 Pekka Paalanen :
>
> > On Fri, 4 Apr 2025 22:14:10 +0300
> > Andrew Randrianasulu wrote:
> >
> > > пт, 4 апр. 2025 г., 21:35 Andrea paz :
> > >
...
> > > > A theoretical question: can CinGG be adapte
On Fri, 4 Apr 2025 22:14:10 +0300
Andrew Randrianasulu wrote:
> пт, 4 апр. 2025 г., 21:35 Andrea paz :
>
> > @Georgy
> > X11 supports CMS more or less well. Even I was able to profile the
> > monitor and install it with colord. It's not full support like Windows
> > or Apple has, but it's doable
пт, 4 апр. 2025 г., 21:35 Andrea paz :
> @Georgy
> X11 supports CMS more or less well. Even I was able to profile the
> monitor and install it with colord. It's not full support like Windows
> or Apple has, but it's doable.
> For Wayland the big problem, why they didn't want to make a CMS, is
> it
On 12.03.25 13:29, Enrico Weigelt, metux IT consult wrote:
hello friends,
That's one of the more tricky things, especially since there's more than
clipboard protocol ;-)
here's a little update:
1. xselections are now fully isolated:
* namespace's IDs are internally prefixed to selection n
On 11.03.25 19:46, Alan Coopersmith wrote:
Hi,
This sounds partially similar to the Trusted Solaris extension, which in
Solaris 10 and later relied on Solaris zones for the client isolation for
each "label", and returned fake success messages to reduce the breakage on
client applications (which
On 3/11/25 11:02, Enrico Weigelt, metux IT consult wrote:
Hello folks,
I'd like to let you know I'm working on a new Xserver extension that's
putting clients into different "namespaces", so they can be isolated
from each other.
The idea is a bit similar to Linux namespaces (containers), where
p
On 3/8/25 20:55, B. Wilson wrote:
Hello,
When mcookie is not found at configure time, we were failing to correctly
set HAS_COOKIE_MAKER and MK_COOKIE, which ends up causing startx to think it
should run a command called MK_COOKIE. The attached patch fixes this case.
Additionally, when MCOOKIE i
- Original Message -
| From: "Nick"
| To: "xorg-devel"
| Sent: Monday, March 10, 2025 12:27:46 AM
| Subject: xterm: incorrect behavior with meta keys? rxvt and gnome-terminal
behave correctly.
| Does anyone know why Emacs-like keybindings such as Meta-b (back word) and
| Meta-f (forward
On 07.02.25 22:25, Ville Syrjälä wrote:
Hi,
xf86-video-intel driver is currently cannot be compiled with released
versions of X server. Simple reproduction steps: create Debian Bookworm
container, download module sources and all required dependencies and try
to build.
Builds fine on my Gentoo
On 2025-02-07 23:25, Ville Syrjälä wrote:
> On Fri, Feb 07, 2025 at 08:57:34PM +0200, Povilas Kanapickas wrote:
>> Hi,
>>
>> xf86-video-intel driver is currently cannot be compiled with released
>> versions of X server. Simple reproduction steps: create Debian Bookworm
>> container, download module
Hi Ville,
Thanks for quick response.
Turns out due to multiple factors leading to my confusion most parts of
the email are plainly wrong. Apologies for going to public mailing list
without more research and discussion.
On 2025-02-07 23:25, Ville Syrjälä wrote:
> On Fri, Feb 07, 2025 at 08:57:34P
On Fri, Feb 07, 2025 at 08:57:34PM +0200, Povilas Kanapickas wrote:
> Hi,
>
> xf86-video-intel driver is currently cannot be compiled with released
> versions of X server. Simple reproduction steps: create Debian Bookworm
> container, download module sources and all required dependencies and try
>
On Wed, Jan 29, 2025 at 01:48:06PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 20.11.24 15:19, nia wrote:
>
> Hi,
>
> sorry for the long dalay.
>
> > All of the code is under the X11 license and unlikely
> > to compile on non-NetBSD without a little patching,
> > at the very least due t
On Thu, Jan 30, 2025 at 01:29:52PM +0100, Enrico Weigelt, metux IT consult
wrote:
> > I'd assume you wanted to mirror the repositories on
> > git.freedesktop.org,
>
> Not necessarily, but at least let xorg-testing build all these
> drivers on NetBSD target.
>
> > since we keep everything in a cv
On 05.12.24 07:57, Chris Ward wrote:
I am trying to build the xorg Xserver (because I want to profile it with
-p or -pg) and getting build breaks. After getting past several of the
libs requiring an empty 'm4' directory, The first is a complaint that
'fontconfig' is installed in a non-standard pa
On 14.12.24 08:06, tlaro...@kergis.com wrote:
I still liked to have a Xorg developers' expressed policy about these
points:
- Has the meson framework to provide at least the configuration
flexibility provided by autotools, so that whoever is compiling Xorg
could, in the future, configure it the
On 20.11.24 15:19, nia wrote:
xf86-input-ws
Input driver for mice, touchscreens, and touchpads
shared with OpnBSD
https://github.com/NetBSD/xsrc/tree/trunk/external/mit/xf86-input-ws
Aproos input devices:
What's the status of libinput on NetBSD ? (FreeBSD seems to have it).
Could we just wri
On 29.01.25 18:51, tlaro...@kergis.com wrote:
Hi,
Theoretically, python is interpreted, so byte-compiling should not be
necessary.
Yes, and IIRC it's only a cache (for reducing startup time) anyways.
Some distros to package them, but for good reasons they've got their
special build machinerie
On 29.01.25 19:16, nia wrote:
Hi,
By the way: I still like to add netbsd to the CI - major blocker
is lack of a suitable cloud image, where we can directly ssh into
w/o any authentication. (f.d.o folks don't like to host custom
images that cant be automatically reproduced - we'd need some
"offi
On Wed, Jan 29, 2025 at 01:40:20PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 14.12.24 08:06, tlaro...@kergis.com wrote:
> > I still liked to have a Xorg developers' expressed policy about these
> > points:
> >
> > - Has the meson framework to provide at least the configuration
> > flexi
On 20.11.24 15:19, nia wrote:
Hi,
sorry for the long dalay.
All of the code is under the X11 license and unlikely
to compile on non-NetBSD without a little patching,
at the very least due to using wscons-specific ioctls.
Would it be hard to make it just compile on other platforms ?
Rational
On Sat, Dec 14, 2024 at 11:21:40AM -0800, Alan Coopersmith wrote:
> On 12/13/24 23:06, tlaro...@kergis.com wrote:
> > - Has the meson framework to provide at least the configuration
> > flexibility provided by autotools, so that whoever is compiling Xorg
> > could, in the future, configure it the w
On 12/13/24 23:06, tlaro...@kergis.com wrote:
- Has the meson framework to provide at least the configuration
flexibility provided by autotools, so that whoever is compiling Xorg
could, in the future, configure it the way it managed to do with
autotools?
=> See: http://notes.kergis.com/x1
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
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 -
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:
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.
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.
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
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
> 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
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
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
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
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
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
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
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
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
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
>> 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
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
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
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
> 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.
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
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
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
> > 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
://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
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
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
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
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
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
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...
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
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
> 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
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
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
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
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
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
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
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
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
> 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
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
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
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
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/
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
>
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
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.
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
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
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
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
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
1 - 100 of 14572 matches
Mail list logo
