From: Michel Dänzer
---
Unfortunately, this doesn't help for DRI3 clients hanging waiting for the
reply from the DRI3Open request with display connections forwarded via
SSH (see https://bugs.freedesktop.org/show_bug.cgi?id=93261), because the
SSH proxy client appears local to the X server. This
Analogous to Xnest implementation at 83fef4235db86343477b4ec9858c6ba35e1aa7d9.
v2 changes:
- Keep struct KdKeyboardInfo untouched.
- Move XkbApplyMappingChange()+XkbDDXChangeControls() call to
EphyrKeyboardInit(), since it doesn't apply for e.g. kdrive evdev driver.
- Call kdrive keyboar
2015-12-04 15:41 GMT-02:00 Daniel Stone :
> No, you can't. But, for full bonus doing-it-properly points, you'd
> want to get the XKB keymap in full (not the butchered core version)
> from the host server, and then supply that directly at init time, via
> an extra argument to InitKeyboardDeviceStru
On Fri, 2015-12-04 at 14:16 -0200, Guilherme Quentel Melo wrote:
> diff --git a/glx/glxext.c b/glx/glxext.c
> index e41b881..16b8039 100644
> --- a/glx/glxext.c
> +++ b/glx/glxext.c
> @@ -469,6 +469,24 @@ __glXForceCurrent(__GLXclientState * cl, GLXContextTag
> tag, int *error)
>
> /* Make
On Fri, 2015-12-04 at 12:30 +, Bob Ham wrote:
> The configure script looks for the libsystemd-daemon pkg-config
> module. If the configure script finds it, the script will add
> libsystemd-daemon to a list of modules which are used to consolidate
> CFLAGS and LIBS.
>
> The check for libsystem
On Fri, 2015-12-04 at 10:15 +0100, Hans de Goede wrote:
> Hi,
>
> On 03-12-15 11:05, Laércio de Sousa wrote:
> > Since non-seat0 X servers no longer touch VTs,
> > I believe these settings are unnecessary.
> >
> > Signed-off-by: Laércio de Sousa
>
> Thanks, you're right keeptty is not used when
Starting Xnest with (say) -scrns 2 and running xdpyinfo against it
results in a crash on cursor cleanup:
(EE) Backtrace:
(EE) 0: ./hw/xnest/Xnest (OsSigHandler+0x29) [0x468ba9]
(EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x30d7034a4f]
(EE) 2: ./hw/xnest/Xnest (xnestUnrealizeCursor
Michel Dänzer writes:
> This commit broke input for me with xf86-input-libinput. No keyboard or
> mouse input is received. There are no errors in the log file.
>
> xf86-input-evdev works.
Ok, I spent some time yesterday figuring out what happened here. The
issue is that xf86-input-libinput is us
Hi,
Am 08.12.2015 um 13:46 schrieb Laércio de Sousa:
[...]
> diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
> index 49516bb..249b210 100644
> --- a/hw/kdrive/ephyr/hostx.c
> +++ b/hw/kdrive/ephyr/hostx.c
[...]
> @@ -1086,18 +1085,105 @@ hostx_paint_debug_rect(KdScreenInfo *screen,
By the time we get to ComputeLocalClient, we've already done
NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
we're built with #define CLIENTIDS), so we can look up the name of the
client process and refuse to treat ssh's X forwarding as if it were
local.
Signed-off-by: Adam J
On Tue, 2015-12-08 at 13:55 -0500, Adam Jackson wrote:
> By the time we get to ComputeLocalClient, we've already done
> NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
> we're built with #define CLIENTIDS), so we can look up the name of the
> client process and refuse to treat
Am 08.12.2015 19:55, schrieb Adam Jackson:
> By the time we get to ComputeLocalClient, we've already done
> NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
> we're built with #define CLIENTIDS), so we can look up the name of the
> client process and refuse to treat ssh's X f
On Tue, 2015-12-08 at 20:09 +0100, walter harms wrote:
> unfortunately, that means if my client is called
> "the_exceptional_secure_shell" it would break, right ?
"Break" in the sense of "be exactly as broken as it already is", sure.
> there i would ask, could that be made on option ?
> (default
On 2015-12-08 13:55, Adam Jackson wrote:
> By the time we get to ComputeLocalClient, we've already done
> NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
> we're built with #define CLIENTIDS), so we can look up the name of the
> client process and refuse to treat ssh's X forwa
On Tue, 2015-12-08 at 14:14 -0500, Peter Harris wrote:
> Was sshd never updated to take advantage of "dix: Extend initial
> connection handshake for forwarding proxies"?
Nope. I'm quite sure I had a patch for that once upon a time, which
I've not been able to find. I should rewrite that too, I su
Signed-off-by: Adam Jackson
---
Xext/xres.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/Xext/xres.c b/Xext/xres.c
index 83cc691..5d3faa3 100644
--- a/Xext/xres.c
+++ b/Xext/xres.c
@@ -274,6 +274,24 @@ ResFindAllRes(void *value, XID id,
It probably doesn't work very well since there's other extension setup
we're not doing on this path, and in any event it's not a thing that
happens currently.
Signed-off-by: Adam Jackson
---
Xext/sync.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/Xext/sync
On 12/ 8/15 11:31 AM, Adam Jackson wrote:
What I'd really prefer is that forwarding proxies (including ssh)
implement support for the extended connection handshake, which allows
the client to ask to be treated as non-local:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=e2c7d70e5ddb8b17676a
Signed-off-by: Adam Jackson
---
hw/dmx/config/dmxconfig.c | 2 +-
hw/dmx/config/dmxparse.h | 2 --
hw/dmx/config/dmxtodmx.c | 1 +
hw/dmx/config/parser.y | 1 +
hw/dmx/config/scanner.l| 6 --
hw/dmx/config/xdmxconfig.c | 1 +
6 files changed, 8 insertions(+), 5 deletions(-)
diff
Signed-off-by: Adam Jackson
---
hw/dmx/glxProxy/glxsingle.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/dmx/glxProxy/glxsingle.c b/hw/dmx/glxProxy/glxsingle.c
index 79d426b..e254936 100644
--- a/hw/dmx/glxProxy/glxsingle.c
+++ b/hw/dmx/glxProxy/glxsingle.c
@@ -804,
Signed-off-by: Adam Jackson
---
hw/dmx/config/dmxcompat.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/hw/dmx/config/dmxcompat.c b/hw/dmx/config/dmxcompat.c
index 107991a..6d31b53 100644
--- a/hw/dmx/config/dmxcompat.c
+++ b/hw/dmx/config/dmxcompat.c
@@ -123,7 +123,6 @@ dmxVDLRead(const c
Signed-off-by: Adam Jackson
---
hw/dmx/glxProxy/render2swap.c | 34 ++
hw/dmx/glxProxy/renderpixswap.c | 3 ---
2 files changed, 6 insertions(+), 31 deletions(-)
diff --git a/hw/dmx/glxProxy/render2swap.c b/hw/dmx/glxProxy/render2swap.c
index 166ec88..146476c 1
> This should be lastGLContext->loseCurrent(lastGLContext) I think. cx
Yes, you are right. It seems the right thing to do, but actually this
should be done every place where lastGLContext is set, right?
It seems to me that every place where lastGLContext is set is a potential
leak.
While you're
Signed-off-by: Adam Jackson
---
randr/rrcrtc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index ec26fcd..566a3db 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -383,7 +383,6 @@ rrDestroySharedPixmap(RRCrtcPtr crtc, PixmapPtr pPixmap) {
void
RRCrtcDet
On Tue, Dec 08, 2015 at 04:05:55PM -0500, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
Series Reviewed-by: Peter Hutterer
Cheers,
Peter
> ---
> hw/dmx/glxProxy/glxsingle.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/hw/dmx/glxProxy/glxsingle.c b/hw/dm
On Tue, Dec 08, 2015 at 09:56:45AM -0800, Keith Packard wrote:
> Michel Dänzer writes:
>
> > This commit broke input for me with xf86-input-libinput. No keyboard or
> > mouse input is received. There are no errors in the log file.
> >
> > xf86-input-evdev works.
>
> Ok, I spent some time yesterd
On Tue, Dec 08, 2015 at 03:08:34PM -0500, Adam Jackson wrote:
> It probably doesn't work very well since there's other extension setup
> we're not doing on this path, and in any event it's not a thing that
> happens currently.
>
> Signed-off-by: Adam Jackson
> ---
> Xext/sync.c | 15 +---
This applies regardless of which DRI you're asking for. Worse, leaving
it out means breaking the config file syntax in a pointless way, since
non-DRI servers can safely just parse it and ignore it.
Signed-off-by: Adam Jackson
---
hw/xfree86/common/xf86Config.c | 8
1 file changed, 8 del
Signed-off-by: Adam Jackson
---
hw/xfree86/doc/Makefile.am| 1 -
hw/xfree86/doc/README.DRIcomp | 551 --
2 files changed, 552 deletions(-)
delete mode 100644 hw/xfree86/doc/README.DRIcomp
diff --git a/hw/xfree86/doc/Makefile.am b/hw/xfree86/doc/Make
DRI1 hasn't really been a supported option for a while now, Mesa hasn't
supplied any drivers for it in years, and the design really isn't
compatible with KMS-like drivers. Also, Keith has some upcoming work to
thread input handling that will conflict with the SIGIO handling, so if
it's not already
Signed-off-by: Adam Jackson
---
configure.ac| 18 +-
dix/protocol.txt| 16
glx/Makefile.am | 1 -
include/protocol-versions.h | 5 -
include/xorg-config.h.in| 3 ---
include/xorg-server.h.in| 3 ---
os/utils.
On 08/12/15 05:41 PM, Adam Jackson wrote:
> DRI1 hasn't really been a supported option for a while now, Mesa hasn't
> supplied any drivers for it in years, and the design really isn't
> compatible with KMS-like drivers. Also, Keith has some upcoming work to
> thread input handling that will conflic
On 8 December 2015 at 22:41, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
> --- a/test/Makefile.am
> +++ b/test/Makefile.am
> @@ -64,10 +64,6 @@ CLEANFILES = sdksyms.c
> sdksyms.c: $(top_builddir)/hw/xfree86/sdksyms.c
> $(AM_V_GEN)$(LN_S) $(top_builddir)/hw/xfree86/sdksyms.c
>
> -
On Tue, 2015-12-08 at 23:12 +, Emil Velikov wrote:
> Afaict this should really be part of previous commit. Since that's the
> place where we remove the static library.
D'oh, right you are. I did verify that the series built at every step,
but only with 'make' and not with a 'make clean' in b
On Wed, 2015-12-09 at 07:54 +1000, Peter Hutterer wrote:
> Series Reviewed-by: Peter Hutterer
Merged, thanks!
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinf
On Wed, 2015-12-09 at 08:40 +1000, Peter Hutterer wrote:
> in that case you can remove the RTCounter == 0 check in SyncExtensionInit()
> and just do the rest unconditional.
Indeed. Fixed that up and pushed, thanks.
- ajax
___
xorg-devel@lists.x.org: X.
On 8 December 2015 at 22:58, Connor Behan wrote:
> On 08/12/15 05:41 PM, Adam Jackson wrote:
>> DRI1 hasn't really been a supported option for a while now, Mesa hasn't
>> supplied any drivers for it in years, and the design really isn't
>> compatible with KMS-like drivers. Also, Keith has some upc
Switch the XFree86 DDX over to threaded input
Signed-off-by: Keith Packard
---
hw/xfree86/common/xf86Events.c | 5 +++--
hw/xfree86/common/xf86Helper.c | 2 +-
hw/xfree86/common/xf86Init.c | 3 +++
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/common/xf86Events.c b/
Here's a series which revives Tiago's ancient threaded input
patch. This has been cleaned up to make sure that it does locking
correctly, and then patches for xf86 and kdrive/fbdev hook the code to
a couple of X servers to show how it should work.
Before applying that, all of the SIGIO support in
The current SIGIO signal handler method, used at generation of input events,
has a bunch of oddities. This patch introduces an alternative way using a
thread, which is used to select()s all input device file descriptors.
A mutex was used to control the access to input structures by the main and in
Now that input is threaded, malloc can be used at event time to resize
the touchpoint buffer as needed.x
---
dix/touch.c | 89 +
1 file changed, 30 insertions(+), 59 deletions(-)
diff --git a/dix/touch.c b/dix/touch.c
index eee110d..591f
---
include/input.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/input.h b/include/input.h
index d8bd9c6..5bc60f0 100644
--- a/include/input.h
+++ b/include/input.h
@@ -712,4 +712,10 @@ extern _X_HIDDEN void input_constrain_cursor(DeviceIntPtr
pDev, ScreenPtr screen
Signed-off-by: Keith Packard
---
hw/kdrive/src/kinput.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/kdrive/src/kinput.c b/hw/kdrive/src/kinput.c
index a3e352c..a2fff1c 100644
--- a/hw/kdrive/src/kinput.c
+++ b/hw/kdrive/src/kinput.c
@@ -131,7 +131,7 @@ static void
This removes all of the SIGIO handling support throughout the X
server, preparing the way for using threads for input handling
instead.
Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
to stub functions input_lock/input_unlock so that we don't lose this
information.
Signed-off
On 12/ 8/15 03:44 PM, Keith Packard wrote:
This removes all of the SIGIO handling support throughout the X
server, preparing the way for using threads for input handling
instead.
Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
to stub functions input_lock/input_unlock so tha
Alan Coopersmith writes:
> Shouldn't this also remove all the USE_SIGIO_BY_DEFAULT references in
> configure.ac?
Yes. Thanks!
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.
On 09.12.2015 06:22, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
> ---
> randr/rrcrtc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
> index ec26fcd..566a3db 100644
> --- a/randr/rrcrtc.c
> +++ b/randr/rrcrtc.c
> @@ -383,7 +383,6 @@ rrDestroyShare
On 08/12/15 06:36 PM, Emil Velikov wrote:
> On 8 December 2015 at 22:58, Connor Behan wrote:
>> On 08/12/15 05:41 PM, Adam Jackson wrote:
>>> DRI1 hasn't really been a supported option for a while now, Mesa hasn't
>>> supplied any drivers for it in years, and the design really isn't
>>> compatible
On 09.12.2015 07:41, Adam Jackson wrote:
> DRI1 hasn't really been a supported option for a while now, Mesa hasn't
> supplied any drivers for it in years, and the design really isn't
> compatible with KMS-like drivers. Also, Keith has some upcoming work to
> thread input handling that will conflict
Yeah, there's no open source implementation of these right now, but essentially
they just allow the source driver to do whatever specific setup necessary to
present to either of the two supplied shared buffers from the same headsurface,
as well as having presentation driven by PresentTrackedFlippin
Keith Packard writes:
> Here's a series which revives Tiago's ancient threaded input
> patch.
I've spent some time debugging and cleaning this up further; I found a
couple of deadlocks, and then I also fixed mieqEnqueue to resize the
input event queue when it gets full, rather than dropping even
Michel Dänzer writes:
> FWIW, the latter is no reason to remove DRI1 support as a whole AFAICT:
> SIGIO was only used for DRI1 kernel driven context switching,
It looks like the only non-SIGIO path would be for drivers using
DRI_KERNEL_SWAP; DRI_HIDE_X_CONTEXT and DRI_SERVER_SWAP both require
S
Adam Jackson writes:
> I've left off the libXfont2 bit in 5/20, since there's neither a
> release nor bits in git to build against yet; 18/20 and 19/20 since
> they require that 5/20 be already in; and 20/20 since xwayland is using
> that API now.
I've released the first version of libXfont2 (2.
On Tue, Dec 08, 2015 at 03:44:50PM -0800, Keith Packard wrote:
> This removes all of the SIGIO handling support throughout the X
> server, preparing the way for using threads for input handling
> instead.
>
> Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
> to stub functions
On Tue, Dec 08, 2015 at 03:44:54PM -0800, Keith Packard wrote:
> Now that input is threaded, malloc can be used at event time to resize
> the touchpoint buffer as needed.x
> ---
> dix/touch.c | 89
> +
> 1 file changed, 30 insertions(+),
./configure: line 19194: syntax error near unexpected token `with_cflags,'
./configure: line 19194: ` CC_CHECK_FLAGS_APPEND(with_cflags, CFLAGS, \'
From what I can tell, CC_CHECK_FLAGS_APPEND comes from glib. Can we please not
add a dependency on glib for this?
--Jeremy
> commit eb67d10ae
On 09.12.2015 14:01, Keith Packard wrote:
>
> Michel Dänzer writes:
>
>> FWIW, the latter is no reason to remove DRI1 support as a whole AFAICT:
>> SIGIO was only used for DRI1 kernel driven context switching,
>
> It looks like the only non-SIGIO path would be for drivers using
> DRI_KERNEL_SWA
On 09.12.2015 13:21, Alex Goins wrote:
> On Tue, 8 Dec 2015, Michel Dänzer wrote:
>> On 26.11.2015 11:39, Alex Goins wrote:
>>>
>>> (Start/Stop)FlippingPixmapTracking are merely the double-buffered
>>> equivalents of (Start/Stop)PixmapTracking, allowing the source driver to do
>>> whatever setup an
58 matches
Mail list logo