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 => include/X11/extensions/dri3proto.h (100%)
diff --git
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 b/meson.build
new file mode 100644
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 INSTALL
+EXTRA_DIST = me
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 to
>Понедельник, 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) so that the incor
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 ProcRR
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 @@ _X_ATTRIBUTE_PRINTF(1, 0)
_X
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.
Signed-off-by:
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
+++ b/hw/kdrive/src/kdri
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
hw/xfree86/common/xf86
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| 17 +++---
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 sig
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 SSE
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 and
> why the cu
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 fixing it in FOO
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 wo
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
---
hw/xfree86/drivers/modesetting/driver.c
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 insertions(+), 22 deletions(-)
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 +++
1 fil
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 dock
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 insertions(+), 52 deletions(
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 connec
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 +++---
hw/xfree86/drivers/modesetting/drmmode_display.
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 ser
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
b/hw/xfree86/drivers/modesetting/drmmo
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
b/hw/xfree86/drivers/modeset
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
b/hw/xfree86/drivers/modesetting/drm
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 -
hw/xfree86/drivers/modesetting/drmmode_d
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 a/hw/xfree86/drivers/modesettin
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
So, we don't rely on the mode_output member.
Signed-off-by: Daniel Martin
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 28 +++-
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/mod
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
-
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 a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/d
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 100644
--- a/os/xdmcp.c
+++ b/os/xdmcp.c
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;
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
--- a/hw/xfree86/drivers/modesetting/driver.h
+++ b/hw/x
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
--
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 a/hw/xfree86/drivers/modesettin
(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: http://lists.x.org/archive
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
> I
--
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 #103820
X.org BUG 1038
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 lockup
42 matches
Mail list logo
