evdevtouch: Disable threading.

This should never have been threaded. It isn't resource-intensive, and it needs
to communicate touches back to the main thread anyway.

Removing the threading significantly(!) improves latency.
evdevtouch: Don't try to keep reading if we get EAGAIN.

This stops touching the screen (and not moving) consuming 80-90% CPU. :)
Merge branch 'master' of github.com:mer-packages/qtbase
Add ability to pre-filter touch data
Bypass eglMakeCurrent where possible.

This has the possibility to be very slow on some GPUs. A nicer alternative would
have been to fix this in QOpenGLContext, but with makeCurrent and updateContext
having been merged in Qt 5, makeCurrent is required every frame call, and thus
cannot be fixed there.

Change-Id: Ib17dbb3a1e4e89c60dfd4f12a55eeff353f9075f
Done-with: Carsten Munk <carsten.munk@jollamobile.com>
Merge pull request #5 from rburchell/eglmakecurrent

Bypass eglMakeCurrent where possible.
Remove -arch

As configure says, such option is nowadays deprecated and unused. Qt's
compiler detection already does what's needed.
Remove -no-neon

Qt is smart enough to pick up whether NEON is supported (armv7tnhl)
or not by itself through compiler detection.
Merge pull request #6 from Ispirata/remove-config-options

Remove config options from configure
[packaging] With no-neon, PCH stops working, disable on ARM

Signed-off-by: Carsten Munk <carsten.munk@jollamobile.com>
correctly fix compilation of NEON_ASM sources

This reverts commit 1ef74a763a726829bfc26224d82acff207fdc8bb, as
assembler files in SOURCES break compiling with -pch, as we don't create
a respective PCH.

instead, compile assembler code with QMAKE_CC, not QMAKE_CXX.

the reason why this change is needed in the first place is not clear to
me, but i guess that CXX defines some c++-related macros when
preprocessing the file, which breaks further down the line. this is
counter-intuitive, as the g++ frontend should treat the same sources the
same way as the gcc frontend (differences should be limited the the ld
invocation).

Task-number: QTBUG-29765
Change-Id: Ic0116b3a5fa621f12ac41cadf3062ff00b538e85
[packaging] Re-enable PCH for ARM after upstream cherry-picking

Signed-off-by: Carsten Munk <carsten.munk@jollamobile.com>
Fix unprotected access to QDBusPendingCallPrivate::pending.

In QDBusConnectionPrivate::waitForFinished() pcall->pending was used
after the protection by pcall->mutex was released. A simultaneous
call to QDBusConnectionPrivate::processFinishedCall() was able
to reset pcall->pending to null before it was used for the
q_dbus_pending_call_block(pcall->pending) call.

Fixed by releasing (and setting to 0) of pcall->pending in
processFinishedCall() only in case no one is waiting yet, otherwise
release pcall->pending by the first thread waiting in waitForFinished().

There is still a race condition about deleting QDBusPendingCallPrivate
(too early) which will be fixed in the next two commits.

Task-number: QTBUG-27809
Change-Id: I040173810ad90653fe1bd1915f22d8dd70d47d8c
Remove QDBusPendingCallPrivate::autoDelete logic.

First step to fix race condition about deleting QDBusPendingCallPrivate.

In a multithreaded application on a slow/single core cpu the following
race (and segmentation fault) can occur:

First thread A is running:
A:  QDBusPendingReply<> reply = pi->asyncCallWithArgumentList(method, argumentList);

Then when the dbus answer arrives thread B will call:

B:  QDBusConnectionPrivate::processFinishedCall()
B:      ...
B:      locker.unlock()

and runs until here, go on with thread A:

A:  reply.waitForFinished();
A:    QDBusPendingCallPrivate::waitForFinished()
A:    {
A:        QMutexLocker locker(&mutex);
A:        if (replyMessage.type() != QDBusMessage::InvalidMessage)
A:            return;

which returns immediately (mutex acquired, replyMessage alread set), now
reply goes out of scope (destructor called) and QDBusPendingCall::d's
destructor of type QExplicitlySharedDataPointer<QDBusPendingCallPrivate>
deletes the reference counted object QDBusPendingCallPrivate.

Now thread B continues, still in processFinishedCall()

B:      if (call->watcherHelper)
B:          call->watcherHelper->emitSignals(msg, call->sentMessage);
B:
B:      if (msg.type() == QDBusMessage::ErrorMessage)
B:          emit connection->callWithCallbackFailed(QDBusError(msg),
B:              call->sentMessage);

accessing alread deleted object QDBusPendingCallPrivate via call->...

Fixed QDBusPendingCallPrivate deletion by proper reference counting
will be done in the next commit.

Task-number: QTBUG-27809
Change-Id: I15b3f0242471b62eaafadc763fb6a33339ff2fe1
Change QDBusPendingCallPrivate to full reference counting for deletion.

Fixes race between QDBusConnectionPrivate::processFinishedCall()
releasing the mutex before emitting signals (using various members of
QDBusPendingCallPrivate) and deletion of the QDBusPendingCallPrivate
object through QDBusPendingCall::d's destructor (a member of type
QExplicitlySharedDataPointer<QDBusPendingCallPrivate>) leeds to
segmentation fault with CrashTest example on slow/single core
arm cpu).

Task-number: QTBUG-27809
Change-Id: I3590d74d1cfa5816ede764b50b83a7008ec780ff
Merge pull request #7 from aaronkennedy/touchfilter

Add ability to pre-filter touch data
Fix dead lock in the Qt event handling

The deadlock is caused because the QEvent is destroyed while holding the
event list mutex. And the QEvent may have a custom destructor that will
re-enter the event handlng code.

The QScopedPointer that should destroy the event must be created after
the MutexUnlocker.

Regression introduced by commit f9035587b98ac5dc9491e642b8ec84470ec03f0e

Task-number: QTBUG-31606
Change-Id: I6b2cbc2656eacdec61b641886953f00bf5b3ff36
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Merge branch 'master' of github.com:mer-packages/qtbase
[patch] Increment loopLevel prior to emitting aboutToBlock()/awake() signals

Without this, any deferred delete actions that occur as a result of
these signals will not be processed until the main event loop exits.

This is triggered by the QtWayland server, which uses aboutToBlock() to
process internal events such as surface destruction.