[PATCH dri3proto 1/3] autotools: Move headers into include folders

This will be used by meson. Signed-off-by: Dylan Baker --- Makefile.am | 2 +- dri3proto.h => include/X11/extensions/dri3proto.h | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename dri3proto.h =>

[PATCH dri3proto 3/3] autotools: distribute meson.build in tarball

Signed-off-by: Dylan Baker --- Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.am b/Makefile.am index 5f078e0..e4b071d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -8,6 +8,8 @@ dist_doc_DATA = dri3proto.txt MAINTAINERCLEANFILES = ChangeLog

[PATCH dri3proto 2/3] meson: Add meson build

This does everything the autotools build does, except modify the git config. Signed-off-by: Dylan Baker --- meson.build | 44 1 file changed, 44 insertions(+) create mode 100644 meson.build diff --git a/meson.build

Re: [PATCH dri2proto 0/3] meson build system for dri2proto

Quoting Dylan Baker (2017-11-06 12:37:59) > This is basically just like the glproto patches, but with meson.build > distrubuted in the autotools generated tarball. > > Dylan Baker (3): > Move headers into structured include directory > meson: add meson support > autotools: Add meson.build

Re[2]: [PATCH xserver] xfree86/common: Fix VT leave lockup #103782

>Понедельник, 20 ноября 2017, 11:06 +03:00 от Michal Srb : > >If you unlock it in xf86VTLeave, you will get a double unlock in xf86VTEnter. Argh. You're absolutely right, thanks! I'll resend the updated version (which locks the input mutex again at the beginning of xf86VTEnter)

Re: [PATCH xserver 0/3] randr valgrind cleanups

