Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
On Sun, 09 Apr 2017 10:27:31 -0700 Keith Packard wrote: > Pekka Paalanen writes: > > > we need some kind of a database to recognize HMDs in any case, right? > > It would be best if the database was shared, so that everyone could > > recognize all HMDs, at least as far as one can do that based on EDID. > > Yeah, I think you've got some good ideas here. Here are some questions > which this raises: > > * What should we do with an HMD which is in the database but for which >no application is installed on the host? IMHO, if nothing is providing a picture intended for the HMD, the HMD should be off. There is no use in showing an arbitrary image that does not look right, is there? For the rest of the questions I can't really say anything, except that even if the database was just a bunch of files, you still need code to access it, and probably something to ensure the entries are well-formed, so that everyone will agree on how to parse them. One should probably decide whether the database will only answer the question "is it a HMD?" or can it provide other information as well. Thanks, pq pgppgKxp5qBhl.pgp Description: OpenPGP digital 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
[PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending connector's
link-status to BAD and send the userspace a hotplug event. This may
happen right after a modeset or later on.
Upon receiving a hot-plug event, we iterate through the connectors to
re-apply the currently-set mode on all the connectors that have a
link-status property set to BAD. This modeset may fail immediatly if
the kernel has already pruned the mode we are trying to set but it
does not matter as -modesetting has no business picking another
mode if the modeset did fail. To make users aware of this problem
a warning is outputed in the logs to warn about having a
potentially-black display.
This patch does not modify the current behaviour of always propagating
the events to the randr clients. This allows desktop environments to
re-probe the connectors and select a new resolution based on the new
(currated) mode list if a mode disapeared. This behaviour is expected in
order to pass the Display Port compliance tests.
Signed-off-by: Martin Peres
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 51
1 file changed, 51 insertions(+)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index c1e489e48a..516eb76915 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -2253,6 +2253,10 @@ drmmode_setup_colormap(ScreenPtr pScreen, ScrnInfoPtr
pScrn)
}
#ifdef CONFIG_UDEV_KMS
+
+#define DRM_MODE_LINK_STATUS_GOOD 0
+#define DRM_MODE_LINK_STATUS_BAD1
+
static void
drmmode_handle_uevents(int fd, void *closure)
{
@@ -2272,6 +2276,49 @@ drmmode_handle_uevents(int fd, void *closure)
if (!found)
return;
+/* Try to re-set the mode on all the connectors with a BAD link-state:
+ * This may happen if a link degrades and a new modeset is necessary, using
+ * different link-training parameters. If the kernel found that the current
+ * mode is not achievable anymore, it should have pruned the mode before
+ * sending the hotplug event. Try to re-set the currently-set mode to keep
+ * the display alive, this will fail if the mode has been pruned.
+ * In any case, we will send randr events for the Desktop Environment to
+ * deal with it, if it wants to.
+ */
+for (i = 0; i < config->num_output; i++) {
+xf86OutputPtr output = config->output[i];
+drmmode_output_private_ptr drmmode_output = output->driver_private;
+uint32_t con_id = drmmode_output->mode_output->connector_id;
+drmModeConnectorPtr koutput;
+
+/* Get an updated view of the properties for the current connector and
+ * look for the link-status property
+ */
+koutput = drmModeGetConnectorCurrent(drmmode->fd, con_id);
+for (j = 0; koutput && j < koutput->count_props; j++) {
+drmModePropertyPtr props;
+props = drmModeGetProperty(drmmode->fd, koutput->props[j]);
+if (props && props->flags & DRM_MODE_PROP_ENUM &&
+!strcmp(props->name, "link-status") &&
+koutput->prop_values[j] == DRM_MODE_LINK_STATUS_BAD) {
+xf86CrtcPtr crtc = output->crtc;
+if (!crtc)
+continue;
+
+/* the connector got a link failure, re-set the current mode */
+drmmode_set_mode_major(crtc, &crtc->mode, crtc->rotation,
+ crtc->x, crtc->y);
+
+xf86DrvMsg(scrn->scrnIndex, X_WARNING,
+ "hotplug event: connector %u's link-state is BAD, "
+ "tried resetting the current mode. You may be left"
+ "with a black screen if this fails...\n", con_id);
+}
+drmModeFreeProperty(props);
+}
+drmModeFreeConnector(koutput);
+}
+
mode_res = drmModeGetResources(drmmode->fd);
if (!mode_res)
goto out;
@@ -2336,6 +2383,10 @@ out_free_res:
out:
RRGetInfo(xf86ScrnToScreen(scrn), TRUE);
}
+
+#undef DRM_MODE_LINK_STATUS_BAD
+#undef DRM_MODE_LINK_STATUS_GOOD
+
#endif
void
--
2.12.1
___
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: Proposal for RandR version 1.6, Leases and EDID-based output grabs
On 04/04/2017 06:48 PM, Keith Packard wrote: Daniel Vetter writes: Yeah I think that's a pretty neat idea to reduce the lease complexity even more. If the VR compositor is unhappy and wants a different mode, it can simply nuke the lease and as for a new one. Forgot to say that :-) Not sure it changes the lease complexity, but it reduces the potential interference with the X server after the lease is created. Hrm. Thinking about the impact on X a bit more, this seems hard - you can't just display the root window in the HMD, so you need a frame buffer to use. The VR compositor can construct this knowing the planned X mode, but, we then have to wire it through the whole X mode set infrastructure, which is not exactly set up to do that. I'll go look at the code in more detail, but I suspect the easiest plan will be to have the VR compositor set its own mode. That may fail if X is consuming too many display resources, but that doesn't seem significantly different from having the lease fail. This doesn't change the kernel API at all, so we can figure out the X bits separately from the kernel bits. Hi, as input from a highly interested future user of such api's: An additional use case beyond VR compositors, at least highly valuable for my kind of apps (= neuroscience / vision science / medical research toolkits) would be to get fullscreen exclusive control over regular outputs / displays. My use cases run about 98% of the time in fullscreen exclusive mode and want as little interference from the windowing system / desktop environment as possible, with as much low level control as possible. It still needs windowed mode for same cases and needs a windowing system up and running. Atm. under X i have to hope that fullscreen unredirection works to get me page flipping for single display monoscopic stimulation and dual-display stereoscopic stuff. And then there's the popular "Regular desktop GUI for interaction" + separate displays for "fullscreen + page flipping for controlled presentation" case. Atm. i have to use custom xorg.confs + dual/multi-x-screen + ZaphodHeads, a static configuration with all the logout/login dance / no display hotplug for configuration change. Workable under X (minus the occasional ZaphodHeads corner case bugs), but somewhat clunky. So if this would give me a plug & play dynamic replacement for ZaphodHeads and xorg.conf fiddling that would be _very_ valuable. The RRCreateLease requests looks as if i could get that for regular non-HMD video outputs as well? And the RRCreateOutputGrab would be mostly to avoid flicker when plugging HMD's or other special purpose devices, but wouldn't be strictly needed for a regular X-client to get a lease on a set of outputs? As far as controllable properties on a lease go, i'd find it very useful if i could have control over framebuffer formats, e.g., being able to select 10 bit scanout formats would be very useful, but is afaik something that X currently doesn't expose with most drivers, especially not for regular desktop mode. Set/Get Gamma tables, dithering properties, other output properties, modesetting would be also important. On X i can do that via RandR, but in the Wayland world, much of this stuff is afaik often restricted to privileged clients or proprietary per-compositor protocols. That's a big upcoming problem for me in the Wayland world, and lease support could be a very good solution for me. If the underlying DRM leases allow me to control this stuff, and Wayland would gain similar extensions to lease outputs for fullscreen exclusive control, i could have one drm/kms backend that can be mostly agnostic of X vs. Wayland / different Wayland compositor flavors. Basically my vote to expose as much flexility in modesetting / properties for the exposed leases as possible on the kernel and X side. thanks, -mario ___ 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 ___ 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: Proposal for RandR version 1.6, Leases and EDID-based output grabs
Mario Kleiner writes: > as input from a highly interested future user of such api's: Thanks much for taking a look at this. > My use cases run about 98% of the time in fullscreen > exclusive mode and want as little interference from the windowing system > / desktop environment as possible, with as much low level control as > possible. It still needs windowed mode for same cases and needs a > windowing system up and running. The new APIs can give you exclusive access to the display resources, bypassing the window system entirely. > Atm. under X i have to hope that fullscreen unredirection works to get > me page flipping for single display monoscopic stimulation and > dual-display stereoscopic stuff. And then there's the popular "Regular > desktop GUI for interaction" + separate displays for "fullscreen + page > flipping for controlled presentation" case. You're still depending on the window system server for timely page flips though; the main reason we're doing the leasing work is to get that variable out of the equation, eliminating any window system scheduling jitter from the regular screen updates on the HMD. > The RRCreateLease requests looks as if i could get that for regular > non-HMD video outputs as well? Yes, there's almost no way we could restrict it even if we wanted to. I'm doing testing with two standard monitors, but any hardware at all will work. > And the RRCreateOutputGrab would be mostly to avoid flicker when > plugging HMD's or other special purpose devices, but wouldn't be > strictly needed for a regular X-client to get a lease on a set of > outputs? Yes, just to avoid having the desktop extend itself onto the HMD, even briefly. The two components of the RandR changes are logically separate, but should be useful in combination when using HMD displays. > As far as controllable properties on a lease go, i'd find it very useful > if i could have control over framebuffer formats, e.g., being able to > select 10 bit scanout formats would be very useful, but is afaik > something that X currently doesn't expose with most drivers, especially > not for regular desktop mode. You have the full KMS api at your disposal; do whatever you like :-) > If the underlying DRM leases allow me to control this stuff, and Wayland > would gain similar extensions to lease outputs for fullscreen exclusive > control, i could have one drm/kms backend that can be mostly agnostic of > X vs. Wayland / different Wayland compositor flavors. Right, that's another benefit here -- allowing HMD applications to be largely window system independent, except for acquiring the initial lease. > Basically my vote to expose as much flexility in modesetting / > properties for the exposed leases as possible on the kernel and X > side. I'll have a second cut of the kernel API changes ready in another day or so; that will eliminate the ability to change an existing lease, so you'll have to acquire all of the resources you need all at once. Otherwise, it will look quite similar at the user API level. The RandR protocol changes will also need another spin; it sounds like we want to configure the set of 'special' monitors and have those never reported as connected via the current API. I don't think that will affect your use case at all, and the other part of the protocol for creating a lease won't change. -- -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: Proposal for RandR version 1.6, Leases and EDID-based output grabs
On Tue, Apr 4, 2017 at 3:02 AM, Daniel Vetter wrote: > On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote: >> Daniel Vetter writes: >> >> > Also if this confuses VR, then another reason why we want to make leases >> > invariant and only allow pure revoke, not changing the list. >> >> I'm not sure why you want this to be asymmetrical, nor why you would >> expect lessees to be any more competent at dealing with hotplug than the >> lessor. >> >> One use case already proposed for this API was to allow for multi-seat, >> where the lessee would be an existing window system, which we already >> accept as being incompetent at dealing with resource hotplug. I imagine >> that in this case, a newly plugged monitor would be detected by the >> multi-seat manager (logind?) and added to one of the existing leases, >> along with a suitable CRTC resource. For this to work, the lessee will >> need to already know about those resources and only have their >> connectivity status hidden. > > The multi-seat thing sounds like vapourware, I think we should care about > the vr use-case for now, and only that one. And for that restricting stuff > is perfectly fine. Of course we can design the entire thing in a way that > doesn't draw us into a corner in the future right away, but that's mostly > on the implementation side. For VR itself I'd go as far as saying that > probably our "create lease" ioctl should have only the semantics we need > to pass one crtc+primary plane for pageflipping in a VR compositor, > expressed in a flag. All the details about additional corner cases are > just so unclear to me (and there's not even a clear use case that will > materialize) that I don't think having the uapi is worth it. Too close to > the "I'll regret this immediately" bucket :-) > I don't know about vaprware. There were a number of attempts to provide static allocation if display resources over the years to solve things like custom zaphod configs and users wanting to use multiple heads for separate users (which currently ends up in various zephyr hacks IRC). Lots of patches were proposed, none landed. I think there is a definite use case there. Why do we need to make X aware of the lease stuff? What about having some pre-X configuration that decides how to split up the display resources. It could be user defined static or dynamic based on what is attached. You can just start X on the device nodes with whatever resources they are assigned. In the multi-user case, you can statically assign resources to each node; in the VR case, you can detect the HMD and automatically assign it's resources to a separate node or override if necessary. Alex ___ 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 xrandr] Adding a "--filter" flag
On Tue, 2017-04-04 at 17:57 -0700, pdelagarza wrote: > ping :) There was a more elaborate version of something like this a while back: https://lists.freedesktop.org/archives/xorg-devel/2016-April/049284.html - ajax ___ 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: Proposal for RandR version 1.6, Leases and EDID-based output grabs
Alex Deucher writes: > I think there is a definite use case there. I agree. What we're missing right now is someone interested in driving an implementation of that use case to help define the right interfaces. Lacking that, we're not likely to come up with a good solution on our own. I think that's what Daniel is concerned about -- specifying something in the absence of an implementation using it. I took a stab at this and added the ability to change leases on the fly, and to create 'sub-leases' from an existing lease. He's pushing back on those features, and I think his reasons are sound. > Why do we need to make X aware of the lease stuff? What about having > some pre-X configuration that decides how to split up the display > resources. For multi-user, this makes a lot of sense; you'd want the system to allocate resources between users to allow them to operate fairly independently. For single-user with a hot-plugged HMD, I'd suggest that having X involved makes a lot of sense -- you may have to interact with the user to reduce resource consumption so that the HMD can be driven successfully, and that will involve poking at the X configuration. > It could be user defined static or dynamic based on what is attached. > You can just start X on the device nodes with whatever resources they > are assigned. In the multi-user case, you can statically assign > resources to each node; in the VR case, you can detect the HMD and > automatically assign it's resources to a separate node or override if > necessary. I don't think we've precluded this for a multi-user environment, and I think it's a good plan in the abstract. I will, however, suggest that asking for VR applications to wait for the desktop environment to be re-architected so that display resources can be centrally allocated by a new 'display resource manager' seems like a rather steep requirement. What I do want to ensure is that these two use cases can both be supported by the kernel interfaces we define, and that we can work in user space on either design going forward. If you'd like to start exploring the design of such a central service, that'd be awesome. -- -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: Proposal for RandR version 1.6, Leases and EDID-based output grabs
On 04/10/2017 08:11 PM, Keith Packard wrote: Mario Kleiner writes: as input from a highly interested future user of such api's: Thanks much for taking a look at this. My use cases run about 98% of the time in fullscreen exclusive mode and want as little interference from the windowing system / desktop environment as possible, with as much low level control as possible. It still needs windowed mode for same cases and needs a windowing system up and running. The new APIs can give you exclusive access to the display resources, bypassing the window system entirely. Atm. under X i have to hope that fullscreen unredirection works to get me page flipping for single display monoscopic stimulation and dual-display stereoscopic stuff. And then there's the popular "Regular desktop GUI for interaction" + separate displays for "fullscreen + page flipping for controlled presentation" case. You're still depending on the window system server for timely page flips though; the main reason we're doing the leasing work is to get that variable out of the equation, eliminating any window system scheduling jitter from the regular screen updates on the HMD. Yes, and that will be an advantage for me as well, especially for some more exotic situations. That said, in my experience good old X is holding up rather well for page-flipped windows if one gets unredirected fullscreen with no DE interference. I have users which runs a 1920x1080@240 Hz display at 240 fps stable update rates without skipping frames and proper frame accurate timing on AMD gfx with the open-source graphics stack on a standard Ubuntu 16.04 + Server 1.18 :) In fact, it still beats current standard Wayland compositors by a large margin, mostly due to how display update scheduling is done in the current incarnations and because Wayland doesn't have a full DRI/Present or OML_sync_control equivalent yet. The RRCreateLease requests looks as if i could get that for regular non-HMD video outputs as well? Yes, there's almost no way we could restrict it even if we wanted to. I'm doing testing with two standard monitors, but any hardware at all will work. And the RRCreateOutputGrab would be mostly to avoid flicker when plugging HMD's or other special purpose devices, but wouldn't be strictly needed for a regular X-client to get a lease on a set of outputs? Yes, just to avoid having the desktop extend itself onto the HMD, even briefly. The two components of the RandR changes are logically separate, but should be useful in combination when using HMD displays. As far as controllable properties on a lease go, i'd find it very useful if i could have control over framebuffer formats, e.g., being able to select 10 bit scanout formats would be very useful, but is afaik something that X currently doesn't expose with most drivers, especially not for regular desktop mode. You have the full KMS api at your disposal; do whatever you like :-) If the underlying DRM leases allow me to control this stuff, and Wayland would gain similar extensions to lease outputs for fullscreen exclusive control, i could have one drm/kms backend that can be mostly agnostic of X vs. Wayland / different Wayland compositor flavors. Right, that's another benefit here -- allowing HMD applications to be largely window system independent, except for acquiring the initial lease. Great! Haven't looked at your patches yet, only at this thread and your blog, but this sounds all very promising. Basically my vote to expose as much flexility in modesetting / properties for the exposed leases as possible on the kernel and X side. I'll have a second cut of the kernel API changes ready in another day or so; that will eliminate the ability to change an existing lease, so you'll have to acquire all of the resources you need all at once. Otherwise, it will look quite similar at the user API level. The RandR protocol changes will also need another spin; it sounds like we want to configure the set of 'special' monitors and have those never reported as connected via the current API. I don't think that will affect your use case at all, and the other part of the protocol for creating a lease won't change. Yes, sounds like i could deal with that. -mario ___ 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 xrandr] Adding a "--filter" flag
Hi Adam, Thank you for taking the time to look at my patch. I saw the one you are referring to, but that one for some reason never got integrated. Which one do you prefer? Thanks, Pablo On Mon, 10 Apr 2017, Adam Jackson wrote: > On Tue, 2017-04-04 at 17:57 -0700, pdelagarza wrote: > > ping :) > > There was a more elaborate version of something like this a while back: > > https://lists.freedesktop.org/archives/xorg-devel/2016-April/049284.html > > - ajax > ___ 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: Proposal for RandR version 1.6, Leases and EDID-based output grabs
Mario Kleiner writes: > Great! Haven't looked at your patches yet, only at this thread and your > blog, but this sounds all very promising. I'll write up another blog post when I finish with the first round of review. That should describe the kernel API at least. I think the X API will be pretty simple though -- tell me which output and crtc and I'll hand you a lease for those. -- -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] modesetting: re-set the crtc's mode when link-status goes BAD
Martin Peres writes: > Despite all the careful planing of the kernel, a link may become > insufficient to handle the currently-set mode. At this point, the > kernel should mark this particular configuration as being broken > and potentially prune the mode before setting the offending connector's > link-status to BAD and send the userspace a hotplug event. This may > happen right after a modeset or later on. > > Upon receiving a hot-plug event, we iterate through the connectors to > re-apply the currently-set mode on all the connectors that have a > link-status property set to BAD. This modeset may fail immediatly if > the kernel has already pruned the mode we are trying to set but it > does not matter as -modesetting has no business picking another > mode if the modeset did fail. To make users aware of this problem I think I'd like to replace the "This modeset" sentence with "The kernel may be able to get the link to work by dropping to using a lower link bpp (with the same display bpp). However, the modeset may fail if the kernel has pruned the mode, so to make users aware..." Does that sound good to you? I'll give this patch a day or two for anyone else to complain, then I'll push. > a warning is outputed in the logs to warn about having a > potentially-black display. > > This patch does not modify the current behaviour of always propagating > the events to the randr clients. This allows desktop environments to > re-probe the connectors and select a new resolution based on the new > (currated) mode list if a mode disapeared. This behaviour is expected in > order to pass the Display Port compliance tests. > > Signed-off-by: Martin Peres 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
[PATCH xserver 1/2] README: HTTPS everywhere
All fd.o HTTP services are now HTTPS-only (with redirects, but still). Signed-off-by: Daniel Stone --- README | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README b/README index b2499a059..d95aacb21 100644 --- a/README +++ b/README @@ -11,12 +11,12 @@ and draggable titlebars and borders. For a comprehensive overview of X Server and X Window System, consult the following article: -http://en.wikipedia.org/wiki/X_server +https://en.wikipedia.org/wiki/X_server All questions regarding this software should be directed at the Xorg mailing list: -http://lists.freedesktop.org/mailman/listinfo/xorg +https://lists.freedesktop.org/mailman/listinfo/xorg Please submit bug reports to the Xorg bugzilla: @@ -26,13 +26,13 @@ The master development code repository can be found at: git://anongit.freedesktop.org/git/xorg/xserver -http://cgit.freedesktop.org/xorg/xserver +https://cgit.freedesktop.org/xorg/xserver For patch submission instructions, see: - http://www.x.org/wiki/Development/Documentation/SubmittingPatches + https://www.x.org/wiki/Development/Documentation/SubmittingPatches For more information on the git code manager, see: -http://wiki.x.org/wiki/GitPage +https://wiki.x.org/wiki/GitPage -- 2.12.2 ___ 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
[PATCH xserver 2/2] README: Add link to fd.o CoC
The Contributor Covenant applies to all fd.o-hosted resources, including lists and Bugzilla. Add a note to the README, reminding people to act like human beings. Signed-off-by: Daniel Stone --- README | 6 ++ 1 file changed, 6 insertions(+) diff --git a/README b/README index d95aacb21..529526d18 100644 --- a/README +++ b/README @@ -36,3 +36,9 @@ For more information on the git code manager, see: https://wiki.x.org/wiki/GitPage +As with other projects hosted on freedesktop.org, X.Org follows its +Code of Conduct, based on the Contributor Covenant. Please conduct +yourself in a respectful and civilized manner when using the above +mailing lists, bug trackers, etc: + + https://www.freedesktop.org/wiki/CodeOfConduct -- 2.12.2 ___ 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
