On Freitag, 10. Mai 2013 08:33:34 CEST, Grant wrote:
See eg. https://bugzilla.redhat.com/show_bug.cgi?id=877464
Try to update the synaptics driver if possible.
OK here are two.
(EE) BUG: triggered 'if (priv-num_active_touches priv-num_slots)'
(EE) BUG:
Hi All, I am using hardware accelerated video rendering on X windows, I
want to set the default background color for windows to be black. It seems
that every effort of doing that fails, i.e. when the HW accelerated video
display queue is terminated, I end up with a green window, not black or
alpha
On Fri, May 10, 2013 at 10:41 AM, Ratin rat...@gmail.com wrote:
Hi All, I am using hardware accelerated video rendering on X windows, I want
to set the default background color for windows to be black. It seems that
every effort of doing that fails, i.e. when the HW accelerated video display
Hi Alex, Thanks for your response. I am using VDPAU API for Nvidia GPUs and
windows created with simple Xlib calls, so when I destroy the presentation
queue, the window becomes green, I tried VDPAU background color but that I
believe will go away when presentation queue is destroyed.
On Fri, May
See eg. https://bugzilla.redhat.com/show_bug.cgi?id=877464
Try to update the synaptics driver if possible.
OK, I'm updating from 1.6.2-r1 to 1.7.0. This crash didn't start
happening for me until I started using the new Cypress driver in the
kernel.
- Grant
OK here are two.
(EE) BUG:
I meant Shotwell can't reorganize your files after they've been imported.
When you're importing and copying files (not in-place), Shotwell will
organize files into directories by the photos' dates. See Edit -
Preferences for different ways to organize by date when importing.
Got it, thanks
If the device is currently grabbed as the result of a passive grab
activating, do not prepend that grab to the listeners (unlike active grabs).
Otherwise, a client with a passive pointer grab will prevent touch grabs
from activating higher up in the window stack.
Signed-off-by: Peter Hutterer
I'm not going to even pretend this is understandable, given that the first
patches to fix this issue go back to November last year. And touch grab
handling and pointer emulation is such a beast that I can't get it all in my
head anymore. I've got a bunch of test cases that show the various bugs
ef64b5ee97099618cf2e2cbbd3e471095695ae24 (which introduced the
TOUCH_CLIENT_ID check) has a wrong assumption that generated touch events
(TOUCH_CLIENT_ID) should not terminate passive grabs.
This is untrue, a TouchEnd may be generated in response to a TouchReject
higher up. If we _deliver_ an
If a TouchBegin is sent to a core client, that client is now the owner.
By the time the TouchEnd is being processed, the client cannot replay
anymore, so we can assume that this is the final touch end and we can clean
up the touch record.
Note: DeliverTouchEmulatedEvent is called for all
ActivateEarlyAccept() can only be called from a grabbing client, so we can
ignore the rest. And it's easy enough to get the client from that since
9ad0fdb135a1c336771aee1f6eab75a6ad874aff.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/exevents.c | 15 +++
1 file
If we only have a single touch-grabbing client, setting the client as owner
would clean up the touch once the TouchEnd was processed. If the client then
calls XIAllowTouches() it will receive a BadValue for the touch ID (since
the internal record is already cleaned up).
Signed-off-by: Peter
Async grabs cannot replay events, they cannot reject, so we can do an early
accept here.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/exevents.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index b1df0cb..0f37d6b 100644
Delivering an event changes the state to LISTENER_IS_OWNER and we thus lose
the information of early acceptance.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/exevents.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index
If a touch is pending_finish and we just punted it to the next owner, that
client must receive a TouchEnd event.
If we just punted to the last owner and that owner not a touch grab, we need
to end the touch since this is the last event to be sent, and the client
cannot accept/reject this.
If a device is frozen in results to a grab, we need to enqueue the events.
This makes things complicated, and hard to follow since touch events are now
replayed in the history, pushed into EnqueueEvent, then replayed later
during PlayReleasedEvents in response to an XAllowEvents.
While the
Change the single if condition in the loop body to a
if (!foo) continue;
and re-indent the rest.
No functional changes.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/touch.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git
A sync grab is the owner once it gets events. If it doesn't replay the
event it will get all events from this touch, equivalent to accepting it.
If the touch has ended before XAllowEvents() is called, we also now need to
send the TouchEnd event and clean-up since we won't see anything more from
No functional changes.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/touch.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/dix/touch.c b/dix/touch.c
index be4a7de..01a554e 100644
--- a/dix/touch.c
+++ b/dix/touch.c
@@ -719,12 +719,13 @@
Obsolete since 4bc2761ad5ec2d0668aec639780ffb136605fbc8. This struct
existed so copying a passive grab could be simply done by
activeGrab = *grab
and thus have a copy of the GrabPtr we'd get from various sources but still
be able to check device-grab for NULL.
Since 4bc2761 activeGrab is a
no functional changes
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/events.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index e2e94a5..dc50311 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -1427,21 +1427,22
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/grabs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/dix/grabs.c b/dix/grabs.c
index 3b02352..0a2111d 100644
--- a/dix/grabs.c
+++ b/dix/grabs.c
@@ -249,6 +249,8 @@ CreateGrab(int client, DeviceIntPtr device, DeviceIntPtr
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/exevents.c | 2 +-
Xi/ungrdevb.c | 2 +-
Xi/ungrdevk.c | 2 +-
Xi/xipassivegrab.c | 2 +-
dix/events.c | 16 +++-
dix/grabs.c| 10 --
include/dixgrabs.h | 2 +-
7 files changed, 20
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/touch.c | 4
1 file changed, 4 insertions(+)
diff --git a/dix/touch.c b/dix/touch.c
index fb218d4..0099914 100644
--- a/dix/touch.c
+++ b/dix/touch.c
@@ -263,6 +263,7 @@ void
TouchFreeTouchPoint(DeviceIntPtr device, int index)
If we have one listener left but it's not a grab, it cannot be in
LISTENER_HAS_ACCEPTED state.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/exevents.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index ae2e5ae..a99821f 100644
A client may call XIGrabDevice twice, overwriting the existing grab. Thus,
make sure we free the old copy after we copied it. Free it last, to make
sure our refcounts don't run to 0 and inadvertantly free something on the
way.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
The cursor is referenced during CopyGrab(), thus doesn't need to be handled
manually anymore. It does need to be refcounted for temp grabs though.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/events.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
On 05/07/2013 09:24 PM, Connor Behan wrote:
On 07/05/13 06:17 AM, Pander wrote:
On 7 May 2013 14:04, Pander pan...@users.sourceforge.net
wrote:
The sis671 driver:
# xorg.conf (X.Org X Window System server configuration
file)
...
Section Device Identifier Configured Video Device
On 05/10/2013 10:23 AM, Pander wrote:
On 05/07/2013 09:24 PM, Connor Behan wrote:
On 07/05/13 06:17 AM, Pander wrote:
On 7 May 2013 14:04, Pander pan...@users.sourceforge.net
wrote:
The sis671 driver:
# xorg.conf (X.Org X Window System server configuration
file)
...
Section Device
On Fri, May 10, 2013 at 11:04 AM, Pander wrote:
On 05/07/2013 09:24 PM, Connor Behan wrote:
SiS drivers support EXA and will probably use that by default when
you start one of the newer Xservers that lacks XAA. This could
easily crash if the SiS EXA hooks haven't been updated in awhile so
On Thu, 9 May 2013 10:21:03 +1000, Dave Airlie airl...@gmail.com wrote:
I have two 6450 cards in my Ubuntu 13.04 system with three monitors.
This
is
a recent install with no binary drivers installed and no additional X
ppa's
installed. I can get X to display output on the primary monitor,
https://bugs.freedesktop.org/show_bug.cgi?id=64449
Priority: medium
Bug ID: 64449
Assignee: xorg-driver-ati@lists.x.org
Summary: xorg hangs randomly with Radeon HD 7450A
QA Contact: xorg-t...@lists.x.org
Severity: critical
32 matches
Mail list logo
