Re: TWM n00b history lesson

> Has anyone been around long enough to know how jim, keith and lemke > managed to get their twmrc files included in the samples that come > in the package? Because that's what we packaged with the old X consortium releases, and no-one has bothered to change them? -- -keith signature.asc

Re: GetScratchPixmapHeader / FreeScratchPixmapHeader

Jeremy Huddleston Sequoia writes: > Is there any real benefit to maintaining this released pixmap for > future re-use on modern hardware? It seems like it's a bunch of code > complexity without much benefit. I'm happy to nuke it completely > unless there are objections... Seems reasonable --

Re: Xlib contract for XEvent up/down-casting

Jeremy Huddleston Sequoia writes: > So the problem is clear, but I'm not sure which side needs to change. Probably both? How about a simple hack in XPutBackEvent that uses _XEventToWire followed by _XWireToEvent? That would also clear out any unused bits from the event before inserting it into

Re: XInitThreads in library constructor breaks Motif!

Po Lu writes: > Besides, how to move it forward? If it works, wouldn't the obvious > solution be to install the change? If all that is needed is for > someone to try it out, I'd be happy to do it, but I'm pretty sure the > better solution is just to remove the call to XInitThreads in the > first

Re: Questions about XPresent

Po Lu writes: > Does that make any sense? I'm thinking of a control flow that looks > like this, when the client draws to the window after a pixmap has been > presented by the compositor: > > Client Server Compositing manager > PresentPixmap >

Re: xserver and splitting ultra-wide monitors

Michael Wyraz writes: > For the second monitor, the output must be set to "none" which is > obviously wrong since it is connected to a device. The reason why it is > set to "none" is some code in xserver that removes an monitor if another > one is added to the same output: That's actually

Re: [Xcb] pthread stubs in libX11 vs. libxcb

Alan Coopersmith writes: > I'm not familiar with the runtime linkers on all platforms, but I know at > least > on Solaris, lazy loading won't load the library until the first reference to > it > is made (or a search needs to be made for a reference that doesn't have direct > binding

Re: pthread stubs in libX11 vs. libxcb

Alan Coopersmith writes: > Does anyone disagree? Yeah, synchronizing with xcb seems 'obviously right. The only question I've got is that in 2022, should xcb ever use stubs for the thread functions? -- -keith signature.asc Description: PGP signature

Re: XRenderComposite Tie To Vsync

Ismael Luceno writes: > AFAIK XRender can't do vsync. You may want to use OpenGL for > everything, or even just for the presentation step in order to do > the vsync... GL and Vulkan use the Present extension, which can also be used by other X applications. -- -keith signature.asc

Re: XRenderComposite Tie To Vsync

Ismael Luceno writes: > AFAIK XRender can't do vsync. You may want to use OpenGL for > everything, or even just for the presentation step in order to do > the vsync... GL and Vulkan use the Present extension, which can also be used by other X applications. -- -keith signature.asc

Re: XRender With Vsync

Ryan McClue writes: > I want this to sync with the monitor's VBLANK, i.e. vsync. > How can this be achieved? Draw to an offscreen pixmap and use the Present extension. -- -keith signature.asc Description: PGP signature

Re: XInitThreads multiple times

Dawid Kowalczyk writes: > Hello, > > Is it possible to call |XInitThreads| multiple times, for example 20 > times and not worry who calls it first? XInitThreads isn't re-entrant, so you need to ensure that it isn't getting invoked by multiple threads in parallel, but it does check to see if it

[ANNOUNCE] libXres 1.2.1

Alan Coopersmith (2): Update README for gitlab migration Update configure.ac bug URL for gitlab migration Keith Packard (2): Note ABI of XResQueryClientIds libXres 1.2.1 Ray Strode (1): XRes: Use _XRead instead of _XRead32 for reading pid git tag: libXres-1.2.1

[ANNOUNCE] libXres 1.2.1

Alan Coopersmith (2): Update README for gitlab migration Update configure.ac bug URL for gitlab migration Keith Packard (2): Note ABI of XResQueryClientIds libXres 1.2.1 Ray Strode (1): XRes: Use _XRead instead of _XRead32 for reading pid git tag: libXres-1.2.1

Re: RFC: New libxcvt library

Olivier Fourdan writes: > Can we consider moving “libxcvt” to the xorg/lib namespace in gitlab? Seems like a good plan to me; I've had several requests to add CVT support to xrandr and haven't done so because it would have involved pulling in a ton of code or creating a library like this :-)

