Hi,
(please CC me, I'm not subscribed)
here is a patch to better handle a big number of resources.
In my case I had been experiencing a huge slowdown of the system
after a few days of uptime, which I tracked to an application (psi)
continuously pushing pixmaps to plasma-desktop to achieve a
Am Samstag, den 24.11.2012, 22:09 +0100 schrieb Thierry Reding:
Hi,
With tegra-drm going into Linux 3.8 and NVIDIA posting initial patches
for 2D acceleration on top of it, I've been looking at the various ways
how this can best be leveraged.
The most obvious choice would be to start work
On Sat, Nov 24, 2012 at 11:54:32PM +0100, Lucas Stach wrote:
Am Samstag, den 24.11.2012, 22:09 +0100 schrieb Thierry Reding:
Hi,
With tegra-drm going into Linux 3.8 and NVIDIA posting initial patches
for 2D acceleration on top of it, I've been looking at the various ways
how this can
On Sun, Nov 25, 2012 at 12:45:07PM +0100, Michal Suchanek wrote:
Hello,
On 24 November 2012 22:09, Thierry Reding
thierry.red...@avionic-design.de wrote:
However, that has all the usual drawbacks of a fork so I thought maybe
it would be better to write some code to
Hello,
On 24 November 2012 22:09, Thierry Reding
thierry.red...@avionic-design.de wrote:
However, that has all the usual drawbacks of a fork so I thought maybe
it would be better to write some code to xf86-video-modesetting to add
GPU-specific acceleration on top. Such code could be leveraged
On 25.11.2012 00:54, Lucas Stach wrote:
As much as I dislike to say this, but forking the modesetting driver to
bring in the Tegra specific 2D accel might be the best way to go for
now. Especially looking at the very limited resources available to
tegradrm development and NVIDIAs expressed
On Sat, Nov 24, 2012 at 4:09 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
going into Linux 3.8 and NVIDIA posting initial patches
for 2D acceleration on top of it, I've been looking at the various ways
how this can best be leveraged.
The most obvious choice would be to start
On Fri, Nov 23, 2012 at 3:21 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
On Thu, Nov 08, 2012 at 02:28:10PM +0100, Thierry Reding wrote:
Recent versions of the X server no longer provide this function, which
has been obsolete for over 2 years now.
Signed-off-by: Thierry Reding
No need to specify those when waiting for core or extension events that are
not GenericEvents.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
include/xorg/gtest/xorg-gtest-xserver.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
export XORG_GTEST_USE_VALGRIND=valgrind --leak-check=full
./run-some-test
But really, can be used with any wrapper binary. Given that valgrind is the
main use-case here, keep the USE_VALGRIND naming instead of something more
generic like USE_PROCESS_WRAPPER or so.
Signed-off-by: Peter Hutterer
An active grab ungrabbing is the same as rejecting the grab, since the
client is no longer interested in those events. So reject any touch grab,
but do so before actually deactivating since we're interested in the
TouchEnd for the current grabbing client.
A passive grab otoh is _not_ like
A client with a pointer grab on a touch device must reject the touch when
detactivating the grab while the touch is active. However, such a rejecting
must not trigger a ButtonRelease event to be emulated and sent to the
client.
Set the grabbing listener's state to HAS_END, so we simply skip
Once the TouchEnd appears on the device, the touch is done. If the client
still has a pointer grab, accept it to avoid clients with TouchOwnership
selections to wait indefinitely for the actual touch event.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Probably a bit confusing to
On Sun, Nov 25, 2012 at 09:51:46PM -0500, Alex Deucher wrote:
On Sat, Nov 24, 2012 at 4:09 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
going into Linux 3.8 and NVIDIA posting initial patches
for 2D acceleration on top of it, I've been looking at the various ways
how this can
On Mon, Nov 26, 2012 at 5:32 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
On Sun, Nov 25, 2012 at 09:51:46PM -0500, Alex Deucher wrote:
On Sat, Nov 24, 2012 at 4:09 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
going into Linux 3.8 and NVIDIA posting initial patches
On Mon, Nov 26, 2012 at 05:45:38PM +1000, Dave Airlie wrote:
On Mon, Nov 26, 2012 at 5:32 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
On Sun, Nov 25, 2012 at 09:51:46PM -0500, Alex Deucher wrote:
On Sat, Nov 24, 2012 at 4:09 PM, Thierry Reding
In technical, it's true to focus xf86-video-modesetting on the hardware
independent stuffs/making frameworks and GPU vendors upstreams their
hardware dependent codes. But this needs a lot of cooperation and the
progress would be slow. This is not GPU vendors want so I assume they'll
not put lots
On Sun, Nov 25, 2012 at 8:37 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
On Sat, Nov 24, 2012 at 11:54:32PM +0100, Lucas Stach wrote:
Am Samstag, den 24.11.2012, 22:09 +0100 schrieb Thierry Reding:
Hi,
With tegra-drm going into Linux 3.8 and NVIDIA posting initial patches
On 11/22/2012 07:08 AM, Tomasz Lis wrote:
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,
On 11/24/2012 01:09 PM, Thierry Reding wrote:
Hi,
With tegra-drm going into Linux 3.8 and NVIDIA posting initial patches
for 2D acceleration on top of it, I've been looking at the various ways
how this can best be leveraged.
The most obvious choice would be to start work on an xf86-video-tegra
Hi Keith,
Some more fixes for building for MinGW. Please consider pulling into master.
You might also want to consider reviewing those patches which touch DIX code
yourself, since they have had no reviews from people who care about DDXs other
than XWin.
Thanks.
The following changes since
On Mon, Nov 26, 2012 at 09:45:50AM -0800, Aaron Plattner wrote:
On 11/24/2012 01:09 PM, Thierry Reding wrote:
Hi,
With tegra-drm going into Linux 3.8 and NVIDIA posting initial patches
for 2D acceleration on top of it, I've been looking at the various ways
how this can best be leveraged.
On Mon, Nov 26, 2012 at 6:14 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 11/26/2012 07:01 AM, Alex Deucher wrote:
On Sun, Nov 25, 2012 at 8:37 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
...
With the common base that could be shared I meant all the modesetting
code and
On Sat, Nov 24, 2012 at 11:31:36PM -0500, Jasper St. Pierre wrote:
On Thu, Nov 22, 2012 at 10:02 PM, Peter Hutterer
peter.hutte...@who-t.netwrote:
On Tue, Nov 20, 2012 at 02:50:40PM -0500, Jasper St. Pierre wrote:
This is a heavy modification of RAOF's patch set that's used in Ubuntu
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/inpututils.c | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/dix/inpututils.c b/dix/inpututils.c
index f01e9a7..eba 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -910,11 +910,7
25 matches
Mail list logo
