[PATCH] glx: Fix checking GL version
Signed-off-by: Bartosz Brachaczek b.brachac...@gmail.com
---
Hi,
I looked at Ian's patch out of curiosity and spotted this typo.
Not sure if I am supposed to send a full-blown patch for this, but
I didn't have a better idea.
glx/glxdri2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 1e99179..2db12b6 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -481,7 +481,7 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
uint32_t *attribs,
* don't support OpenGL 3.2 may fail the request for a core profile.
*/
if (*api == __DRI_API_OPENGL_CORE
- (*major_ver 3 || (*major_ver 3 *minor_ver 2))) {
+ (*major_ver 3 || (*major_ver == 3 *minor_ver 2))) {
*api == __DRI_API_OPENGL;
}
--
1.7.8.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Fwd: [PATCH 3/3] evdev: Don't post REL_MISC events as axis motion. (#24737)
2010/8/16 Peter Hutterer peter.hutte...@who-t.net: On Fri, Aug 13, 2010 at 02:12:41PM +0200, Bartosz Brachaczek wrote: Actually this REL_MISC event doesn't affect x/y motion, at least for me, as long as the bug fixed by patches 1, 2 is fixed (though Bartek Iwaniec had problems with it, see https://bugs.freedesktop.org/show_bug.cgi?id=24737#c19). The problem caused by REL_MISC is described in this comment: https://bugs.freedesktop.org/show_bug.cgi?id=24737#c29. Anyway, you can see that REL_MISC events sent by this device are obviously wrong and confusing: # ./evtest /dev/input/event6 [..] Event: time 1281700515.957497, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.957498, -- Report Sync Event: time 1281700515.965503, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.965505, -- Report Sync Event: time 1281700515.973505, type 2 (Relative), code 0 (X), value 2 Event: time 1281700515.973509, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.973510, -- Report Sync Event: time 1281700515.981509, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.981512, -- Report Sync Event: time 1281700515.997508, type 2 (Relative), code 1 (Y), value -2 Event: time 1281700515.997511, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.997512, -- Report Sync Event: time 1281700516.005506, type 2 (Relative), code 0 (X), value 1 Event: time 1281700516.005509, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700516.005510, -- Report Sync Event: time 1281700516.013504, type 2 (Relative), code 0 (X), value 2 Event: time 1281700516.013508, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700516.013509, -- Report Sync Event: time 1281700516.021506, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700516.021510, -- Report Sync Event: time 1281700516.029508, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700516.029511, -- Report Sync Maybe kernel should have a quirk for this device? yeah, possibly. but with your patches applied (except for the REL_MISC one) this only results in spare motion events that don't actually do anything (the GIMP may get confused though). I've tested this with a software emulation device and everything seemed to work fine. I've pushed the other two patches, thanks for your efforts. Cheers, Peter The problem is that the X server still posts MotionNotify events because of these REL_MISC events, which according to libX11 specs (section 10.5.2) is incorrect because MotionNotify indicates that the pointer moved, which isn't the case here. So either evdev should not post REL_MISC as a motion event or X server should check if the pointer actually moved before posting MotionNotify event. Cheers, Bartosz ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Fwd: [PATCH 3/3] evdev: Don't post REL_MISC events as axis motion. (#24737)
2010/8/17 Peter Hutterer peter.hutte...@who-t.net: On Mon, Aug 16, 2010 at 12:50:16PM +0200, Bartosz Brachaczek wrote: The problem is that the X server still posts MotionNotify events because of these REL_MISC events, which according to libX11 specs (section 10.5.2) is incorrect because MotionNotify indicates that the pointer moved, which isn't the case here. So either evdev should not post REL_MISC as a motion event or X server should check if the pointer actually moved before posting MotionNotify event. this is a server bug, but afaict not much of an issue at this point, I don't know of an application that screws up because it gets two MotionNotifies with the same x/y coordinates. If there is one that would up the priority a bit but this bug has been around since at least 1.7. http://bugs.freedesktop.org/show_bug.cgi?id=23985 Cheers, Peter Actually some KDE elements get confused and act incorrectly because of getting a MotionNotify between ButtonPress and ButtonRelease when the user didn't move his device. It is very annoying and it's described in bug #24737, comment 29: http://bugs.freedesktop.org/show_bug.cgi?id=24737#c29 Cheers, Bartosz ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix: don't create core motion events for non-x/y valuators.
2010/8/17 Peter Hutterer peter.hutte...@who-t.net:
Devices that send motion events with valuators other than x/y get core
motion events with unchanged x/y coordinates. This confuses some
applications.
If the DeviceEvent does not have the x/y valuators set, return BadMatch on
core conversion, thus skipping the event altogether.
Reported-by: Bartosz Brachaczek b.brachac...@gmail.com
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/eventconvert.c | 9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/dix/eventconvert.c b/dix/eventconvert.c
index 4e3de0b..0f747c1 100644
--- a/dix/eventconvert.c
+++ b/dix/eventconvert.c
@@ -102,6 +102,15 @@ EventToCore(InternalEvent *event, xEvent *core)
switch(event-any.type)
{
case ET_Motion:
+ {
+ DeviceEvent *e = event-device_event;
+ /* Don't create core motion event if neither x nor y are
+ * present */
+ if (!BitIsOn(e-valuators.mask, 0)
+ !BitIsOn(e-valuators.mask, 1))
+ return BadMatch;
+ }
+ /* fallthrough */
case ET_ButtonPress:
case ET_ButtonRelease:
case ET_KeyPress:
--
1.7.2.1
Tested-by: Bartosz Brachaczek b.brachac...@gmail.com
This fixes the issue for me. Thanks a lot!
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Fwd: [PATCH 3/3] evdev: Don't post REL_MISC events as axis motion. (#24737)
), code 9 (Misc), value 8 Event: time 1281700516.029511, -- Report Sync Maybe kernel should have a quirk for this device? Cheers, Bartosz 2010/8/13 Peter Hutterer peter.hutte...@who-t.net: On Tue, Aug 10, 2010 at 10:32:08PM +0200, Bartosz Brachaczek wrote: Some devices, notably A4Tech X-750F, send unknown events with non-zero value after almost every other event which kernel interprets as REL_MISC. It results in a motion event sent between all key press/release events, which is incorrect and may unnecessarily trigger drag'n'drop actions. X.Org Bug 24737 http://bugs.freedesktop.org/show_bug.cgi?id=24737 Signed-off-by: Bartosz Brachaczek b.brachac...@gmail.com Tested-by: Bartek Iwaniec has...@gmail.com --- src/evdev.c | 5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index 31fe1d6..ca9dc6f 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -500,7 +500,10 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo, struct input_event *ev) EvdevQueueButtonClicks(pInfo, wheel_left_button, -value); break; - /* We don't post wheel events as axis motion. */ + case REL_MISC: + break; + + /* We don't post wheel/misc events as axis motion. */ default: /* Ignore EV_REL events if we never set up for them. */ if (!(pEvdev-flags EVDEV_RELATIVE_EVENTS)) -- 1.7.2 Can you provide the evtest or evtest-capture output for such a device? REL_MISC should just be handled as another axis and if it's non-zero, it should not affect x/y motion. I merged the other two, will push after a bit of testing. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 3/3] evdev: Don't post REL_MISC events as axis motion. (#24737)
), code 9 (Misc), value 8 Event: time 1281700516.029511, -- Report Sync Maybe kernel should have a quirk for this device? Cheers, Bartosz // Sorry for spam, apparently I can't use my mail client. 2010/8/13 Bartosz Brachaczek b.brachac...@gmail.com: Actually this REL_MISC event doesn't affect x/y motion, at least for me, as long as the bug fixed by patches 1, 2 is fixed (though Bartek Iwaniec had problems with it, see https://bugs.freedesktop.org/show_bug.cgi?id=24737#c19). The problem caused by REL_MISC is described in this comment: https://bugs.freedesktop.org/show_bug.cgi?id=24737#c29. Anyway, you can see that REL_MISC events sent by this device are obviously wrong and confusing: # ./evtest /dev/input/event6 Input driver version is 1.0.0 Input device ID: bus 0x3 vendor 0x9da product 0xe version 0x110 Input device name: A4Tech PS/2+USB Mouse Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 272 (LeftBtn) Event code 273 (RightBtn) Event code 274 (MiddleBtn) Event code 275 (SideBtn) Event code 276 (ExtraBtn) Event code 277 (ForwardBtn) Event code 278 (BackBtn) Event code 279 (TaskBtn) Event type 2 (Relative) Event code 0 (X) Event code 1 (Y) Event code 8 (Wheel) Event code 9 (Misc) Event type 4 (Misc) Event code 4 (ScanCode) Grab succeeded, ungrabbing. Testing ... (interrupt to exit) Event: time 1281700496.957417, type 4 (Misc), code 4 (ScanCode), value 90001 Event: time 1281700496.957419, type 1 (Key), code 272 (LeftBtn), value 1 Event: time 1281700496.957421, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700496.957422, -- Report Sync Event: time 1281700497.061417, type 4 (Misc), code 4 (ScanCode), value 90001 Event: time 1281700497.061420, type 1 (Key), code 272 (LeftBtn), value 0 Event: time 1281700497.061422, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700497.061423, -- Report Sync Event: time 1281700501.973438, type 4 (Misc), code 4 (ScanCode), value 90002 Event: time 1281700501.973440, type 1 (Key), code 273 (RightBtn), value 1 Event: time 1281700501.973442, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700501.973443, -- Report Sync Event: time 1281700502.125445, type 4 (Misc), code 4 (ScanCode), value 90002 Event: time 1281700502.125447, type 1 (Key), code 273 (RightBtn), value 0 Event: time 1281700502.125449, type 2 (Relative), code 9 (Misc), value 8 // till this moment I was only clicking buttons, no motion; below is some motion Event: time 1281700502.125450, -- Report Sync Event: time 1281700515.917507, type 2 (Relative), code 0 (X), value 1 Event: time 1281700515.917510, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.917511, -- Report Sync Event: time 1281700515.925532, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.925534, -- Report Sync Event: time 1281700515.933494, type 2 (Relative), code 0 (X), value 2 Event: time 1281700515.933496, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.933496, -- Report Sync Event: time 1281700515.941496, type 2 (Relative), code 0 (X), value 1 Event: time 1281700515.941498, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.941499, -- Report Sync Event: time 1281700515.949496, type 2 (Relative), code 0 (X), value 2 Event: time 1281700515.949498, type 2 (Relative), code 1 (Y), value -1 Event: time 1281700515.949499, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.949500, -- Report Sync Event: time 1281700515.957495, type 2 (Relative), code 0 (X), value 1 Event: time 1281700515.957497, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.957498, -- Report Sync Event: time 1281700515.965503, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.965505, -- Report Sync Event: time 1281700515.973505, type 2 (Relative), code 0 (X), value 2 Event: time 1281700515.973509, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.973510, -- Report Sync Event: time 1281700515.981509, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.981512, -- Report Sync Event: time 1281700515.997508, type 2 (Relative), code 1 (Y), value -2 Event: time 1281700515.997511, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700515.997512, -- Report Sync Event: time 1281700516.005506, type 2 (Relative), code 0 (X), value 1 Event: time 1281700516.005509, type 2 (Relative), code 9 (Misc), value 8 Event: time 1281700516.005510, -- Report Sync Event: time 1281700516.013504, type 2
[PATCH 1/3] evdev: Revert Set all valuators for relative motion events (#24737)
It isn't necessary to post zero-deltas to X Server. In order not to post
uninitialized v array we should rather simply initialize it.
This reverts commit c1f16a4f59a584ab4546c2f16e20b06703042057.
Signed-off-by: Bartosz Brachaczek b.brachac...@gmail.com
---
src/evdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index cd0fb6c..18f3fb7 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -386,7 +386,7 @@ EvdevProcessValuators(InputInfoPtr pInfo, int
v[MAX_VALUATORS], int *num_v,
for (i = 0; i REL_CNT; i++)
{
int map = pEvdev-axis_map[i];
-if (map != -1)
+if (pEvdev-delta[i] map != -1)
{
v[map] = pEvdev-delta[i];
if (map first)
--
1.7.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/3] evdev: Initialize valuators array. (#24737)
The array needs to be filled with zeros, otherwise we may end up sending
it with random values if non-zero values aren't in one row (which is the
case for A4Tech X-750F which sends REL_MISC events without a reason).
X.Org Bug 24737 http://bugs.freedesktop.org/show_bug.cgi?id=24737
Signed-off-by: Bartosz Brachaczek b.brachac...@gmail.com
Tested-by: Bartek Iwaniec has...@gmail.com
---
src/evdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 18f3fb7..31fe1d6 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -662,7 +662,7 @@ static void
EvdevProcessSyncEvent(InputInfoPtr pInfo, struct input_event *ev)
{
int num_v = 0, first_v = 0;
-int v[MAX_VALUATORS];
+int v[MAX_VALUATORS] = {};
EvdevPtr pEvdev = pInfo-private;
EvdevProcessValuators(pInfo, v, num_v, first_v);
--
1.7.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/3] evdev: Don't post REL_MISC events as axis motion. (#24737)
Some devices, notably A4Tech X-750F, send unknown events with non-zero value after almost every other event which kernel interprets as REL_MISC. It results in a motion event sent between all key press/release events, which is incorrect and may unnecessarily trigger drag'n'drop actions. X.Org Bug 24737 http://bugs.freedesktop.org/show_bug.cgi?id=24737 Signed-off-by: Bartosz Brachaczek b.brachac...@gmail.com Tested-by: Bartek Iwaniec has...@gmail.com --- src/evdev.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index 31fe1d6..ca9dc6f 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -500,7 +500,10 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo, struct input_event *ev) EvdevQueueButtonClicks(pInfo, wheel_left_button, -value); break; -/* We don't post wheel events as axis motion. */ +case REL_MISC: +break; + +/* We don't post wheel/misc events as axis motion. */ default: /* Ignore EV_REL events if we never set up for them. */ if (!(pEvdev-flags EVDEV_RELATIVE_EVENTS)) -- 1.7.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