Re: Fwd: The importance of mutual authentication: Local Privilege Escalation in X11

Roberto Ragusa writes: > Wouldn't this make it impossible to run processes under different users > by using xauth and export DISPLAY=:0 ? As long as the other user has access to the specified path, processes will be able to connect to the server. -- -keith signature.asc Description: PGP

[ANNOUNCE] libX11 1.7.0

n some keyboards Keith Packard (6): Don't cache converters in _Xlcmbtowc and Xlcwctomb Don't attempt to unload locale context data Avoid recursing through _XError due to sequence adjustment Copy locale modifiers when creating XimInstCallback [v2] Update libX11 .so version to

[ANNOUNCE] libX11 1.7.0

n some keyboards Keith Packard (6): Don't cache converters in _Xlcmbtowc and Xlcwctomb Don't attempt to unload locale context data Avoid recursing through _XError due to sequence adjustment Copy locale modifiers when creating XimInstCallback [v2] Update libX11 .so version to

Re: AW: AW: AW: Preparing for libX11 1.7.0

Walter Harms writes: > nobody expects this to become bug free. The point was to raise awareness that > the > same class (heap-use-after-free) are still reported. Yup, it's important to realize that while this class of bugs don't *seem* important, they often lead to very difficult to diagnose

[ANNOUNCE] xprop 1.2.5

Jason Nader (1): Add missing `-help` function Keith Packard (5): Make output with unknown width terminal the same as old code Free string list returned from XmbTextPropertyToTextList Correct icon buffer width computation for truecolor terminals Check return value

Re: AW: AW: Preparing for libX11 1.7.0

I've posted an MR for version 1.7.0 that includes release notes added to the README.md. It might be useful to include links to bugs known to be addressed with this release as well? -- -keith signature.asc Description: PGP signature ___

Thinking about xprop-1.2.5

Pierre-Loup Griffais helped his kid make some fun changes in xprop -- it can now display icons in full color, and it checks the terminal width when displaying icons. Plus there's a new '-help' option added by Jason Nader. Unless anyone else is thinking about doing development here, I figure we

Re: AW: Preparing for libX11 1.7.0

Vittorio Zecca writes: > Even easier to reproduce running /usr/bin/wish if you have tk installed. I run wish (for 'gitk') many times a day and haven't seen any thing amiss, so it could be something in your environment causing trouble. > If there is a fix to this issue plese let me know it so I

Re: AW: Preparing for libX11 1.7.0

Alan Coopersmith writes: > https://lists.x.org/archives/xorg/2020-November/060510.html I've reviewed this message and believe that this issue has already been fixed on Xlib master -- Jacek Caban provided a set of fixes over three years ago which have been merged along with some small additional

Re: AW: Preparing for libX11 1.7.0

Alan Coopersmith writes: > Unfortunately, it only seems to have been sent to the mailing list, > not filed in the bug tracker: > > https://lists.x.org/archives/xorg/2020-November/060510.html Thanks, Alan. Should we wait and see if more information about this bug appears before finalizing a

Re: AW: Preparing for libX11 1.7.0

Walter Harms writes: > before the actions start, > i would like to point out that Vittorio Zecca reported a > use-after-free in LibX11. It is reproduceable and it is found with > libtk. Do you have any references to a bug report about this? -- -keith signature.asc Description: PGP signature

Re: Preparing for libX11 1.7.0

Matthieu Herrb writes: > Since a new API was added, the shared lib version number in > src/Makefie.am probably needs to be adjusted too. Good point. I think we want 6:4:0 then? No changed or removed APIs, just new ones, like this? diff --git a/src/Makefile.am b/src/Makefile.am index

Re: Fwd: The importance of mutual authentication: Local Privilege Escalation in X11

Alan Coopersmith writes: > Since this is now public, we can open up the discussion of how to fix it in > public as well, and hope we can make more progress than the security list > did during the embargo phase. I've got a proposed fix for this issue in two merge requests, one for xcb and the

Re: Preparing for libX11 1.7.0

Alan Coopersmith writes: > Since https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/15 > was merged, I was thinking the next release should be 1.7.0 since it has > a new API people may want to check for with pkg-config version checks, > but yes, a new release once things finish

