If a slot's ABS_MT_TRACKING_ID event was received during SYN_DROPPED, the
driver isn't aware that a touchpoint has started or ended in that slot. When
the next ABS_MT_TRACKING_ID event arrives, the driver would unconditionally
close or open a new touchpoint. This could lead to two or more
Hi,
On 03/20/2014 01:23 AM, Martin Peres wrote:
On 17/03/2014 17:37, Hans de Goede wrote:
Signed-off-by: Hans de Goede hdego...@redhat.com
Hi Hans,
When compiling these patches, it generated some warnings because NVEntPtr
pNVEnt was not defined in NVEnterVT and NVLeaveVT. I have tested
Signed-off-by: Thomas Klausner w...@netbsd.org
---
Imake.cf | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Imake.cf b/Imake.cf
index 2b6c649..9e438e7 100644
--- a/Imake.cf
+++ b/Imake.cf
@@ -238,8 +238,9 @@ XCOMM $XFree86: xc/config/cf/Imake.cf,v 3.88 2003/12/16
(regardless of server support on this plattform)
Signed-off-by: Thomas Klausner w...@netbsd.org
---
NetBSD.cf | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/NetBSD.cf b/NetBSD.cf
index 7d1afa0..7d9aadd 100644
--- a/NetBSD.cf
+++ b/NetBSD.cf
@@ -596,10 +596,6 @@
On 17 March 2014 12:49, Michael Thayer michael.tha...@oracle.com wrote:
Signed-off-by: Michael Thayer michael.tha...@oracle.com
---
hw/xfree86/common/xf86Events.c | 36
1 file changed, 36 insertions(+)
diff --git a/hw/xfree86/common/xf86Events.c
Signed-off-by: Thomas Klausner w...@netbsd.org
---
Imake.cf | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Imake.cf b/Imake.cf
index 2b6c649..9e438e7 100644
--- a/Imake.cf
+++ b/Imake.cf
@@ -238,8 +238,9 @@ XCOMM $XFree86: xc/config/cf/Imake.cf,v 3.88 2003/12/16
(regardless of server support on this plattform)
Signed-off-by: Thomas Klausner w...@netbsd.org
---
NetBSD.cf | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/NetBSD.cf b/NetBSD.cf
index 7d1afa0..7d9aadd 100644
--- a/NetBSD.cf
+++ b/NetBSD.cf
@@ -596,10 +596,6 @@
When a video driver changed the availability of hw cursor inside the
xf86SetCursor() call, f86CursorSetCursor() still assumes the hw
cursor and clears SWCursor flag of the screen unconditionally. This
results in the inconsistent state, typically the invisible cursor
pointer. For example, the
Keith Packard kei...@keithp.com writes:
This just adds a bunch of support code to construct shaders from
'facets', which bundle attributes needed for each layer of the
rendering system. At this point, that includes only the primtive and
the fill stuff.
Signed-off-by: Keith Packard
Markus Wick mar...@selfnet.de writes:
Am 2014-03-19 06:09, schrieb Keith Packard:
These use glTexSubimage2D for upload and glReadPixels for
download. There are a variety of interfaces to the basic function as
needed by the callers.
Signed-off-by: Keith Packard kei...@keithp.com
---
Daniel Stone dan...@fooishbar.org writes:
Hi,
On 19 March 2014 05:09, Keith Packard kei...@keithp.com wrote:
+glPixelStorei(GL_UNPACK_ROW_LENGTH, byte_stride / bytes_per_pixel);
This isn't natively supported on GLES; it requires
GL_EXT_unpack_subimage, which isn't available on the vast
Sorry for sending these without proper module name in the subject,
I've resent them.
Thomas
On Thu, Mar 20, 2014 at 11:33:40AM +0100, Thomas Klausner wrote:
Signed-off-by: Thomas Klausner w...@netbsd.org
---
Imake.cf | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
Keith Packard kei...@keithp.com writes:
I couldn't get the existing paths to work and they made no sense, so I
just wrote new ones.
Signed-off-by: Keith Packard kei...@keithp.com
---
glamor/Makefile.am | 2 +
glamor/glamor_prepare.c | 167
Eric Anholt e...@anholt.net writes:
So, are lame GLES drivers something we really need to support?
I'm certainly willing to review patches that broaden the hardware
support; if it's really lame, we can always reject them :-)
--
keith.pack...@intel.com
pgpLofc0vljbu.pgp
Description: PGP
Eric Anholt e...@anholt.net writes:
This comment is stale now that center_offset exists.
I've moved and re-worded it:
/*
* To get GL_POINTS drawn in the right spot, we need to adjust the
* coordinates by 1/2 a pixel.
*/
if (center_offset)
center_adjust = 0.5f;
Eric Anholt e...@anholt.net writes:
For novices to X, an explanatory comment about the region twiddling
stuff here might be nice:
/* In X, multiple Drawables can be stored in the same Pixmap (such as
* each individual window in a non-composited screen pixmap, or the
* reparented window
Markus Wick mar...@selfnet.de writes:
So in the end, I suggest to use PBO all the time. It's likely an
overhead compared to the internal staging buffer of the driver, but imo
this shouldn't matter compared with the memcpy time.
As you'll note, the fallback API does use PBOs through this
Markus Wick mar...@selfnet.de writes:
I'd move glamor_get_context here. There is no need in calling get + put
context when the shader isn't available.
Sure. It shouldn't be common for compiling to fail though, unless your
driver doesn't support the required GLSL version.
Is it allowed to
Markus Wick mar...@selfnet.de writes:
This will crash when GL_ARB_instanced_arrays isn't available.
Yeah, we need some infrastructure for testing and saving GL features...
What are common values for RegionNumRects(gc-pCompositeClip)?
1.
For lots (3+) of boxes, it's likely faster to pass
Markus Wick mar...@selfnet.de writes:
You haven't used reverse, upsidedown and closure. Aren't they needed?
reverse and upsidedown are required when doing software overlapping
blts; but glCopyPixels handles those internally. 'closure' is a left
over from some ancient drawing code requirements;
Keith Packard kei...@keithp.com writes:
This accelerates poly_fill_rect using GPU-based geometry computation
Signed-off-by: Keith Packard kei...@keithp.com
diff --git a/glamor/glamor_rects.c b/glamor/glamor_rects.c
new file mode 100644
index 000..22bb313
--- /dev/null
+++
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
conf/11-x11-synaptics.fdi | 9 +
conf/50-synaptics.conf| 12
2 files changed, 21 insertions(+)
diff --git a/conf/11-x11-synaptics.fdi b/conf/11-x11-synaptics.fdi
index a898875..44dfce3 100644
---
Markus Wick mar...@selfnet.de writes:
I think this functions are worth to reimplement. eg horizontal lines are
used a lot and very slow on mi.
Having sped up the underlying functions, they're not terrible at this
point:
200 reps @ 0.0035 msec (288000.0/sec): 500-pixel horizontal
Markus Wick mar...@selfnet.de writes:
This patch series is a very nice cleanup. I like the new way how this
functions should be implemented, but the shader generator. Plain GLSL +
predefined header are less confusing and more flexible imo.
We also have to figure out on which gl extension
Markus Wick mar...@selfnet.de writes:
Rebase failure.
Yeah, I noticed that. The newer series fixes this.
--
keith.pack...@intel.com
pgp742uIN3_Zt.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives:
Markus Wick mar...@selfnet.de writes:
Yeah, this fixes a crash in
kdrive: Remove duplicated definitions of some XV-related structs..
But as this patch was skipped in the megaseries, there is no need in
only applying this fix.
Maybe squashing both patches together as the origin was a nice
Markus Wick mar...@selfnet.de writes:
First, I like to have some common functions to compile our shaders, bind
common uniforms, defining common headers, ...
But tbh I don't see why it's easier to split up the glsl source
completely. Most shaders aren't more than 5 loc, so they are easier to
Am 2014-03-20 23:07, schrieb Keith Packard:
+glCopyPixels (dx1 + dx - src_box-x1,
+ dy1 + dy - src_box-y1,
+ dx2 - dx1, dy2 - dy1, GL_COLOR);
This functions are deprecated fortunately. Please don't use them
Markus Wick mar...@selfnet.de writes:
This one looks so similiar with your last one, isn't there a way to
merge them?
The fill style is merged because of the shared programs, but yeah, there
is a bunch of nearly-duplicate code and it would be nice to share a bit
more. The goal of both is to
Markus Wick mar...@selfnet.de writes:
+glamor_get_context(glamor_priv);
+
+if (prog-failed) {
+glamor_put_context(glamor_priv);
Why don't you check this issue before calling glamor_get_context?
Could do, but compiles shouldn't fail?
What do you think about a small API
Am 2014-03-20 23:35, schrieb Keith Packard:
We are used to also disable the gl program here unnecessaryly.
I want to strip them all, so I'm fine without it, but it isn't fair
for
a performance comparison.
I stripped them out in an earlier patch; we could measure performance
at
that point?
Am 2014-03-20 23:22, schrieb Keith Packard:
I think this functions are worth to reimplement. eg horizontal lines
are
used a lot and very slow on mi.
Having sped up the underlying functions, they're not terrible at this
point:
200 reps @ 0.0035 msec (288000.0/sec): 500-pixel
Keith Packard kei...@keithp.com writes:
Use mi line code for now
x11perf -vseg100:
x before
+ after
+--+
| + x |
| +
On Fri, Mar 21, 2014 at 08:18:54AM +1000, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
update on this, Adam Williamson just notified me that two-finger scrolbefore
merging.
Cheers,
Peter
---
conf/11-x11-synaptics.fdi | 9 +
Keith Packard kei...@keithp.com writes:
This just calls miPushPixels until glamor uses FBOs for bitmaps
The only cases that PushPixels() is called that I can find:
- miglblt.c
We're doing hand-accelerated glyph blits, so that's gone.
- miarc.c
I tried a few likely x11perfs and nothing hit
Markus Wick mar...@selfnet.de writes:
more important to only get one mipmap level: max_level = 0
I copied this code from elsewhere; do you have a substitute suggestion?
Here you hope that the driver detects that this texture isn't in use.
Else you maybe get some kind of async upload /
Markus Wick mar...@selfnet.de writes:
Patch 1 seems to fix my issue on nvidia, so:
Tested-by: Markus Wick mar...@selfnet.de
Patches 2-5 are:
Reviewed-by: Markus Wick mar...@selfnet.de
Patches 7-9 are really nice, but there should be a glsl130+instancing
fallback with another vertex
This was required when we started supporting hotplugging to avoid duplicate
events. These days the drawback of not being able to record events in the case
of a bug is significant, possibly more so than whatever static
configurations are still out there. Let's see how much pain this causes.
On Thu, Mar 20, 2014 at 7:23 PM, Eric Anholt e...@anholt.net wrote:
Keith Packard kei...@keithp.com writes:
This just calls miPushPixels until glamor uses FBOs for bitmaps
The only cases that PushPixels() is called that I can find:
- miglblt.c
We're doing hand-accelerated glyph blits,
39 matches
Mail list logo
