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

hi, On Tue, Nov 13, 2018, 7:57 PM Alan Coopersmith Anyone have a preference? Shipping README.md seems easier - will it cause > problems for any distros or packagers? > i think README.md is the right way to go. presumably any packaging challenges have been ironed out by now considering how

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

hi, On Mon, Oct 1, 2018, 1:11 PM Alan Coopersmith wrote: > Does anyone have feedback on changing our README's like this? it should probably be renamed README.md so it shows up in the gitlab view better. Ray ___ xorg-devel@lists.x.org: X.Org

Re: Xorg-1.20.1 crashes when using glamor on top of llvmpipe

hi, what version of mesa? might be https://cgit.freedesktop.org/mesa/mesa/commit/?id=9baff597ce021f7691187b0d1d1bbc16d07b13e1 Ray On Thu, Aug 30, 2018, 5:00 PM Hans de Goede wrote: > Hi, > > On 30-08-18 22:48, Hans de Goede wrote: > > HI all, > > > > I've been debugging some strange

Re: [PATCH xserver 05/10] test: Add a little xinit-like program for starting servers for testing.

Hey cool, On Friday, September 23, 2016, Eric Anholt wrote: > > The normal xinit is racy because it doesn't use -displayfd.  This > implements the bare minimum for testing purposes, using -displayfd to > sequence starting the client, and avoids adding yet another dependency > to

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi, > This still suffers from your priority-starvation-bug. If a simple > ping/pong protocol barrier doesn't solve the issue, why would the > timer? You'd have to put the timer on lowest priority to make that > work, but then again you can do the same for wl_display_sync. Yup, indeed, you're

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi, On Tue, Mar 8, 2016 at 7:09 AM, Daniel Stone wrote: >> If one justification for server-side repeat is that if the compositor >> is hosed and the user cannot see how many characters have been >> repeated, then you could as well solve that in the client too, by >>

Re: [PATCH] Fix NO_LOCAL_CLIENT_CRED build

Hi, On Mon, Jul 6, 2015 at 6:08 PM, Keith Packard kei...@keithp.com wrote: I liked your first version a lot better; looks a lot simpler. An autoconf test might make sense if there was some reason to override it? To be clear, I primarily gave feedback because touched it last. I think it makes

Re: [PATCH] Fix NO_LOCAL_CLIENT_CRED build

Hi, On Thu, Jul 2, 2015 at 12:40 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Makes sense. Revised patch attached. LGTM --Ray ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info:

Re: [PATCH] Fix NO_LOCAL_CLIENT_CRED build

Hi, Yes, I think so. Revised patch attached. I've tested this a few ways and it seems to be working correctly, but it's hard for me to be sure that this is doing the correct thing on all targets. Thanks for working on this! Seems right to me. My only comment is I think have_so_peercred

Re: [PATCH] Fix NO_LOCAL_CLIENT_CRED build

Hi, This is a build fix for MinGW ... Move the check if NO_LOCAL_CLIENT_CRED should be defined to before it's first use. Well, Alan wondered if anyone is actually using NO_LOCAL_CLIENT_CRED, now we know! Patch doesn't look wrong to me, but I wonder if maybe it should get put in

Re: [PATCH 1/2] systemd-logind: filter out non-signal messages from message filter

Hi, Ray, you may want to reduce the number of context lines a bit next time you post patches. Nope, definitely don't. my default config produces patches with a lot of context intentionally. I want driveby readers who aren't motivated enough to go to the source tree to still be able to do a

Re: [PATCH 1/2] systemd-logind: filter out non-signal messages from message filter

Hi, On Fri, Apr 17, 2015 at 10:43 AM, Hans de Goede You may be making life easier for casual reviewers, but you are making life harder for the people actually merging your patches as the chances of a conflict increase enormously with such a large context. Well, we all know how to deal with

[PATCH 2/2] systemd-logind: don't second guess D-Bus default timeout

Signed-off-by: Ray Strode rstr...@redhat.com --- hw/xfree86/os-support/linux/systemd-logind.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/hw/xfree86/os-support/linux/systemd-logind.c b/hw/xfree86/os-support/linux/systemd-logind.c index 57c87c0..4ad41a3

[PATCH 1/2] systemd-logind: filter out non-signal messages from message filter

to filter out all non-signal messages, including spurious message replies. Downstream-bug: https://bugzilla.redhat.com/show_bug.cgi?id=1209347 Signed-off-by: Ray Strode rstr...@redhat.com --- hw/xfree86/os-support/linux/systemd-logind.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw

