On 28 January 2015 at 09:32, Daniel Martin consume.no...@gmail.com wrote:
On 28 January 2015 at 08:40, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
This is ported from the same code in the ati and intel drivers,
It uses the same option name as nvidia and the
On 28 January 2015 at 08:40, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
This is ported from the same code in the ati and intel drivers,
It uses the same option name as nvidia and the other DDXes to
disable tearing down outputs as it is hard to avoid racing with
On 01/23/2015 09:50 AM, Jonathan Dieter wrote:
Dave, is this what you're looking for in moving it to config/udev.c?
I've also fixed the indentation on the #ifdefs.
Sorry if I'm being a pain, but is there anything else that I need to do
with this patch?
Jonathan
Hi,
On 28-01-15 10:07, Jonathan Dieter wrote:
On 01/23/2015 09:50 AM, Jonathan Dieter wrote:
Dave, is this what you're looking for in moving it to config/udev.c?
I've also fixed the indentation on the #ifdefs.
Sorry if I'm being a pain, but is there anything else that I need to do with
this
So that Xwayland gets re-linked each time glamor is modified.
Signed-off-by: Olivier Fourdan ofour...@redhat.com
---
hw/xwayland/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
index 9945540..ab1bbb6 100644
---
When using glamor (either in Xephyr or Xwayland) on hardware with too
low instructions limit, glamor fallbacks to sw due to large shaders.
This makes glamor unbearably slow on such hardware.
Check reported value for GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB
and fail in glamor_init() if the
On 01/28/2015 07:17 AM, Olivier Fourdan wrote:
When using glamor (either in Xephyr or Xwayland) on hardware with too
low instructions limit, glamor fallbacks to sw due to large shaders.
This makes glamor unbearably slow on such hardware.
Check reported value for
On 28/01/15 21:17, Ian Romanick wrote:
Do we know which GPUs cannot meet this limit and also do not have true
integer support? I wonder if we should go ahead and do the
GL_MESA_shading_language_130 or GL_MESA_gpu_shader_int32 extensions that
we had previously discussed, and remove support for
On 01/28/2015 01:00 PM, Olivier Fourdan wrote:
On 28/01/15 21:17, Ian Romanick wrote:
Do we know which GPUs cannot meet this limit and also do not have true
integer support? I wonder if we should go ahead and do the
GL_MESA_shading_language_130 or GL_MESA_gpu_shader_int32 extensions that
we
From: Dave Airlie airl...@redhat.com
Jonathan Dieter posted a few patches to do this inside the Xorg
server but it makes no sense to do it there, just have the code
we use to probe the device list at startup check seat assignments
using the same code we check at hotplug time.
Signed-off-by: Dave
On Thu, Jan 29, 2015 at 09:23:22AM +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
Jonathan Dieter posted a few patches to do this inside the Xorg
server but it makes no sense to do it there, just have the code
we use to probe the device list at startup check seat assignments
This seems obviously correct.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 01/28/2015 07:12 AM, Olivier Fourdan wrote:
Signed-off-by: Olivier Fourdan ofour...@redhat.com
---
hw/kdrive/ephyr/hostx.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
Signed-off-by: Olivier Fourdan ofour...@redhat.com
---
hw/kdrive/ephyr/hostx.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
index f64861b..6c4d61c 100644
--- a/hw/kdrive/ephyr/hostx.c
+++ b/hw/kdrive/ephyr/hostx.c
On Wed, Jan 28, 2015 at 4:55 PM, Ian Romanick i...@freedesktop.org wrote:
On 01/28/2015 01:00 PM, Olivier Fourdan wrote:
On 28/01/15 21:17, Ian Romanick wrote:
Do we know which GPUs cannot meet this limit and also do not have true
integer support? I wonder if we should go ahead and do the
Nope still not right,
I'll send what I think it should look like in a minute, then someone
can tell me why its wrong :-)
Dave.
On 28 January 2015 at 19:28, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 28-01-15 10:07, Jonathan Dieter wrote:
On 01/23/2015 09:50 AM, Jonathan Dieter wrote:
This device has the trackpoint buttons wired up to the touchpad to send BTN_0,
BTN_1 and BTN_2 for left, right, middle. This conflicts with previous
touchpads that used those event codes for dedicated scroll buttons.
Add an option HasTrackpointButtons that can be set via a xorg.conf.d
snippets.
^
It seems like this should be 30. That will allow the check to keep
working if glamor ever grows support for OpenGL 2.0 (however unlikely
that may be).
Do we know which GPUs cannot meet this limit and also do not have true
integer support? I wonder if we
On Tue, Jan 27, 2015 at 07:11:18PM +0530, Vikas Patil wrote:
Hi,
I am running GENIVI Layermanager (i.e. window manager and compositor based
on GLES2.0 and X11) which doesn't support multi-touch event (i.e.
Xi_TouchBegin, XI_TouchUpdate, XI_TouchEnd) handling and I have a
requirement to
Hi,
On 17 December 2014 at 02:33, Peter Hutterer peter.hutte...@who-t.net wrote:
On Tue, Dec 16, 2014 at 08:15:31AM +, Daniel Stone wrote:
Are you sure this is right? Won't this change it from returning root_[xy]
with current MD pointer co-ordinates to nothing/rubbish?
no, this actually
On 16/12/2014 04:43, Peter Hutterer wrote:
Nothing was using it and if anyone had they would've gotten a warning and
noticed that it doesn't actually work. Drop this, it has been unused for years.
Input ABI 22
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Jeremy, Jon, can you
20 matches
Mail list logo
