Subject: [PATCH] xfree86: don't access the old input handler after freeing it
Introduced in 323869f3298cbbfe864af9404a8aed1bf7995d79
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Reviewed-by: Dave Airlie airl...@redhat.com
---
hw/xfree86/common/xf86Events.c | 10 ++
1
From: Tomasz Lis tomasz@intel.com
Changes to correctly initialize the sRGB capability attribute and
transfer it between XServer and the client. Modifications include
extension string, transferring visual config attribs and fbconfig
attribs. Also, attribute is initialized in the modules which
On 07/01/2013 14:24, Dan Nicholson wrote:
On Mon, Jan 7, 2013 at 5:14 AM, Jon TURNEY wrote:
The config check of the results of testing for dlcfn.h or dl.h just tests the
value of the ac_cv_ variables, which will be 'yes' or 'no', rather than
checking
it is 'yes', so loadable module support
Slap _X_INTERNAL so sdksyms won't attempt to export PanoramiXSaveXFixesVector
just because it has extern in it..
Fixes build of x1.14rc1
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/xfixes/xfixesint.h b/xfixes/xfixesint.h
index 334c71f..309954d 100644
---
Hi,
this patch series aims at fixing the bug that will arrive with Win 8 devices
supporting Z-axis detection (proximity or hovering).
Patches 1 to 4 are some cleanup
Patch 5 removes the need of mtdev for the mt protocol B devices
Patch 6 makes a necessary initialization of the current values of
This prevents the creation of a touch in case no multitouch event came
before the very first EV_SYN.
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@gmail.com
---
src/evdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/evdev.c b/src/evdev.c
index 619bce6..27b0e76 100644
---
The current implementation assume that multitouch devices following the
Multitouch Protocol A (those requiring mtdev) present 10 touches,
no matter mtdev decides.
num_slots should be relying on mtdev when it is available.
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@gmail.com
---
Everywhere else in the code, pEvdev-cur_slot is never used directly,
but through the function last_mt_vals_slot which standardize it.
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@gmail.com
---
src/evdev.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git
Getting an out of range ABS_MT_SLOT value means that either the kernel
driver is broken or the device is sending more slots that it advertised.
In both cases, it's a bug in the kernel and processing the incoming
events for this bad slot may introduce end-user problems.
Signed-off-by: Benjamin
Mtdev is only usefull for protocol A devices (quite a few now).
For all the others, it adds some memory and process which is not required
as it just passes the events to the caller.
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@gmail.com
---
src/evdev.c | 26 +++---
1
The previous implementation considers that a new slot means a TouchBegin,
and the deletion of the slot a TouchEnd. However, this is not compliant
with the mt evdev specification as the touch state is given by
ABS_MT_DISTANCE == 0.
Before Win 8 specification, no known multitouch devices present in
ABS_MT_DISTANCE controls whether the finger is touching the sensor or not.
When the slot is opened, if the device reports ABS_MT_DISTANCE, we should
rely on it to set the right value of touch. If not, then the creation of
the slot means that the touch began.
Signed-off-by: Benjamin Tissoires
Hello, as reported downstream[1] by me, various xf-86-video-*
packages fail during the compile phase with the following error:
/usr/include/xorg/compiler.h:1412:5: error: impossible register
constraint in 'asm'
The proposed patch at comment 1 works for me. What do you think about?
Note:
* where are the bytes guaranteed to be zero? Not questioning, I just want to
double-check and it's outside the patch contexts
I looked into xkbcomp source. Before the actions structs are written to
according to the specification in the .xkb file, they are indeed zeroed.
For specifications in
On 9 January 2013 01:33, Samuel Thibault samuel.thiba...@ens-lyon.org wrote:
Samuel Thibault, le Wed 09 Jan 2013 00:55:13 +0100, a écrit :
Michal Suchanek, le Tue 08 Jan 2013 22:26:50 +0100, a écrit :
Well, I hope I have made my point clear: the blind user case should
get exactly the same
On Wed, Jan 09, 2013 at 09:19:25PM +0100, wettstein...@solnet.ch wrote:
* where are the bytes guaranteed to be zero? Not questioning, I just want to
double-check and it's outside the patch contexts
I looked into xkbcomp source. Before the actions structs are written to
according to the
Michal Suchanek, le Wed 09 Jan 2013 22:46:37 +0100, a écrit :
On 9 January 2013 01:33, Samuel Thibault samuel.thiba...@ens-lyon.org wrote:
Samuel Thibault, le Wed 09 Jan 2013 00:55:13 +0100, a écrit :
Michal Suchanek, le Tue 08 Jan 2013 22:26:50 +0100, a écrit :
Well, I hope I have made
On 9 January 2013 23:51, Samuel Thibault samuel.thiba...@ens-lyon.org wrote:
And I don't see that happening by default with the dummy driver.
s/happening/coming back/
Since the drivers are probed one by one in order there can be only one
flag. Two flags set by two drivers will never be set
On Wed, Jan 09, 2013 at 07:21:21PM +0100, Benjamin Tissoires wrote:
The previous implementation considers that a new slot means a TouchBegin,
and the deletion of the slot a TouchEnd. However, this is not compliant
with the mt evdev specification as the touch state is given by
ABS_MT_DISTANCE
On Wed, Jan 09, 2013 at 07:21:22PM +0100, Benjamin Tissoires wrote:
ABS_MT_DISTANCE controls whether the finger is touching the sensor or not.
When the slot is opened, if the device reports ABS_MT_DISTANCE, we should
rely on it to set the right value of touch. If not, then the creation of
commit 6703a7c7cf1a349c137e247a0c8eb462ff7b07be
Author: Keith Packard kei...@keithp.com
Date: Tue Jan 8 20:24:32 2013 -0800
hw/xfree86: Require only one working CRTC to start the server.
changed the logic to try to set the mode on all connected outputs rather
than abort upon the first
21 matches
Mail list logo
