Re: [PATCH] Update synaptics to XInput 7 ABI
On Mon, Jun 22, 2009 at 01:56:07AM -0400, Ben Gamari wrote: On Fri, Jun 19, 2009 at 04:34:33PM +1000, Peter Hutterer wrote: On Fri, Jun 19, 2009 at 02:01:30AM -0400, Ben Gamari wrote: How about this one (obviously on top of fd939)? Looks good (once someone figures out the button label situation). So getting the labels right is mostly candy now anyway, and getting them for the ones after 7 is something we can worry about in the future, but don't have to worry about right now. Oops, it seems I messed up. When I tested your patches it turned out that I wasn't actually testing your patches. It seems that providing a label of 0 causes gnome-settings-daemon to crash with the following backtrace, [...] Changing the third argument of the InitPointerDeviceStruct() call in synaptics' DeviceInit() from SYN_MAX_BUTTONS to 7 avoids the crash. Changing it then to 8 (as was done in the case of the above backtrace) triggers the crash. Not really sure what to make of this. Let me know what you think. Thanks, server bug, uncovered by 280b7f92d729ec910ffa3d18dce7bbc215be7a3c. http://bugs.freedesktop.org/show_bug.cgi?id=22392 Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: FreeGLUT MPX patch [was: Unpredictable Behaviour with XI2 and XI_Enter]
after the call to XMapWindow() your client and the WM work in parallel, so it's a race to who is faster - your client in selecting the event mask or the window manager in mapping the window. The correct way to avoid that problem is to simply move the event mask selection up that at the time of mapping, the events are already selected. 1. create window 2. select for core events 3. select for XI2 events. 4. map window server generates events here Hello Peter, many thanks for the explanation. I didn't realize that the WM is involved, too - but thinking about it a bit more, it makes sense. Fixing this in the FreeGLUT patch was almost trivial, so for all interested parties, here's the most current version where XI_Enter now works as expected: http://tisch.sourceforge.net/freeglut-2.6.0-mpx-r3.patch Thanks again, Yours, Florian -- 0666 - Filemode of the Beast ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Xi: Remove redundant and incorrect butmap range check
Maps are CARD8s, therefore checking for values above 255 is completely
unnecessary. Moreover, 0 is a valid value for maps, so the check wasn't
even correct to begin with. This fixes bug #22392, which was uncovered
by commit 280b7f92d729ec910ffa3d18dce7bbc215be7a3c.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
---
dix/inpututils.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/dix/inpututils.c b/dix/inpututils.c
index 79b6ab7..8194e69 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -54,12 +54,6 @@ check_butmap_change(DeviceIntPtr dev, CARD8 *map, int len,
CARD32 *errval_out,
for (i = 0; i len; i++) {
if (dev-button-map[i + 1] != map[i] dev-button-down[i + 1])
return MappingBusy;
-
-if (map[i] 1 || map[i] 255) {
-if (errval_out)
-*errval_out = map[i];
-return -1;
-}
}
return Success;
--
1.6.3.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with resumed suspend: Work (dual/external heads) = Home (built in laptop display)
Okay, nobody liked my questions. ;-) Let me ask a different question, then: Is there a way to query xrandr to give me the current configuration as an xrandr command? That could help give me a workaround. Thanks, Jamie On Thu, Jun 18, 2009 at 1:08 AM, Jamie Jacksonmyspa...@gmail.com wrote: (Ubuntu 9.04) At work, I've got dual head, external monitors (VGA, TDMS-1). If I suspend there, and resume at home (using only built-in LVDS), I get a black screen. I have similar problems when going in reverse. The only way I've been able to recover is via SSH and xrandr, however, my home = work xrandr process is haphazard. While I can usually get it to work, I can only get enough to give me a panel (on the wrong screen, the VGA) to get to the gnome display config gui (where I can finish the proper config, getting the panel on the main TDMS-1, and the auxiliary display on the smaller VGA). When I need to resume at home, I usually bag it, and just hard reset. I've got a few questions: 1. Is there a way to get X to roam better (be smarter about detecting and using displays on resume)? 2. Alternatively, is there some xrandr sequence I can use that makes the home = work transition less awkward? 3. Also, alternatively, what's the sequence for the work = home transition? (This one's a bit of a pain, because I've got to jump through some hoops to SSH in at home, but if I had a sequence, I could script it, and then maybe blindly run my script from a TTY.) Thanks, Jamie ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: unexpected phenomenon on XV texture adapter with no scaling
Roland Scheidegger srol...@tungstengraphics.com writes: With a very quick look at the r600 code, I suggest trying out the attached patch to test my theory about half pixel offsets in hardware. This could mess though with EXA acceleration, so if you see a bit odd corruption don't be surprised :-). I can now confirm this patch, applied to current Fedora 11 xorg-x11-drv-ati-6.12.2-14 driver, fixes this Xv issue on RV6xx. I can't see any EXA corruption. Thanks a lot. I guess it should be aplied to the repository? --- a/src/r6xx_accel.c +++ b/src/r6xx_accel.c @@ -974,7 +974,7 @@ set_default_state(ScrnInfoPtr pScrn, drmBufPtr ib) EREG(ib, PA_SU_POLY_OFFSET_FRONT_OFFSET, 0); EREG(ib, PA_SU_LINE_CNTL, (8 PA_SU_LINE_CNTL__WIDTH_shift)); /* Line width 1 pixel */ -EREG(ib, PA_SU_VTX_CNTL, ((2 PA_SU_VTX_CNTL__ROUND_MODE_shift) | +EREG(ib, PA_SU_VTX_CNTL, ((2 PA_SU_VTX_CNTL__ROUND_MODE_shift) | PIX_CENTER_bit | (5 QUANT_MODE_shift))); /* Round to Even, fixed point 1/256 */ EREG(ib, PA_SU_POLY_OFFSET_CLAMP, 0); -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange mouse behaviour after switching to evdev.
Dnia poniedziałek, 22 czerwca 2009, Peter Hutterer napisał: [...] http://people.freedesktop.org/~whot/evtest.c run this against the mouse's device file (/dev/input/eventX, check in /proc/bus/input/devices for the number) and leave it running. right after the mouse jumps, check the last events in the log it spits out. Is there anything weird? if it's caused by the kernel/hardware then you should see the jump as a large movement. if not, then it's somewhere in the driver or (more likely) the server. Here is the last part before the pointer jumped: Event: time 1245690853.452867, -- Report Sync Event: time 1245690853.476198, type 2 (Relative), code 0 (X), value 9 Event: time 1245690853.476214, type 2 (Relative), code 1 (Y), value -2 Event: time 1245690853.476217, -- Report Sync Event: time 1245690853.477684, type 2 (Relative), code 0 (X), value 3 Event: time 1245690853.477690, type 2 (Relative), code 1 (Y), value -1 Event: time 1245690853.477693, -- Report Sync Event: time 1245690853.482855, type 2 (Relative), code 0 (X), value 3 Event: time 1245690853.482867, -- Report Sync Event: time 1245690853.507963, type 2 (Relative), code 0 (X), value 3 Event: time 1245690853.507975, type 2 (Relative), code 1 (Y), value -2 Event: time 1245690853.507978, -- Report Sync Event: time 1245690853.507982, type 2 (Relative), code 0 (X), value 1 Event: time 1245690853.507985, -- Report Sync Event: time 1245690853.512476, type 2 (Relative), code 1 (Y), value -1 Event: time 1245690853.512483, -- Report Sync Event: time 1245691046.035363, type 3 (Absolute), code 40 (Misc), value 91 Event: time 1245691046.035382, -- Report Sync All other events are type 2 (Relative), just all others, when I move a mouse. The last one is type 3 (Absolute). -- Łukasz Maśko GG: 2441498_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające Nie umiem zainstalować Debiana ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Expected video performance on r700 based cards?
Hi, I just upgraded from Fedora 10 i386 to Fedora 11 x86_64 (by means of a new installation) and have noticed that video performance is now worse than it was before under F10 even though general 2D performance seems to have increased quite a bit. What should I expect in terms of video performance on a 4850 card? Before playing 720p videos consumed relatively little CPU power but now I need a full core to play them. Regards, Dennis ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Remove redundant check, attempt #2
François-Denis Gonthier made the very valid point that the errval_out parameter is now unnecessary without the check. This patch removes it as well. Build-tested but not run yet. - Ben ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Xi: Remove redundant and incorrect butmap range check
Maps are CARD8s, therefore checking for values above 255 is completely
unnecessary. Moreover, 0 is a valid value for maps, so the check wasn't
even correct to begin with. This fixes bug #22392, which was uncovered
by commit 280b7f92d729ec910ffa3d18dce7bbc215be7a3c.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
---
dix/inpututils.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/dix/inpututils.c b/dix/inpututils.c
index 79b6ab7..4a513fc 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -39,8 +39,7 @@
/* Check if a button map change is okay with the device.
* Returns -1 for BadValue, as it collides with MappingBusy. */
static int
-check_butmap_change(DeviceIntPtr dev, CARD8 *map, int len, CARD32 *errval_out,
-ClientPtr client)
+check_butmap_change(DeviceIntPtr dev, CARD8 *map, int len, ClientPtr client)
{
int i, ret;
@@ -54,12 +53,6 @@ check_butmap_change(DeviceIntPtr dev, CARD8 *map, int len,
CARD32 *errval_out,
for (i = 0; i len; i++) {
if (dev-button-map[i + 1] != map[i] dev-button-down[i + 1])
return MappingBusy;
-
-if (map[i] 1 || map[i] 255) {
-if (errval_out)
-*errval_out = map[i];
-return -1;
-}
}
return Success;
@@ -113,7 +106,7 @@ ApplyPointerMapping(DeviceIntPtr dev, CARD8 *map, int len,
ClientPtr client)
int ret;
/* If we can't perform the change on the requested device, bail out. */
-ret = check_butmap_change(dev, map, len, client-errorValue, client);
+ret = check_butmap_change(dev, map, len, client);
if (ret != Success)
return ret;
do_butmap_change(dev, map, len, client);
--
1.6.3.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Applying patch for bug 22383
For bug 22383 (X server stuck in infinite loop on laptop lid close), Jesse Barnes has asked to try applying a very simple patch. However, I don't know how to do that - I've only used packaged code from Ubuntu and/or from various PPAs. Is there a how-to on x.org somewhere I haven't found, or would someone be able to give me some pointers? Thanks, -Mike ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Applying patch for bug 22383
Depending on the patch you may need to recompile Xorg, or not. And I do not think you want to recompile Xorg... What is this patch? On Mon, Jun 22, 2009 at 12:46 PM, Mike.lifeguard mikelifegu...@fastmail.fmwrote: For bug 22383 (X server stuck in infinite loop on laptop lid close), Jesse Barnes has asked to try applying a very simple patch. However, I don't know how to do that - I've only used packaged code from Ubuntu and/or from various PPAs. Is there a how-to on x.org somewhere I haven't found, or would someone be able to give me some pointers? Thanks, -Mike ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RFC: Xv field order
Hi, I'm at a point with all needed hardware info to implement interlaced mode (mainly for perfect Xvideo playback) in intel driver. Now there is another question: how should an Xv client interface with it? Do we have any interlaced field-aware Xv interface? My assumption (please correct if wrong): - it requires interlaced display mode (i830+: practically completed). - the video windows must not be scaled vertically. - there could be progressive, top-field-first or bottom-field-first order. PAL uses (generally) TFF, NTSC - BFF. Video may be in any order and it may change in the middle. - using textured Xv we can have many video windows on one screen. Each can have different field order (progressive, TFF or BFF). This also depends on vertical window position and on panning position. HW support is not a problem. - sync events for TFF and BFF are signaled by interrupts. For progressive video (with interlaced display mode, of course) we can pick any of these two. Now: how is a client going to tell the Xserver that it wants progressive, TFF or BFF video window? Possibilities: - attribute: XV_TOP_FIELD_FIRST, writable by the client. 0 = BFF, 1 = TFF. A client could change the value upon a change in the video material. Could we have 3 values (TFF, BFF, -1 = progressive)? Perhaps a better name/scheme? - different XV ports for TFF and BFF. A client would have to change ports when the video order changes. - adding field order to Xv specs? Should it have anything to do with XvMC? -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: unexpected phenomenon on XV texture adapter with no scaling
Krzysztof Halasa k...@pm.waw.pl writes: It seems that the fix to i915 is: diff --git a/src/i915_video.c b/src/i915_video.c index 1ef58ac..3b4247c 100644 --- a/src/i915_video.c +++ b/src/i915_video.c @@ -136,8 +136,8 @@ I915DisplayVideoTextured(ScrnInfoPtr pScrn, I830PortPrivPtr pPriv, int id, format = COLR_BUF_ARGB | DEPTH_FRMT_24_FIXED_8_OTHER; OUT_BATCH(LOD_PRECLAMP_OGL | - DSTORG_HORT_BIAS(0x80) | - DSTORG_VERT_BIAS(0x80) | + DSTORG_HORT_BIAS(0x8) | + DSTORG_VERT_BIAS(0x8) | format); /* front buffer, pitch, offset */ I think it's safe to commit. Seems like a simple mistake, those fields in that variable seem to be 4-bits wide. Fixes the problem. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Dear Krzysztof, Am Montag, den 22.06.2009, 21:56 +0200 schrieb Krzysztof Halasa: […] I'm at a point with all needed hardware info to implement interlaced mode (mainly for perfect Xvideo playback) in intel driver. Now there is another question: how should an Xv client interface with it? Do we have any interlaced field-aware Xv interface? I am no expert and do not know if it has anything to do with your “problem”, but have you heard of the FRC patches [1] yet? I put Thomas, the author of the patches, to receivers of this message. […] Bests, Paul [1] http://frc.easy-vdr.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Xi: Remove redundant and incorrect butmap range check
On Mon, Jun 22, 2009 at 08:59:45AM -0400, Ben Gamari wrote:
Maps are CARD8s, therefore checking for values above 255 is completely
unnecessary. Moreover, 0 is a valid value for maps, so the check wasn't
even correct to begin with. This fixes bug #22392, which was uncovered
by commit 280b7f92d729ec910ffa3d18dce7bbc215be7a3c.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
---
dix/inpututils.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/dix/inpututils.c b/dix/inpututils.c
index 79b6ab7..8194e69 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -54,12 +54,6 @@ check_butmap_change(DeviceIntPtr dev, CARD8 *map, int len,
CARD32 *errval_out,
for (i = 0; i len; i++) {
if (dev-button-map[i + 1] != map[i] dev-button-down[i + 1])
return MappingBusy;
-
-if (map[i] 1 || map[i] 255) {
-if (errval_out)
-*errval_out = map[i];
-return -1;
-}
}
return Success;
--
1.6.3.1
Merged, thanks. I'll push this in a bit.
I merged this patch not the other. errval_out should be used by this
function. There are two spots where it may return BadDevice, in which case
it should set the client error value to the deviceid.
note that this cannot happen in the current implementation anyway since the
parameters are already checked beforehand but it serves to be correct.
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Current tinderbox regression (pixman, ppc64)
http://tinderbox.x.org/builds/2009-06-23-0002/logs/pixman/#build pixman-fast-path.c: In function 'Store24': pixman-fast-path.c:69: error: invalid operands to binary * (have 'int' and 'uint8_t *') -- Chris Ball c...@laptop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Xi: Remove redundant and incorrect butmap range check
On Tue, Jun 23, 2009 at 09:23:30AM +1000, Peter Hutterer wrote:
On Mon, Jun 22, 2009 at 08:59:45AM -0400, Ben Gamari wrote:
Maps are CARD8s, therefore checking for values above 255 is completely
unnecessary. Moreover, 0 is a valid value for maps, so the check wasn't
even correct to begin with. This fixes bug #22392, which was uncovered
by commit 280b7f92d729ec910ffa3d18dce7bbc215be7a3c.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
---
dix/inpututils.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/dix/inpututils.c b/dix/inpututils.c
index 79b6ab7..8194e69 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -54,12 +54,6 @@ check_butmap_change(DeviceIntPtr dev, CARD8 *map, int
len, CARD32 *errval_out,
for (i = 0; i len; i++) {
if (dev-button-map[i + 1] != map[i] dev-button-down[i + 1])
return MappingBusy;
-
-if (map[i] 1 || map[i] 255) {
-if (errval_out)
-*errval_out = map[i];
-return -1;
-}
}
return Success;
--
1.6.3.1
Merged, thanks. I'll push this in a bit.
I merged this patch not the other. errval_out should be used by this
function. There are two spots where it may return BadDevice, in which case
it should set the client error value to the deviceid.
note that this cannot happen in the current implementation anyway since the
parameters are already checked beforehand but it serves to be correct.
The patch below addresses the above issue.
From 778b8352a322e755b078afa765fc41a4a31ec54c Mon Sep 17 00:00:00 2001
From: Peter Hutterer peter.hutte...@who-t.net
Date: Tue, 23 Jun 2009 11:50:29 +1000
Subject: [PATCH] dix: set the client's error value to the bad deviceid in
check_butmap_change.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/inpututils.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/dix/inpututils.c b/dix/inpututils.c
index 8194e69..378deb0 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -45,11 +45,17 @@ check_butmap_change(DeviceIntPtr dev, CARD8 *map, int len,
CARD32 *errval_out,
int i, ret;
if (!dev || !dev-button)
+{
+client-errorValue = (dev) ? dev-id : 0;
return BadDevice;
+}
ret = XaceHook(XACE_DEVICE_ACCESS, client, dev, DixManageAccess);
if (ret != Success)
+{
+client-errorValue = dev-id;
return ret;
+}
for (i = 0; i len; i++) {
if (dev-button-map[i + 1] != map[i] dev-button-down[i + 1])
--
1.6.3.rc1.2.g0164.dirty
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
