On Mon, 2014-03-24 at 09:45 +1000, Peter Hutterer wrote:
other than that this seems to be the best solution, thanks.
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
though I'll still ship the xorg.conf snippet in fedora until this filters
down.
The kernel package maintainers might not
The width parameter is used to restrict the blit fast-path (memcpy) when
the source and destination rows overlap. This check was added in [0].
Unfortunately, the calculation to determine if source and destination
lines overlapped was incorrect:
(1) it trys to convert width from pixels to
Hi,
On 03/24/2014 12:45 AM, Peter Hutterer wrote:
On Fri, Mar 21, 2014 at 11:03:36AM +0100, Hans de Goede wrote:
Hi,
On 03/21/2014 10:31 AM, Hans de Goede wrote:
Hi,
On 03/20/2014 11:18 PM, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
On 12/03/2014 06:43, Peter Hutterer wrote:
On Fri, Mar 07, 2014 at 02:32:27PM -0800, Kristian Høgsberg wrote:
From: Rui Matos
This will also make it useful for cases when we have a new keymap to
apply to a device but don't have a source device.
Reviewed-by: Kristian Høgsberg
When we're using server managed-fds through systemd-logind, systemd-logind
*must* keep running while we are using it, as it does things like drmSetMaster
and drmDropMaster for us on vt-switch.
On a systemd-logind restart, we cannot simply re-connect since we will then
get a different fd for the
On Mon, 2014-03-24 at 15:29 +0800, Daniel Kurtz wrote:
This bug causes us to take the slow path for large non-overlapping rows
that are close in memory. As a data point, XGetImage(1366x768) on my
ARM chromebook was taking ~140 ms, but with this fixed, it now takes
about 60 ms.
XGetImage()
When no logfile was specified (xf86LogFileFrom == X_DEFAULT) and we're not
running as root log to $XDG_DATA_HOME/xorg/Xorg.#.log as Xorg won't be able to
log to the default /var/log/... when it is not running as root.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hw/xfree86/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am
index a315bbc..5cdecd9 100644
--- a/hw/xfree86/Makefile.am
+++ b/hw/xfree86/Makefile.am
@@ -105,6 +105,7 @@ if
In MousePickProtocol() with protocol PROT_AUTO we probe for the protocol to
use but drop the result in most cases. This was causing DEVICE_INIT and
DEVICE_ON to fail to be called with the VUID protocol. Git history suggests
that this code was originally meant to cover both PS/2 auto-detection
Jon TURNEY (2):
Fix ephyr build with --disable-glamor
Fix build when configured --enable-debug
hw/kdrive/ephyr/hostx.c| 5 -
hw/xfree86/parser/DRI.c| 1 +
hw/xfree86/parser/Extensions.c | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
--
1.8.3.4
Include os.h for ErrorF() to fix implicit-function-declaration warnings when
configured with --enable-debug.
hw/xfree86/parser/DRI.c: In function 'xf86parseDRISection':
hw/xfree86/parser/DRI.c:87:5: error: implicit declaration of function 'ErrorF'
[-Werror=implicit-function-declaration]
See http://tinderbox.x.org/builds/2014-03-23-0010/logs/xserver/#build
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/kdrive/ephyr/hostx.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
index 3260d95..3c8b49d
Daniel Kurtz djku...@chromium.org writes:
+ int srcX,/* bits */
+ FbBits * dstLine,/* pixels */
+ FbStride dstStride, /* pixels */
FbStride is in FbBits units, not pixels (yes, at 32bpp, it's the same)
+ int dstX,/* bits */
+ int width,
Markus Wick mar...@selfnet.de writes:
I don't get it, why are horizontal lines so much faster than vertical
ones?
Presumably due to memory access patterns. When doing a horizontal line,
you're hitting all of the bytes in several cache lines, rather than only
a few bytes in each one. And,
On Wed, Mar 19, 2014 at 7:26 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote:
Handle -displayfd and an explicit display number sensibly, e.g. use the
explicitly specified display number, and write it to the displayfd
I don't think the two options were meant to be used together, but I
can see
It should be. Some of the tests rely on linux/input.h to get KEY_*
definitions, but you could just copy that and it'll work fine. The
only test which will break would be interactive.c.
It seems you are right. I am not sure that how to run the tests
properly, but at least, I have been able to
Am 2014-03-24 20:47, schrieb Keith Packard:
Even still, uxa is significantly faster than glamor on this one; uxa
has
a simple test for a request that contains only vertical and horizontal
lines and fills those as rectangles. We could easily do the same thing
in glamor, which should yield better
Markus Wick mar...@selfnet.de writes:
But shouldn't UXA be affected as much as glamor by cache issues?
One would think so, but the 2D engine has a very different memory path
than the 3D engine, and it's barely possible that the fact that there
are a sequence of adjacent lines for this test is
The following changes since commit 0e531fbb97868b9a869044fc5a4f6cb58de6751e:
xkb: add XkbLoadKeymapFromString (2014-03-19 08:37:15 +1000)
are available in the git repository at:
git://people.freedesktop.org/~whot/xserver for-keith
for you to fetch changes up to
Hi,
On 24 March 2014 20:53, wettstein...@solnet.ch wrote:
That is a long way, I am afraid. To demonstrate the correctness of the
X-server implementation by means of a libxkbcommon implementation, the
implementations and the environment they live in must be equivalent.
Even though the
On Mon, Mar 24, 2014 at 02:51:40PM +, Jon TURNEY wrote:
On 12/03/2014 06:43, Peter Hutterer wrote:
On Fri, Mar 07, 2014 at 02:32:27PM -0800, Kristian Høgsberg wrote:
From: Rui Matos
This will also make it useful for cases when we have a new keymap to
apply to a device but don't
21 matches
Mail list logo