Preparing for libX11 1.6.13

Xlib has seen some useful changes get merged since 1.6.12 and I'm wondering if others agree that we might want to do a 1.6.13 in the near future.h? I'd like to do a release in the next week or so, mostly to avoid having the charge from recent activity leak away. We've got one more important

Re: xserver release process

Adam Jackson writes: > In short, releases need to happen, and we have CI, so let's just pop a > release out on scheduled dates assuming CI passes. WFM -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development

Re: [PATCH xserver] modesetting: typo in drmmode_display.c -- ',' instead of '; ' at end of line

Keith Packard writes: > This seems like a simple typo to me; thanks to C it isn't caught by > the compiler. > > Signed-off-by: Keith Packard Sorry, I didn't find this myself. It was found by Roman Gilg, who should be listed as the author. > --- > hw/xfree86/d

[PATCH xserver] modesetting: typo in drmmode_display.c -- ',' instead of '; ' at end of line

This seems like a simple typo to me; thanks to C it isn't caught by the compiler. Signed-off-by: Keith Packard --- hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86

Re: [PATCH] xfree86/modes: Add "NoOutputInitialSize" option

gt; xf86AssignNoOutputInitialSize(), so that other XFree86 loadable drivers > can use it, even if they don't use xf86InitialConfiguration(). > > Signed-off-by: Andy Ritger Reviewed-by: Keith Packard -- -keith signature.asc Description: PGP signature __

Re: [Xcb] Migrating XCB to GitLab

Daniel Stone writes: > I've done this now, including having moved the bugs over. \o/ Thanks much! -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel

Re: [ANNOUNCE] X Server 1.19.7 maintenance release plan

"Kevin Brace" writes: > Assuming everything goes right, I expect an official maintenance > release around end of February 2019 to early March 2019. Sounds good to me; thanks for stepping in. I'd be happy to help out, let me know what I can do. -- -keith signature.asc Description: PGP

Re: [PATCH app/xcursorgen v3] Update README for gitlab migration

Alan Coopersmith writes: > On 11/13/18 05:13 PM, Ray Strode wrote: >> hi, >> >> On Tue, Nov 13, 2018, 7:57 PM Alan Coopersmith > wrote: >> >> Anyone have a preference?   Shipping README.md seems easier - will it >> cause >> problems for any distros

Re: [PATCH app/xcursorgen v3] Update README for gitlab migration

Alan Coopersmith writes: > 3rd choice - this seems to work for me, shipping a file named README in the > tarball without any Makefile modifications: Yikes! Scary git-fu! Maybe we can see if cmark-gfm is available? That's the github fork that parses more useful common mark syntax files, which

Re: DRM leases + X = SW only OpenGL acceleration on child X server

Raimonds Cicans writes: > Some questions: > 1) Which video drivers support DRM leases? Only amdgpu? Both amdgpu and modesetting. > 2) Which video driver must load child X server? modesetting? Same as > master X server? Only modesetting appears to use xf86DRMMasterFd at this point; adding that

Re: DRM leases + X = SW only OpenGL acceleration on child X server

Michel Dänzer writes: > Looks like drmAuthMagic returns an error for the leased FD in the Xorg > process. > > Keith, was this working for you? At one point, I'm nearly certain it was, but I haven't messed with this in a while. -- -keith signature.asc Description: PGP signature

Re: Sharing a KMS device

Pekka Paalanen writes: > Hi Keith, > > sorry to bump in, but do you mean that a lessee doing drmDropMaster() > will both succeed and drop master also for the lessor (and recursively > through the whole leasing tree up and down as a consequence)? If that call weren't disabled for lessees, then

Re: Sharing a KMS device

Troll Berserker writes: > Hmm. I see that drmDropMaster became conditional: > > if (!ms->fd_passed) > drmDropMaster(ms->fd); That's actually a fix which is necessary so that the lessee doesn't give away control of the whole device. > I was thinking that may be it is possible to

Re: Sharing a KMS device

Troll Berserker writes: > Cool. In your talk you even mentions multiseating. > AFAIU with this technique one doesn't get multiple /dev/dri/card* for > a GPU out of the box, so it is not possible to use unmodified > modesetting driver to run multiple X servers. Correct. I have posted X server

Re: Sharing a KMS device