Re: [PATCH xinit 2/2] startx: Make startx auto display select work with per user /tmp dirs

Hi, Now, I've tried to avoid anything xauth-related, but from the little I know: to support displayfd in startx you'd have to communicate back to startx about the $DISPLAY and do the xauth dance before continuing with the xinit initial client connection. AFAICT, that's the tricky bit about

Re: [PATCH xinit 2/2] startx: Make startx auto display select work with per user /tmp dirs

Hi, You're right I had forgotten that the xauth file needs to contain the displaynr, so there is no easy fix here I'm afraid. That's not true actually. The xauth file can have a display wildcard, but the xauth command doesn't support generating xauth files with display wildcards. I think that

Re: [PATCH xinit 1/2] startx: Fix startx picking an already used display number when -nolock is used

Hi, On Fri, Mar 20, 2015 at 1:01 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: ... Why does displayfd imply nolock? It doesn't really matter why it implies, nolock, I guess. The issue at hand is that it does (and always has) implied nolock. You can't fix that without breaking things that

Re: [PATCH xinit 2/2] startx: Make startx auto display select work with per user /tmp dirs

Hi, On Fri, Mar 20, 2015 at 10:02 AM, Hans de Goede hdego...@redhat.com wrote: If a separate /tmp per user is used the existing auto display select code does not work, add an extra check for the unix socket for the display number existing in /proc/net/unix (linux only). This patch and the

Re: Using systemd-logind Session.TakeControl() from Xorg, input needed

Hi, - Original Message - Ray Strode also said: You can't shut down an X server unless it's in the foreground.. I can remember having done that without problems just yesterday when working on systemd socket activation for the xserver. I've just tried and I can happily kill (normal

Re: Using systemd-logind Session.TakeControl() from Xorg, input needed

Hi, - Original Message - No. gdm uses a single Xserver for the login-screen and for the session. But once you log in multiple times, I think it starts a new Xserver for each. But I am not that familiar with gdm.. * Can gdm pass in the session id, or the pid of the session leader

Re: Using systemd-logind Session.TakeControl() from Xorg, input needed

Hi, - Original Message - No it ain't. If you use DRM, you can run a smooth handover without tearing, flicker or other artifacts. It's not obvious and not documented at all (sadly), but it's possible. You simply avoid doing a full/deep modeset on session activation but instead

Re: [PATCH] config: provide example configuration for multi-seat setups

Hi, (sorry for the slow response on this) On Fri, Jul 12, 2013 at 1:32 PM, Lennart Poettering lenn...@poettering.netwrote: Ray, this would mean gdm would no longer have to call our multi-seat-x tool for seats != seat0 but rather use the normal X binary but pass -config

Re: [PATCH 2/2] Xinit: close stdin to avoid leak of file descriptior to the Xorg session.

Hi, Apparently I wrote this patch like 5 years and promptly forgot about. Matej tracked me down and asked me to chime in. I don't really remember the patch, but it sort of makes sense to me so I'll try to answer any questions about it. What's the point of setsid(2)?  It certainly doesn't fall

Re: [PATCH 2/2] Xinit: close stdin to avoid leak of file descriptior to the Xorg session.

Hi, On Tue, Jul 26, 2011 at 2:57 PM, Jeremy Huddleston jerem...@apple.com wrote: yick... ok, well I'd suggest making that its own patch rather than squashed into the stdin one... I dunno how I feel about it and will let others chime in... It's two pieces of the same thing. There's not much

Re: [PATCH 2/2] Xinit: close stdin to avoid leak of file descriptior to the Xorg session.

Hi, On Tue, Jul 26, 2011 at 4:02 PM, Jeremy Huddleston jerem...@apple.com wrote: IMO, there is a point to closing stdin aside from the setsid(2). My point is, it only solves the problem part way. As an example, say a program wants to ask the user for a password. The program supports asking the

Re: [PATCH 2/2] Xinit: close stdin to avoid leak of file descriptior to the Xorg session.

Hi, On Tue, Jul 26, 2011 at 4:42 PM, Lennart Poettering lenn...@poettering.net wrote: What I am trying to say here basically: if you are planning to invoke setsid() or detach from the controlling tty otherwise in the normal X servers, then you'll break existing code. And I'd like to ask you

Re: [PATCH 2/2] Xinit: close stdin to avoid leak of file descriptior to the Xorg session.

Hi, Well, the problem you are reporting is 2 parted, hence you should have 2 commits.  The stdin closing is an issue in its own right and should be a separate patch. Okay, i'll look into splitting up the patch and follow up to your other points later. --Ray