On Thu, 2017-11-09 at 10:21 +0100, Giuseppe Bilotta wrote: > These three small patches replace and complement my previous “randr: properly > cleanup on crtc and output destroy”. > > The first one cleans up another bit of unitialized memory being sent over the > wire (similar to the previous

[PATCH xserver 6/6] os: Remove unused OsRegisterSigWrapper

Signed-off-by: Adam Jackson --- include/os.h | 3 --- os/osinit.c | 19 --- 2 files changed, 22 deletions(-) diff --git a/include/os.h b/include/os.h index e141a6b02c..593c784753 100644 --- a/include/os.h +++ b/include/os.h @@ -297,12 +297,9 @@

[PATCH xserver 3/6] os: Make OsSignalHandler ask for core dumps for signo != SIGQUIT

SIGQUIT is a normal termination request, but any other signal we handle here wants a core. This has the effect of making FatalError's call to AbortServer trigger the if (CoreDump) OsAbort(); path. This will allow us to remove some DDX code that has the same net effect.

[PATCH xserver 0/6] Signal handling cleanups

I started writing a review of Olivier's patch and got sidetracked. I can't really think of a good reason _not_ to generate a core if possible, even for xfree86, and I think things look a lot simpler if we do: hw/kdrive/src/kdrive.c | 14

[PATCH xserver 4/6] xfree86: remove xf86CaughtSignal etc.

This no longer does anything useful. Signed-off-by: Adam Jackson --- hw/xfree86/common/xf86.h| 2 -- hw/xfree86/common/xf86Events.c | 11 --- hw/xfree86/common/xf86Globals.c | 1 - hw/xfree86/common/xf86Helper.c | 6 -- hw/xfree86/common/xf86Init.c|

[PATCH xserver 2/6] xfree86: Remove xf86InterceptSignals

The only consumer of this is the Linux vm86 backend for int10 (which you should not use), and there all it serves to do is make signals generated by the vm86 task non-fatal. In practice this error appears never to happen, and marching ahead with root privileges after arbitrary code has raised a

[PATCH xserver 5/6] kdrive: remove KdSignalWrapper etc.

This no longer does anything useful. Signed-off-by: Adam Jackson --- hw/kdrive/src/kdrive.c | 14 -- 1 file changed, 14 deletions(-) diff --git a/hw/kdrive/src/kdrive.c b/hw/kdrive/src/kdrive.c index 82dcf4ae73..6dbb908565 100644 --- a/hw/kdrive/src/kdrive.c +++

[PATCH xserver 1/6] xfree86: Remove xf86InterceptSigIll

This was added in ~2004 for the sis driver, to detect whether it could use SSE for memcpy. Charmingly, the code to check whether that feature exists in the server is: #if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(6,8,99,13,0) #define SISCHECKOSSSE /* Automatic check OS for

Re: Xstartup handle DISPLAY=(null) correctly

On Mon, 2017-11-20 at 13:36 +, Emil Velikov wrote: > On 20 November 2017 at 09:22, walter harms wrote: > > at what circumstances can DISPLAY == '(null)' ? > > > > looks more like a bug in an Xserver. > > > > The commit message should explain where/how such string originates

Re: Xstartup handle DISPLAY=(null) correctly

On 20 November 2017 at 09:22, walter harms wrote: > at what circumstances can DISPLAY == '(null)' ? > > looks more like a bug in an Xserver. > The commit message should explain where/how such string originates and why the current solutions is preferred. Say bug is in A/B/other and

[PATCH xserver] xwayland: Restore default signal handlers

Xwayland is a pretty standard Wayland client, we want to be able to capture core dumps on crashes. Yet using "-core" in the command line is not what we want, because that causes any FatalError() to generate a core dump, meaning that we would get a core file for all Wayland server crashes, which

[PATCH xserver 1/7] modesetting: Check for uevents on EnterVT

We have to re-evaluate the outputs (their ids) before drmmode_set_desired_modes() as it triggers drmmode_set_mode_major(). drmmode_set_mode_major() working with old ids is likely to fail and will tear down the server. Signed-off-by: Daniel Martin ---

[PATCH xserver 6/7] modesetting: Check for vanished outputs after updating output ids

Doing this before updating the output_ids is not a good idea as we compare the output id in the loop and the output id is unreliable. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 51 ++-- 1 file changed, 29

[PATCH xserver 4/7] modesetting: Check mode in drmmode_set_mode_major() first

We don't do anything in drmmode_set_mode_major() without a mode. Check it at the beginning and may bail out. With that, we can remove one indention level. No functional changes. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 165

[PATCH xserver 5/7] modesetting: Fix server crash on failing modeset

This fixes a potential: (EE) modeset(0): failed to set mode: Invalid argument crashing the server on EnterVT. To reproduce the bug you need a laptop (i.e. Lenovo X270), a docking station using MST to connect the outputs (i.e. ThinkPad Ultra Dock) and have at least one active output at the

[PATCH xserver 7/7] modesetting: Squash link-status check into output re-evaluation loop

By using a helper function it looks more streamlined and we don't do to drmModeGetConnectorCurrent() in drmmode_handle_uevents() twice. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 99 +++- 1 file changed, 47

[PATCH xserver 3/7] modesetting: Compare connector info to identify outputs

The output id is unreliable for MST connectors and so is the connector type id. Both can change during hotplugs of MST connectors. The fun part comes if they change while we switched to another VT as one output id may gets re-assigned to another output. The only reliable way to identify MST

[PATCH xserver 2/7] modesetting: Store info to identify a connector

That is the connector_type, connector_type_id and path_blob. We'll identify a connector using this information later, as the output_id is unreliable. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 10 +++---

[PATCH xserver 0/7] modesetting - more stable MST hotpluging

This patchset handles hotpluging of MST connectors. They can be fun, especially if we aren't active (VT switched away) and vanish + reappear. - We have to check for uevents on EnterVT, otherwise we may work with outdated output_ids leading to a failing drmmode_set_mode_major() and tear the

[PATCH xserver 4/6] modesetting: Retrieve drm connector in drmmode_output_detect()

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c

[PATCH xserver 3/6] modesetting: Retrieve drm connector in drmmode_output_create_resources()

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c

[PATCH xserver 6/6] modesetting: Get current connector infos in drmmode_output_init()

No need for modes and connector status probing here. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c

[PATCH xserver 5/6] modesetting: Remove mode_output member from drmmode_output

We failed to handle the mode_output member properly a few times. We can retrieve it at any time, which we do at various places anyway. Remove it. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 21 -

[PATCH xserver 1/6] modesetting: Save number of encoders in drmmode_output

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 13 +++-- hw/xfree86/drivers/modesetting/drmmode_display.h | 1 + 2 files changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH xserver 0/6] modesetting - remove mode_output member