Troll Berserker writes: > Is it theoretically possible to implement a driver (let's call it > shared-modesetting) which will offload mode setting to a helper daemon > (drmMaster) thus allowing to run multiple Xorg servers on one DRM > device? (provided that there are enough CRTCs (?) available).

Re: Window scaling (aka owner sizes)

Olivier Fourdan writes: > How do you plan to deal with this in your approach? Well, that's why I'm trying to get some help here... What we're trying to do here is replace some really ugly hacks that Valve has made outside of the server to get applications that depend on changing the video mode

Re: Window scaling (aka owner sizes)

Giuseppe Bilotta writes: > By drawing “outside” of their window I don't mean using the window's > own GC context —that would actually work correctly, since it's the one > that gets scaled— but rather using a (grand)parent window such as the > root or vroot window(s). If they did that without

Re: Window scaling (aka owner sizes)

Daniel Stone writes: > It's the other way around. Wayland only has surface-relative > co-ordinates, so we take those and then translate them back into the > X11 global co-ordinate space. Oh, so if we know how XWayland is scaling the output to the screen, then we can translate the coordinates

Re: Window scaling (aka owner sizes)

Robert Mader writes: > I can post my WIP work (will have to clean it up and rebase to current > master). > That said, I'm very interested to see this go forward and am very > willing to help :) I don't know how device coordinates are handled in XWayland, but this mechanism *might* help if you

Re: Window scaling (aka owner sizes)

Giuseppe Bilotta writes: > Wonderful endeavor. Thanks! > I guess the only way in which this can fail is if a client tries to > draw its own decorations (or something) “outside” of their own window, > assuming that origin+width or origin+height actually brings them there > in the root context

Window scaling (aka owner sizes)

I'm doing a bit of work to help support applications that want to run at a small fixed size. The 'usual' way to make them visible on our modern desktops is to flip video modes, but that means everything runs at low resolution, plus you get the adventure of switching modes, which can take a long

Re: [PULL xserver] Remove old colormap special cases from xfree86

f86cmap > > for you to fetch changes up to 5e01650d190fa046a53139a4955b0ef7aedcbaad: > > xfree86: Remove the rest of ->SetOverscan (2018-08-20 14:55:35 > -0400) For the series: Reviewed-by: Keith Packard -- -keith signature.asc Description: PGP signature

Re: [PATCH xserver] randr: rrCheckPixmapBounding should only increase screen size

Alex Goins writes: > Instead, this change simply > makes it so that rrCheckPixmapBounding() will only resize the fb to be larger > than it already is, preventing it from stepping on prior requests to increase > the size of the fb. Seems like a fine plan to me. Reviewed-by: K

Re: [PATCH xserver] dix: check_modmap_change() returns Success, not true

an; I see no possibility for confusion here. I saw that check_modmap_change returns -1 for BadValue and then checked to make sure this odd value is fixed up in both ProcXSetDeviceModifierMapping and ProcSetModifierMapping so that this value doesn't get back to the client. Reviewed-by: Keith Packard -

Re: [PATCH xserver 7/7] composite: Implement backing store's Always mode

Adam Jackson writes: > +static Bool > +backed(WindowPtr pWin) > +{ > +for (; pWin; pWin = pWin->parent) > +if (pWin->backStorage) > +return TRUE; > + > +return FALSE; > +} > + Do we need to stop if we find another redirection layer? I think that will break the

Re: [PATCH xserver 6/7] dix: Switch window unmap to mark normally instead of UnmapValData

Adam Jackson writes: > --- > dix/window.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dix/window.c b/dix/window.c > index 55290577d9..34bed93d93 100644 > --- a/dix/window.c > +++ b/dix/window.c > @@ -2870,7 +2870,7 @@ UnmapWindow(WindowPtr pWin, Bool

Re: [PATCH xserver 5/7] dix: Update window state based on paintable not viewable

Adam Jackson writes: > Signed-off-by: Adam Jackson Yeah, this all looks reasonable. > +if (wasPaintable && anyMarked) { > +if (pLayerWin->parent == pWin) > +(*pScreen->MarkWindow) (pWin); > +else { > +WindowPtr ptmp; Argh. Please make the logic fix

Re: [PATCH xserver 4/7] mi: Shortcut miDoCopy/miCopyArea based on paintable not realized

Adam Jackson writes: > Signed-off-by: Adam Jackson Should we just be checking for empty clip lists instead? It's not quite as cheap, but we do catch FullyObscurred in the same check. -- -keith signature.asc Description: PGP signature ___

Re: [PATCH xserver 2/7] mi: miValidateTree based on paintable not viewable

Adam Jackson writes: Reading through this, I don't see what this patch ends up changing -- TreatAsTransparent will always return True for unmapped Always windows, so every place you're checking paintable && !TreatAsTransparent, you could equivalently be checking viewable && !TreatAsTrasparent

Re: [PATCH xserver] Xext: dynamically allocate the PanoramiXDepths[j].vids array

sed invalid reads/writes followed by eventually a double-free abort. > > Reproduced with xorg-integration-tests server test > XineramaTest.ScreenCrossing/* (and a bunch of others). > > Signed-off-by: Peter Hutterer Reviewed-by: Keith Packard (I'd complain about the lack of NULL che

Re: [PATCH xf86-video-amdgpu 0/3] Add RandR lease support [v2]

Michel Dänzer writes: > On 2018-07-07 02:36 AM, Keith Packard wrote: > Well, this is unfortunate timing. Last Friday, I finally got around to > porting these myself, as I had promised I would, but ran out of time for > sending them out before the weekend. Sent out now: Not a pr

[PATCH xf86-video-amdgpu 3/3] Add RandR leases with modesetting driver support [v7]

off. v6: Add meson build infrastructure v7: Make it build on X server 1.13 Remove drmmode_terminate_leases Signed-off-by: Keith Packard Reviewed-by: Adam Jackson --- configure.ac | 18 ++ src/drmmode_display.c | 137 +-

[PATCH xf86-video-amdgpu 1/3] xf86-video-modesetting: Record non-desktop kernel property at PreInit time [v2]

Save any value of the kernel non-desktop property in the xf86Output structure to avoid non-desktop outputs in the default configuration. v2: Support X server 1.13 Signed-off-by: Keith Packard Reviewed-by: Adam Jackson --- configure.ac | 6 ++ src/drmmode_display.c | 15

[PATCH xf86-video-amdgpu 0/3] Add RandR lease support [v2]

When we last saw these patches, they required current X server bits to build, while the project requires that the driver build back to X server 1.13. I've added suitable checks and wrapped the new code in #ifdefs now. If I don't hear any complaints in a few days (given that we're at the boundary

[PATCH xf86-video-amdgpu 2/3] xf86-video-modesetting: Create CONNECTOR_ID properties for outputs [v2]

This lets a DRM client map between X outputs and kernel connectors. v2: Change CONNECTOR_ID to enum -- Adam Jackson Signed-off-by: Keith Packard Reviewed-by: Adam Jackson --- src/drmmode_display.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/src

Re: gitlab migration

Adam Jackson writes: > I don't really see a reason not to move the repos for everything. It's > a pretty invisible change since the old URLs keep working, and I'm > itchy to see CI wired up. Sounds good to me; I was trying to not over-load poor Daniel. If he's up for it, or can use help from

Re: gitlab migration

Adam Jackson writes: > I'd like us to start moving repos and bug tracking into gitlab. I would also like to get to a merge-request model at some point. However, I think we can take this in stages and start by moving the git repos over to gitlab, and then move the bugs over, and finally start

Re: [PATCH xserver] modesetting: Allow a DRM fd to be passed on command line with -masterfd

ith it Sounds good. Here's an updated patch with the usage message change suggested. Thanks for reviewing! From f122451b7f5be985036cae29df7126a7f25cc891 Mon Sep 17 00:00:00 2001 From: Keith Packard Date: Thu, 18 Jan 2018 18:07:29 -0800 Subject: [PATCH xserver] modesetting: Allow a DRM fd to be passed on command line with -

[PATCH xserver 2/2] xfree86: Wrap RRCrtcIsLeased and RROutputIsLeased to check for DIX structures

/show_bug.cgi?id=106772 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960 Signed-off-by: Keith Packard --- hw/xfree86/modes/xf86Crtc.c | 42 ++--- 1 file changed, 34 insertions(+), 8 deletions(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes

[PATCH xserver 1/2] xfree86: Reset randr_crtc and randr_output early in xf86CrtcCloseScreen

The DIX crtc and output structures are freed when their resources are destroyed, which happens before CloseScreen is called. As a result, we know these pointers are invalid and referencing them during any of the remaining CloseScreen sequence will be bad. Signed-off-by: Keith Packard Cc: thellst

[PATCH xserver] xf86-video-modesetting: Lease planes as well if using atomic

If we're using atomic modesetting, then we're also using universal planes, and so the lease we create needs to include the plane. Signed-off-by: Keith Packard --- hw/xfree86/drivers/modesetting/drmmode_display.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/hw

Re: RR Leases use-after-free bug

vered that leasing is broken with current X server master; patches to fix that have been sent to the list under a separate cover. From 509d59ce4f9faa939c83a987aae7552293c8b624 Mon Sep 17 00:00:00 2001 From: Keith Packard Date: Tue, 26 Jun 2018 09:20:00 -0700 Subject: [PATCH xserver] During reset/

[PATCH xserver] xf86-video-modesetting: Don't enable UNIVERSAL_PLANES separately

lease creation which requires planes for each output when universal_planes is enabled. Signed-off-by: Keith Packard --- hw/xfree86/drivers/modesetting/driver.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers

Re: Fw: merging imake fork

Alan Coopersmith writes: > and the most likely outcome will be many people recommending you move > to anything but Imake, and maybe offering to make you the maintainer of > X.Org's > version so we can stop paying attention to it too. I don't think we even want imake in the X.org repository

Re: [PATCH xorgproto 1/2] Remove the use of no-op B16 & B32 bitfield macros in headers

| xargs perl -i -p -e 's{\s+B\d+}{}g' > followed by manual whitespace fixups to preserve visual alignment. > > The #defines for B16 & B32 are left in place to preserve compatibility > in any code that used them outside the xorgproto repo. > > Signed-off-by: Alan Coopersmit

Re: [PATCH xorg-proto] Remove libdir from pc files.

Jeremy Puhlman writes: > Currently the pc files define libdir, however they are installed into > /usr/share, which means they should be architecture agnostic. Makes sense to me; none of these install any libraries. Reviewed-by: Keith Packard -- -keith signature.asc Descriptio

Re: [PATCH xserver] present/wnmd: Preserve window pixmap's screen_x/y on flip

sense. Screen flips are always at 0,0... Reviewed-by: Keith Packard -- -keith signature.asc Description: PGP signature ___ 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] glamor: Enable modifier support for xfree86 too

Adam Jackson writes: > This was left disabled in 1.20.0, it's time to start being sure it > works. > > Signed-off-by: Adam Jackson Yup. Acked-by: Keith Packard -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.

[PATCH xserver] xfree86: Wrap RRCrtcIsLeased and RROutputIsLeased to check for DIX structures

-off-by: Keith Packard --- hw/xfree86/modes/xf86Crtc.c | 42 ++--- 1 file changed, 34 insertions(+), 8 deletions(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index 4aa77a244..dd795f983 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw

Re: [PATCH xserver 1/2] xfree86: Fix O_CLOEXEC usage in lnx_platform

Michel Dänzer <mic...@daenzer.net> writes: > From: Michel Dänzer <michel.daen...@amd.com> > > It was passing O_CLOEXEC as permission bits instead of as a flag. Both are Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc

Re: Stepping back

Alan Coopersmith writes: > While in person discussions can be efficient, I do wonder if limiting > them to people who can travel to XDC is how we end up burning out the > same folks over and over. A good point. With corporate support for desktop computing seeming

Re: Stepping back

Adam Jackson writes: > tl;dr: I will not be release manager for 1.21, nor for anything > thereafter either, and this time that's probably permanent. I'd like to thank you for all of the work you have done and with you all the best in your next adventures. > As for what this

Re: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages

Alexander Volkov writes: > libxcb stores received file descriptors in the buffer of size 16 > (XCB_MAX_PASS_FD). > Whether it's possible that the X server will send more than 16 fds in a > single reply > and overflow the libxcb's buffer? It wouldn't be if the X server

Re: [PATCH xserver 0/8] GCC8 warning fixes

Adam Jackson <a...@redhat.com> writes: > gcc 8's buffer size logic got a bit pickier, in mostly reasonable ways, > but -Wmaybe-uninitialized got a lot more speculative. Regardless I'm > tired of seeing warnings in my build logs. (some of these are truly ridiculous, but...)

[PATCH xcb/libxcb] Don't close file descriptors received before associated replies

The X server may send reply file descriptors at any point before the reply itself as the buffering of fds in the socket is separate from reply data. Instead of closing those received early, leave them around in xcb and await the receipt of the associated reply. Signed-off-by: Keith Packard <

Re: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages

Alexander Volkov writes: > Yes, it would be easier to fix this in libxcb, but I believe that it > would be more correct to do this in the X server. At least I want to > try to fix the X server. Hrm. The problem is that there are two streams of data here -- the stream of

Re: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages

Alexander Volkov writes: > Otherwise a client may receive data with an unrelated file > descriptor after calling recvmsg() if its input buffer is not > big enough. In libxcb it may lead to a situation when all > received messages fit the buffer while a message related to >

Re: [PATCH xserver] meson: Add option to set default font path (v2)

reversed, this is Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ 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 08/12] meson: Build cvt and gtf

Adam Jackson writes: > What'd be Real Nice is if xrandr knew how to generate modes for given > sizes. Yeah, I've started to add cvt to xrandr a couple of times but never finished. Would also be nice to let you add a mode, associate with an output and set that mode all in one

Re: [PATCH xserver 05/12] meson: Build Xorg suid wrapper

Adam Jackson writes: > Probably this path should add a warning() to alert the builder? Yeah, probably. -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives:

Re: [PATCH xserver 12/12] meson: Fix install path for 10-quirks.conf

Adam Jackson <a...@redhat.com> writes: > Signed-off-by: Adam Jackson <a...@redhat.com> Almost got me with this one -- autotools uses XF86CONFIGDIR but offers no way to configure it. Hardcoding the name seems just fine to me. Reviewed-by: Keith Packard <kei...@keith

Re: [PATCH xserver 11/12] meson: Install xorg-server.m4

Adam Jackson <a...@redhat.com> writes: > Signed-off-by: Adam Jackson <a...@redhat.com> Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org devel

Re: [PATCH xserver 10/12] meson: Generate xorg-server.pc

Adam Jackson <a...@redhat.com> writes: > Otherwise external drivers can't build against us. > > Signed-off-by: Adam Jackson <a...@redhat.com> Acked-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature _

Re: [PATCH xserver 09/12] meson: Install the dmx utilities

Adam Jackson <a...@redhat.com> writes: > And add the forgotten dmxrminput to the list. Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development

Re: [PATCH xserver 08/12] meson: Build cvt and gtf

Adam Jackson <a...@redhat.com> writes: > Signed-off-by: Adam Jackson <a...@redhat.com> These shouldn't be in the X server sources, but... Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___

Re: [PATCH xserver 07/12] meson: Install man pages

Adam Jackson <a...@redhat.com> writes: > Signed-off-by: Adam Jackson <a...@redhat.com> I have no idea if this works correctly, but we certainly need it if it does, so: Acked-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Descr

Re: [PATCH xserver 06/12] meson: Add option to set default font path

Adam Jackson <a...@redhat.com> writes: > +option('default_font_path', type: 'string', > + value: 'catalogue:/etc/X11/fontpath.d,built-ins') This isn't the autotools default; seems like you should probably just use that? Otherwise, Reviewed-by: Keith Packard <ke

Re: [PATCH xserver 05/12] meson: Build Xorg suid wrapper

> +c_args: xorg_c_args, > +install: true, > +install_dir: get_option('libexecdir'), > +# install_mode: ['r-sr-xr-x', 0, 0], I assume your package files fix the permissions? If I'm reading the autotools version, there's a chown and chmod for that? Othe

Re: [PATCH xserver 04/12] meson: Fix installing protocol.txt

Adam Jackson <a...@redhat.com> writes: > One fix the constructed path, two actually install it. > > Signed-off-by: Adam Jackson <a...@redhat.com> Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc

Re: [PATCH xserver 03/12] meson: Add libdrm to hw/xfree86/common's dependencies

Adam Jackson <a...@redhat.com> writes: > Signed-off-by: Adam Jackson <a...@redhat.com> How did this ever work? Acked-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-dev

Re: [PATCH xserver 01/12] autotools: Stop caring about XORG_DATE

Adam Jackson <a...@redhat.com> writes: > Signed-off-by: Adam Jackson <a...@redhat.com> Acked-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org devel

  1   2   3   4   5   6   7   8   9   10   >