Michel Dänzer mic...@daenzer.net writes:
On Die, 2014-01-14 at 05:34 -0800, Keith Packard wrote:
Michel Dänzer mic...@daenzer.net writes:
Didn't SNA prove though that sharing the same pixel storage for GPU and
CPU doesn't give the overall best performance even with Intel GPUs? It
Hi Peter,
I am debugging geis-2.2.16 these days, and also read about synaptics
1.7.x source code, in 1.7.x, it uses xf86PostTouchEvent, post multitouch
event to X, then the client application, such as touchegg, is able to
get XEvent in a while loop, is that right?
But in 1.7.x
On Fre, 2014-01-10 at 09:26 +0800, Eric Anholt wrote:
We're going to want to make this DIX code instead of XF86 if at all
possible, but for now just disable it so we can work on the rest of
the build.
The radeon driver can't really use the in-tree glamor unless it supports
Xv. What's your plan
On Wed, Jan 15, 2014 at 02:22:11PM +0800, Leslie Zhai wrote:
Hi synaptics developers,
In geis-2.2.16, libgeis/backend/grail/geis_grail_backend.c source
code file, about the 1143 line,
http://bazaar.launchpad.net/~oif-team/geis/trunk/view/head:/libgeis/backend/grail/geis_grail_backend.c#L1147
On Wed, Jan 15, 2014 at 05:43:31PM +0800, Leslie Zhai wrote:
Hi Peter,
I am debugging geis-2.2.16 these days, and also read about synaptics
1.7.x source code, in 1.7.x, it uses xf86PostTouchEvent, post
multitouch event to X, then the client application, such as
touchegg, is able to get
On 01/15/2014 01:22 AM, Leslie Zhai wrote:
And why ubuntu phone with multitouch touchscreen works well? It is based on
Mir, utouch-geis, sort of gesture
recognition utils, is not it? or it is android-based, different from Linux
multitouch protocol?
For systemd-logind integration we need the dbus connection to be available
before enumerating input and gfx devices.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hw/xfree86/common/dbus-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Use kernel goto style error handling for xf86VTSwitchAway() failure. This
makes it much easier to read the straight path.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hw/xfree86/common/xf86Events.c | 94 +-
1 file changed, 46 insertions(+), 48
Before this commit we were trying to add most drm devices twice, once
from xf86platformProbe() and once from config_udev_init().
This results in somewhat confusing messages in Xorg.log, ie:
(II) xfree86: Adding drm device (/dev/dri/card0)
Later followed by:
(II) config/udev: Adding drm device
With systemd-logind we need to delay input device probing when switched away
(iow not on the active vt). This is a preparation patch for this.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
config/udev.c | 150 +-
1 file changed, 85
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hw/xfree86/common/xf86.h | 2 +
hw/xfree86/common/xf86Events.c | 273 +
2 files changed, 145 insertions(+), 130 deletions(-)
diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index
With systemd-logind support, the xserver, rather then the drivers will be
responsible for opening/closing the fd for drm nodes.
The initial open will happen on probe from config/udev.c, this commit adds
a fd member to OdevAttributes to store the fd to pass it along to the driver.
The server_fd
systemd-logind has the ability to manage /dev/... nodes for us, this
includes not only opening them for us, but also getting/setting drm master on
vtenter/vtleave for drm nodes, and revoking access on vtleave + providing
a new fd on vtenter for evdev nodes.
Using systemd-logind under Linux for
Signed-off-by: Hans de Goede hdego...@redhat.com
---
config/udev.c| 35 ++--
hw/xfree86/os-support/linux/systemd-logind.c | 4
include/hotplug.h| 4
3 files changed, 41 insertions(+), 2 deletions(-)
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/intel_device.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/src/intel_device.c b/src/intel_device.c
index 4d08a6e..4378e66 100644
--- a/src/intel_device.c
+++ b/src/intel_device.c
@@ -42,6
This commits add the bulk of the systemd-logind integration code, but does
not hook it up yet other then calling its init and fini functions, which
don't do that much.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
configure.ac | 21 ++
With systemd-logind the dbus-core will be used for more then just config.
This patch also makes the building of the dbus-core and udev no longer
mutually exclusive and removes the config_ prefix from the dbus-core symbols.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
config/Makefile.am
With systemd-logind support, the xserver, rather then the drivers will be
responsible for opening/closing the fd for input devices.
This commit adds a new XI86_SERVER_FD flag to indicate to drivers when the
server is managing the fd and they should not open/close it.
This commit also bumps the
This commits makes the changes necessary outside of the systemd-logind core
to make the server use systemd-logind managed fds for input devices and drm
nodes.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
config/config.c| 5 ++-
config/udev.c
Factor this code out into functions so that it can be re-used for the
systemd-logind device pause/resume paths.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hw/xfree86/common/xf86.h | 4
hw/xfree86/common/xf86Events.c | 52 +++---
2 files
Eric Anholt e...@anholt.net writes:
One of keithp's assumptions has been that you have
reasonable-performance access to the texture memory for doing fallbacks.
It's actually a bit more subtle than that; what I want is to ensure that
when we switch to Glamor, we don't have any performance
Ideally, we'll eventually write code which makes all core operations
faster with the GPU than with the CPU.
What if there is no GPU? Will support for such systems be dropped?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML
Since d9769c193765ac303ad4d4760e57ff368df1f663 DRI_PRIME=1 works
isn't correctly.
1. $ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0x0 crtcs: 2 outputs: 4 associated
providers: 0 name:Intel
Provider 1: id: 0x55 cap: 0xf, Source Output, Sink Output, Source
Hi Keith!
I see a build failure on an openSuSE 13.1 system:
make[2]: Entering directory `/home/knut/fast/xorg/xserver/dix'
CC atom.lo
. ../include/dix-config.h
. /home/knut/fast/xorg/X11-s/usr/include/X11/X.h
. /home/knut/fast/xorg/X11-s/usr/include/X11/Xatom.h
. /usr/include/stdio.h
..
On 01/13/14 05:30 PM, Keith Packard wrote:
Alan Coopersmith alan.coopersm...@oracle.com writes:
Does this need to be #ifdef'ed to avoid breaking people building
1.15.x earlier releases?
No. 'pointer' was just a typedef for 'void *'.
Right, and replacing it doesn't seem to cause any
Alan Coopersmith alan.coopersm...@oracle.com writes:
Right, and replacing it doesn't seem to cause any problems in my
builds here.
Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com
Pushed.
3911ad9..148d89f master - master
--
keith.pack...@intel.com
pgpAQFVxW6UDg.pgp
Hi Peter,
You are so nice to answer all my questions, if you came to China for
travel, I will provide HOST, courchsurfing.org, for you :)
Yes, device node does not change if changed vts, sorry for my poor
English :P
But you still understand what I want, LOL, I will try GrabEventDevice
off
Hi Peter,
You are a good mentor to me :)
Here is xdpyinfo -ext XInputExtension in my box shown as below:
XInputExtension version 2.3 opcode: 131, base event: 66, base error: 129
Extended devices :
Virtual core pointer[XPointer]
Virtual core keyboard[XKeyboard]
Virtual
-Original Message-
From: xorg-devel-boun...@lists.x.org
[mailto:xorg-devel-boun...@lists.x.org]
On Behalf Of Keith Packard
Sent: Thursday, January 16, 2014 1:43 AM
To: Eric Anholt; Michel Dänzer
Cc: xorg-de...@lists.freedesktop.org
Subject: Re: [PATCH 0/4] fb support for 8bpp
On Mit, 2014-01-15 at 01:27 -0800, Eric Anholt wrote:
Michel Dänzer mic...@daenzer.net writes:
On Die, 2014-01-14 at 05:34 -0800, Keith Packard wrote:
Michel Dänzer mic...@daenzer.net writes:
Didn't SNA prove though that sharing the same pixel storage for GPU and
CPU doesn't give
Michel Dänzer mic...@daenzer.net writes:
What's the plan for dealing with GPU tiling in this scheme? Disabling
tiling for all textures which could be hit by software fallbacks seems
like a bad plan for GPU performance.
If you can't get the hardware to de-tile, then you can use wfb.
--
Michel Dänzer mic...@daenzer.net writes:
But why are you putting so much effort into trying to share storage
between GPU and CPU for bitmaps, given that SNA has apparently proved
such sharing is not beneficial overall even on Intel GPUs?
Did you look at how 'hard' getting GPU-acceleratable
On Mit, 2014-01-15 at 19:30 -0800, Keith Packard wrote:
Michel Dänzer mic...@daenzer.net writes:
What's the plan for dealing with GPU tiling in this scheme? Disabling
tiling for all textures which could be hit by software fallbacks seems
like a bad plan for GPU performance.
If you
On Mit, 2014-01-15 at 19:43 -0800, Keith Packard wrote:
Michel Dänzer mic...@daenzer.net writes:
But why are you putting so much effort into trying to share storage
between GPU and CPU for bitmaps, given that SNA has apparently proved
such sharing is not beneficial overall even on Intel
34 matches
Mail list logo