This patchset removes the mode_output member. We failed to handle it correctly in the past and most people won't notice if the do as it requires MST hotpluging. Thanks, Daniel Daniel Martin (6): modesetting: Save number of encoders in drmmode_output modesetting: Retrieve drm connector in

[PATCH xserver 0/6] xdmcp, xfree86, modesetting - fixes and cleanups

This patchset includes: os/xdmcp: Honour -once when session is dead - an old one, that wasn't merged, but got a review xfree86: Fix set but not used warnings in lnx_platform - compiler warnings, pimped commit message, got a review modesetting: Fix log msg if pixmap creation failed -

[PATCH xserver 3/6] modesetting: Fix log msg if pixmap creation failed

Add a missing new-line character and make the message more verbose than "Failed". Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH xserver 1/6] os/xdmcp: Honour -once when session is dead

Terminate a dead session when -once was passed. Don't restart it. Signed-off-by: Daniel Martin Reviewed-by: Walter Harms --- os/xdmcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/os/xdmcp.c b/os/xdmcp.c index 906c95944..7aeb393e6

[PATCH xserver 2/6] xfree86: Fix set but not used warnings in lnx_platform

Those warnings are generated, when building without systemd support: ../hw/xfree86/os-support/linux/lnx_platform.c: In function ‘get_drm_info’: ../hw/xfree86/os-support/linux/lnx_platform.c:29:16: warning: variable ‘minor’ set but not used [-Wunused-but-set-variable] int major, minor, fd;

[PATCH xserver 5/6] modesetting: Remove unused define DRV_ERROR

Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/driver.h | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/xfree86/drivers/modesetting/driver.h b/hw/xfree86/drivers/modesetting/driver.h index 7ea500f5c..08dc3b58a 100644 ---

[PATCH xserver 4/6] modesetting: Reset output_id if drmModeGetConnector failed

If drmModeGetConnector() fails in drmmode_output_detect(), we have to reset the output_id to -1 too. Yet another spot leading to a potential NULL dereference when handling the mode_output member as output_id was != -1. Though, this case should be very hard to hit. Signed-off-by: Daniel Martin

[PATCH xserver 6/6] modesetting: Remove #if 0 CMAP_LOAD_EVEN_IF_OFFSCREEN

CMAP_LOAD_EVEN_IF_OFFSCREEN has been encapsulated since the import of xf86-video-modesetting into the tree. Signed-off-by: Daniel Martin --- hw/xfree86/drivers/modesetting/drmmode_display.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git

Re: [PATCH xserver 00/11] modesetting: Fixes, cleanups and mode_output removal

(Sorry, for not reporting back earlier, had to do internal stuff.) Please ignore this pathset. It's superseded by distinct patchsets I'm going to send. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives:

Re: Xstartup handle DISPLAY=(null) correctly

at what circumstances can DISPLAY == '(null)' ? looks more like a bug in an Xserver. re, wh Am 20.11.2017 06:40, schrieb xiaoguang wang: > > > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel >

Xstartup handle DISPLAY=(null) correctly

-- SUSE Linux Room 1401, World Financial Center, West Tower Beijing, P.R. China, 100020 >From bddc3bea3472edfad9476e952c0599f48d51f921 Mon Sep 17 00:00:00 2001 From: Xiaoguang Wang Date: Mon, 20 Nov 2017 12:40:20 +0800 Subject: [PATCH] xdm: Handle DISPLAY=(null) correctly

Re: [PATCH xserver] xfree86/common: Fix VT leave lockup #103782

On čtvrtek 16. listopadu 2017 21:28:05 CET Алексей Шилин wrote: > When xf86VTSwitchAway() returns true to xf86VTLeave(), the input > mutex does not get unlocked. As the result, any other thread which > later tries to execute input_lock() freezes forever, which in turn > may lead to X server