Re: touchpad slight regression (snap: 20141121-20150217)
Hello again On 27/02/15(Fri) 11:40, patrick keshishian wrote: I can confirm this change alone causes no adverse, observable change on my x120e's touchpad. Could you guys confirm that the last fix from Ulf also fixes your issue? https://marc.info/?l=openbsd-techm=142513927519879w=2 Thanks, Martin
Re: touchpad slight regression (snap: 20141121-20150217)
On 3/4/15, Martin Pieuchot mpieuc...@nolizard.org wrote: On 04/03/15(Wed) 10:49, patrick keshishian wrote: On 3/4/15, Martin Pieuchot mpieuc...@nolizard.org wrote: Hello again On 27/02/15(Fri) 11:40, patrick keshishian wrote: I can confirm this change alone causes no adverse, observable change on my x120e's touchpad. Could you guys confirm that the last fix from Ulf also fixes your issue? https://marc.info/?l=openbsd-techm=142513927519879w=2 Hi, Apologies. I thought that patch was sent for comment by experts (there was a lot of questions/second guesses accompanying the referenced post/patch). Testing is always welcome! Is this to be tested on its own or in conjunction with sys/dev/wscons/wsmouse.c patch from this thread? On its own :) This patch seems to work fine. I don't see the issue I reported. Thank you, --patrick Thanks, Martin
Re: touchpad slight regression (snap: 20141121-20150217)
On 3/4/15, Martin Pieuchot mpieuc...@nolizard.org wrote: Hello again On 27/02/15(Fri) 11:40, patrick keshishian wrote: I can confirm this change alone causes no adverse, observable change on my x120e's touchpad. Could you guys confirm that the last fix from Ulf also fixes your issue? https://marc.info/?l=openbsd-techm=142513927519879w=2 Hi, Apologies. I thought that patch was sent for comment by experts (there was a lot of questions/second guesses accompanying the referenced post/patch). Is this to be tested on its own or in conjunction with sys/dev/wscons/wsmouse.c patch from this thread? --patrick
Re: touchpad slight regression (snap: 20141121-20150217)
On 04/03/15(Wed) 10:49, patrick keshishian wrote: On 3/4/15, Martin Pieuchot mpieuc...@nolizard.org wrote: Hello again On 27/02/15(Fri) 11:40, patrick keshishian wrote: I can confirm this change alone causes no adverse, observable change on my x120e's touchpad. Could you guys confirm that the last fix from Ulf also fixes your issue? https://marc.info/?l=openbsd-techm=142513927519879w=2 Hi, Apologies. I thought that patch was sent for comment by experts (there was a lot of questions/second guesses accompanying the referenced post/patch). Testing is always welcome! Is this to be tested on its own or in conjunction with sys/dev/wscons/wsmouse.c patch from this thread? On its own :) Thanks, Martin
Re: touchpad slight regression (snap: 20141121-20150217)
Hi Patrick, hi Henrik,
this is good news, thanks for your help. I hope a fix will be
available soon, be it in this form or another (it might be better
to implement it in wsconscomm).
@Patrick: For a PS/2 mouse the Z value describes the rotation
of the scrolling wheel; for a touchpad that operates in native
mode - which means it isn't emulating a mouse - Z represents the
finger pressure. The W value is a bit weird: Synaptics touchpads
encode a hint to the width of a contact in W, which ranges from 0
to 15: 4 and 5 are for normal contacts, the values from 6 to 15
represent wide - and usually accidental - touches, e.g., with a
palm. The other values don't indicate finger width: 2 and 3 have
special technical meanings, and 0 and 1 indicate a two-finger touch
or a three-finger touch. However, W == 0 can also mean that a touch
has ended, because the hardware sends a packet with all four
coordinates set to zero in this case, and this is what the patches
are about.
On 02/27/2015 08:40 PM, patrick keshishian wrote:
Hi,
On 2/26/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote:
On 02/27/2015 03:31 AM, Ulf Brosziewski wrote:
...
It might be that the following patch to wsmouse.c solves the problem
with the new version of wsconscomm. Tests would be welcome (I could
only verify that the patch does no harm to other touchpad types, i.e.,
Elantech-v4 and Alps Glidepoint).
[...]
Sorry, the change was in the wrong place and would only do a half of
the work. It should look like:
Index: wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.26
diff -u -p -r1.26 wsmouse.c
--- wsmouse.c 27 Oct 2014 13:55:05 - 1.26
+++ wsmouse.c 27 Feb 2015 02:50:06 -
@@ -433,6 +433,9 @@ wsmouse_input(struct device *wsmousedev,
}
}
+ if (sc-sc_z == 0)
+ sc-sc_w = INVALID_W;
+
mb = sc-sc_mb;
while ((d = mb ^ ub) != 0) {
/*
I can confirm this change alone causes no adverse, observable
change on my x120e's touchpad.
With -r1.11 of xenocara/driver/xf86-input-synaptics/wsconscomm.c,
in combination with above patch, I no longer seem to notice the
issue for which this message thread was originated.
However, I would appreciate it if someone could enlighten me
as to what the Z and W axis refer.
Thanks,
--patrick
Re: touchpad slight regression (snap: 20141121-20150217)
That does seem to fix it in my case.
Re: touchpad slight regression (snap: 20141121-20150217)
Hi,
On 2/26/15, Ulf Brosziewski ulf.brosziew...@t-online.de wrote:
On 02/27/2015 03:31 AM, Ulf Brosziewski wrote:
...
It might be that the following patch to wsmouse.c solves the problem
with the new version of wsconscomm. Tests would be welcome (I could
only verify that the patch does no harm to other touchpad types, i.e.,
Elantech-v4 and Alps Glidepoint).
[...]
Sorry, the change was in the wrong place and would only do a half of
the work. It should look like:
Index: wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.26
diff -u -p -r1.26 wsmouse.c
--- wsmouse.c 27 Oct 2014 13:55:05 - 1.26
+++ wsmouse.c 27 Feb 2015 02:50:06 -
@@ -433,6 +433,9 @@ wsmouse_input(struct device *wsmousedev,
}
}
+ if (sc-sc_z == 0)
+ sc-sc_w = INVALID_W;
+
mb = sc-sc_mb;
while ((d = mb ^ ub) != 0) {
/*
I can confirm this change alone causes no adverse, observable
change on my x120e's touchpad.
With -r1.11 of xenocara/driver/xf86-input-synaptics/wsconscomm.c,
in combination with above patch, I no longer seem to notice the
issue for which this message thread was originated.
However, I would appreciate it if someone could enlighten me
as to what the Z and W axis refer.
Thanks,
--patrick
Re: touchpad slight regression (snap: 20141121-20150217)
On 2/26/15, Ulf Brosziewski ulf.brosziew...@t-online.de wrote: On 02/26/2015 02:32 AM, patrick keshishian wrote: On 2/25/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote: On 02/25/2015 11:53 PM, patrick keshishian wrote: Hi, On 2/25/15, joshua steinj...@openbsd.org wrote: On Tue, 24 Feb 2015 at 12:32:10 -0800, patrick keshishian wrote: I'm noticing slight annoyance with recent update from 20141121 snapshot to 20150217. My touchpad, while two-finger scrolling (up/down) sometimes ignores the scrolls. I have to lift my fingers and retry the gesture to initiate the scroll. There was a change to pms(4) (r1.57) but it should only affect elantech touchpads, so it's probably the r1.11 change to the synaptics xorg driver which affects all of them: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c Can you try recompiling that driver with that last revision backed out and see if it fixes the problem? Thanks for the reply and hint. Took me a while longer as I made the mistake of rebuilding the entire xenocara. Indeed this revision seems to be the cause of the issue; at least I've not been able to run into the issue in the last 10 minutes or so, whilst trying my best. Thanks to Henrik Friedrichsen for also confirming the issue and the fix. Cheers, --patrick Unfortunately that fix might reintroduce other problems, at least with other touchpads, and maybe even with yours. For example, if you start a scrolling operation by making two touches at the same time, I would expect that it begins with a jump. Would you mind check that? I can't make any tests myself, there is no synaptics touchpad around here. Hi, I'm not sure what you mean exactly by making two touches at the same time. The way I initiate a scroll is by placing two fingers (typically my index and middle fingers) on the touchpad and moving them up/down or left/right. It has never begun with any jump. The change which prompted this thread, was absolutely annoying. e.g., While reading a PDF document. I'd have to remove my fingers and touch the touchpad again, very frequently, in order to continue scrolling. Where as before (and now with the revision rollback) I can completely concentrate on reading the document. Best, --patrick Hi Patrick, thanks for the reply. What I meant was this: There can be a (possibly small) time interval between the contacts, or this interval can be (nearly) zero. In the first case, the finger count of the driver should change from 0 to 1, then from 1 to 2. If the hardware is not extremely accurate it may change directly from 0 to 2 in the second case. If the hardware *is* very accurate, it may be difficult to produce these double contacts. The test I had in mind could look like this: You move the cursor over a scrollable document, lift the moving finger, then make a double contact on a position that has a noticeable (vertical) distance from the previous contact point. If the document moves/jumps when the double contact is made, there's something wrong. This can happen when the driver doesn't count properly. Hello and thanks for the clarification of your test-case. I have been attempting it this morning, but not able to see any jumps. It seems/feels pretty solid. Sorry, --patrick Regards, Ulf
Re: touchpad slight regression (snap: 20141121-20150217)
On 02/26/2015 06:06 PM, patrick keshishian wrote: On 2/26/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote: On 02/26/2015 02:32 AM, patrick keshishian wrote: On 2/25/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote: ... Hi Patrick, thanks for the reply. What I meant was this: There can be a (possibly small) time interval between the contacts, or this interval can be (nearly) zero. In the first case, the finger count of the driver should change from 0 to 1, then from 1 to 2. If the hardware is not extremely accurate it may change directly from 0 to 2 in the second case. If the hardware *is* very accurate, it may be difficult to produce these double contacts. The test I had in mind could look like this: You move the cursor over a scrollable document, lift the moving finger, then make a double contact on a position that has a noticeable (vertical) distance from the previous contact point. If the document moves/jumps when the double contact is made, there's something wrong. This can happen when the driver doesn't count properly. Hello and thanks for the clarification of your test-case. I have been attempting it this morning, but not able to see any jumps. It seems/feels pretty solid. Sorry, --patrick Regards, Ulf Hi Patrick, may I ask you a last question? Does tapping work with the reverted version?
Re: touchpad slight regression (snap: 20141121-20150217)
On 02/26/2015 02:32 AM, patrick keshishian wrote: On 2/25/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote: On 02/25/2015 11:53 PM, patrick keshishian wrote: Hi, On 2/25/15, joshua steinj...@openbsd.org wrote: On Tue, 24 Feb 2015 at 12:32:10 -0800, patrick keshishian wrote: I'm noticing slight annoyance with recent update from 20141121 snapshot to 20150217. My touchpad, while two-finger scrolling (up/down) sometimes ignores the scrolls. I have to lift my fingers and retry the gesture to initiate the scroll. There was a change to pms(4) (r1.57) but it should only affect elantech touchpads, so it's probably the r1.11 change to the synaptics xorg driver which affects all of them: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c Can you try recompiling that driver with that last revision backed out and see if it fixes the problem? Thanks for the reply and hint. Took me a while longer as I made the mistake of rebuilding the entire xenocara. Indeed this revision seems to be the cause of the issue; at least I've not been able to run into the issue in the last 10 minutes or so, whilst trying my best. Thanks to Henrik Friedrichsen for also confirming the issue and the fix. Cheers, --patrick Unfortunately that fix might reintroduce other problems, at least with other touchpads, and maybe even with yours. For example, if you start a scrolling operation by making two touches at the same time, I would expect that it begins with a jump. Would you mind check that? I can't make any tests myself, there is no synaptics touchpad around here. Hi, I'm not sure what you mean exactly by making two touches at the same time. The way I initiate a scroll is by placing two fingers (typically my index and middle fingers) on the touchpad and moving them up/down or left/right. It has never begun with any jump. The change which prompted this thread, was absolutely annoying. e.g., While reading a PDF document. I'd have to remove my fingers and touch the touchpad again, very frequently, in order to continue scrolling. Where as before (and now with the revision rollback) I can completely concentrate on reading the document. Best, --patrick Hi Patrick, thanks for the reply. What I meant was this: There can be a (possibly small) time interval between the contacts, or this interval can be (nearly) zero. In the first case, the finger count of the driver should change from 0 to 1, then from 1 to 2. If the hardware is not extremely accurate it may change directly from 0 to 2 in the second case. If the hardware *is* very accurate, it may be difficult to produce these double contacts. The test I had in mind could look like this: You move the cursor over a scrollable document, lift the moving finger, then make a double contact on a position that has a noticeable (vertical) distance from the previous contact point. If the document moves/jumps when the double contact is made, there's something wrong. This can happen when the driver doesn't count properly. Regards, Ulf
Re: touchpad slight regression (snap: 20141121-20150217)
On 2/26/15, Ulf Brosziewski ulf.brosziew...@t-online.de wrote: On 02/26/2015 06:06 PM, patrick keshishian wrote: On 2/26/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote: On 02/26/2015 02:32 AM, patrick keshishian wrote: On 2/25/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote: ... Hi Patrick, thanks for the reply. What I meant was this: There can be a (possibly small) time interval between the contacts, or this interval can be (nearly) zero. In the first case, the finger count of the driver should change from 0 to 1, then from 1 to 2. If the hardware is not extremely accurate it may change directly from 0 to 2 in the second case. If the hardware *is* very accurate, it may be difficult to produce these double contacts. The test I had in mind could look like this: You move the cursor over a scrollable document, lift the moving finger, then make a double contact on a position that has a noticeable (vertical) distance from the previous contact point. If the document moves/jumps when the double contact is made, there's something wrong. This can happen when the driver doesn't count properly. Hello and thanks for the clarification of your test-case. I have been attempting it this morning, but not able to see any jumps. It seems/feels pretty solid. Sorry, --patrick Regards, Ulf Hi Patrick, may I ask you a last question? Does tapping work with the reverted version? Hi Ulf, Yes. Tapping works. Double tap to select words, tap + tap- hold-and-drag to select sequence of characters or drag/move windows, etc. Two finger tap to bring up contextual menus .. I've really not had any issues with my touchpad. In fact, I was pleasantly surprised when it just worked out-of-the-box, so to speak. HTH, --patrick
Re: touchpad slight regression (snap: 20141121-20150217)
On 02/26/2015 11:12 PM, patrick keshishian wrote: On 2/26/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote: On 02/26/2015 06:06 PM, patrick keshishian wrote: On 2/26/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote: On 02/26/2015 02:32 AM, patrick keshishian wrote: On 2/25/15, Ulf Brosziewskiulf.brosziew...@t-online.dewrote: ... Hi Patrick, thanks for the reply. What I meant was this: There can be a (possibly small) time interval between the contacts, or this interval can be (nearly) zero. In the first case, the finger count of the driver should change from 0 to 1, then from 1 to 2. If the hardware is not extremely accurate it may change directly from 0 to 2 in the second case. If the hardware *is* very accurate, it may be difficult to produce these double contacts. The test I had in mind could look like this: You move the cursor over a scrollable document, lift the moving finger, then make a double contact on a position that has a noticeable (vertical) distance from the previous contact point. If the document moves/jumps when the double contact is made, there's something wrong. This can happen when the driver doesn't count properly. Hello and thanks for the clarification of your test-case. I have been attempting it this morning, but not able to see any jumps. It seems/feels pretty solid. Sorry, --patrick Regards, Ulf Hi Patrick, may I ask you a last question? Does tapping work with the reverted version? Hi Ulf, Yes. Tapping works. Double tap to select words, tap + tap- hold-and-drag to select sequence of characters or drag/move windows, etc. Two finger tap to bring up contextual menus .. I've really not had any issues with my touchpad. In fact, I was pleasantly surprised when it just worked out-of-the-box, so to speak. HTH, --patrick This leaves me with some puzzles, but thanks for your help and patience.
Re: touchpad slight regression (snap: 20141121-20150217)
On 02/27/2015 03:31 AM, Ulf Brosziewski wrote:
...
It might be that the following patch to wsmouse.c solves the problem
with the new version of wsconscomm. Tests would be welcome (I could
only verify that the patch does no harm to other touchpad types, i.e.,
Elantech-v4 and Alps Glidepoint).
Index: wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.26
diff -u -p -r1.26 wsmouse.c
--- wsmouse.c 27 Oct 2014 13:55:05 - 1.26
+++ wsmouse.c 27 Feb 2015 01:39:29 -
@@ -420,7 +420,7 @@ wsmouse_input(struct device *wsmousedev,
ev-value = w;
TIMESTAMP;
ADVANCE;
- sc-sc_w = w;
+ sc-sc_w = (sc-sc_z == 0 ? INVALID_W : w);
}
} else {
if (sc-sc_dw) {
Sorry, the change was in the wrong place and would only do a half of
the work. It should look like:
Index: wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.26
diff -u -p -r1.26 wsmouse.c
--- wsmouse.c 27 Oct 2014 13:55:05 - 1.26
+++ wsmouse.c 27 Feb 2015 02:50:06 -
@@ -433,6 +433,9 @@ wsmouse_input(struct device *wsmousedev,
}
}
+ if (sc-sc_z == 0)
+ sc-sc_w = INVALID_W;
+
mb = sc-sc_mb;
while ((d = mb ^ ub) != 0) {
/*
Re: touchpad slight regression (snap: 20141121-20150217)
On 02/25/2015 11:53 PM, patrick keshishian wrote:
Hi,
On 2/25/15, joshua steinj...@openbsd.org wrote:
On Tue, 24 Feb 2015 at 12:32:10 -0800, patrick keshishian wrote:
I'm noticing slight annoyance with recent update from 20141121
snapshot to 20150217.
My touchpad, while two-finger scrolling (up/down) sometimes ignores
the scrolls. I have to lift my fingers and retry the gesture to initiate
the scroll.
There was a change to pms(4) (r1.57) but it should only affect
elantech touchpads, so it's probably the r1.11 change to the
synaptics xorg driver which affects all of them:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c
Can you try recompiling that driver with that last revision backed
out and see if it fixes the problem?
Thanks for the reply and hint.
Took me a while longer as I made the mistake of rebuilding
the entire xenocara.
Indeed this revision seems to be the cause of the issue; at
least I've not been able to run into the issue in the last 10
minutes or so, whilst trying my best.
Thanks to Henrik Friedrichsen for also confirming the issue
and the fix.
Cheers,
--patrick
It might be that the following patch to wsmouse.c solves the problem
with the new version of wsconscomm. Tests would be welcome (I could
only verify that the patch does no harm to other touchpad types, i.e.,
Elantech-v4 and Alps Glidepoint).
Index: wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.26
diff -u -p -r1.26 wsmouse.c
--- wsmouse.c 27 Oct 2014 13:55:05 - 1.26
+++ wsmouse.c 27 Feb 2015 01:39:29 -
@@ -420,7 +420,7 @@ wsmouse_input(struct device *wsmousedev,
ev-value = w;
TIMESTAMP;
ADVANCE;
- sc-sc_w = w;
+ sc-sc_w = (sc-sc_z == 0 ? INVALID_W : w);
}
} else {
if (sc-sc_dw) {
Re: touchpad slight regression (snap: 20141121-20150217)
I can confirm this on my Thinkpad X220i.
Re: touchpad slight regression (snap: 20141121-20150217)
On Wed, Feb 25, 2015 at 11:50:55AM -0600, joshua stein wrote: Can you try recompiling that driver with that last revision backed out and see if it fixes the problem? Done. Problem is gone.
Re: touchpad slight regression (snap: 20141121-20150217)
On 02/25/2015 11:53 PM, patrick keshishian wrote: Hi, On 2/25/15, joshua steinj...@openbsd.org wrote: On Tue, 24 Feb 2015 at 12:32:10 -0800, patrick keshishian wrote: I'm noticing slight annoyance with recent update from 20141121 snapshot to 20150217. My touchpad, while two-finger scrolling (up/down) sometimes ignores the scrolls. I have to lift my fingers and retry the gesture to initiate the scroll. There was a change to pms(4) (r1.57) but it should only affect elantech touchpads, so it's probably the r1.11 change to the synaptics xorg driver which affects all of them: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c Can you try recompiling that driver with that last revision backed out and see if it fixes the problem? Thanks for the reply and hint. Took me a while longer as I made the mistake of rebuilding the entire xenocara. Indeed this revision seems to be the cause of the issue; at least I've not been able to run into the issue in the last 10 minutes or so, whilst trying my best. Thanks to Henrik Friedrichsen for also confirming the issue and the fix. Cheers, --patrick Unfortunately that fix might reintroduce other problems, at least with other touchpads, and maybe even with yours. For example, if you start a scrolling operation by making two touches at the same time, I would expect that it begins with a jump. Would you mind check that? I can't make any tests myself, there is no synaptics touchpad around here.
Re: touchpad slight regression (snap: 20141121-20150217)
dmesg OpenBSD 5.7-beta (GENERIC.MP) #856: Tue Feb 17 12:43:12 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3850960896 (3672MB) avail mem = 3744530432 (3571MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf9ba0 (60 entries) bios0: vendor LENOVO version 8FET32WW (1.16 ) date 11/03/2011 bios0: LENOVO 06112EU acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC HPET APIC MCFG UEFI UEFI SSDT SSDT UEFI acpi0: wakeup devices PB4_(S4) PB5_(S4) PB6_(S4) PB7_(S4) OHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3) EHC3(S3) OHC4(S3) SBAZ(S4) GEC_(S4) P2P_(S5) SPB0(S4) SPB1(S4) SPB2(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD E-350 Processor, 19639.39 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD E-350 Processor, 1596.60 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpimcfg0 at acpi0 addr 0xf800, bus 0-31 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB4_) acpiprt2 at acpi0: bus -1 (PB5_) acpiprt3 at acpi0: bus 1 (PB6_) acpiprt4 at acpi0: bus -1 (PB7_) acpiprt5 at acpi0: bus 2 (P2P_) acpiprt6 at acpi0: bus 3 (SPB0) acpiprt7 at acpi0: bus 4 (SPB1) acpiprt8 at acpi0: bus -1 (SPB2) acpiprt9 at acpi0: bus -1 (SPB3) acpiec0 at acpi0 acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpitz0 at acpi0: critical temperature is 92 degC acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB acpithinkpad0 at acpi0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 model 42T4785 serial 3355 type LION oem SANYO acpibtn2 at acpi0: LID_ cpu0: 19639 MHz: speeds: 1600 1280 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00 radeondrm0 at pci0 dev 1 function 0 ATI Radeon HD 6310 rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci0 dev 1 function 1 ATI Radeon HD 6310 HD Audio rev 0x00: msi azalia0: no supported codecs ppb0 at pci0 dev 6 function 0 AMD AMD64 14h PCIE rev 0x00: msi pci1 at ppb0 bus 1 1:0:0: mem address conflict 0xfffe/0x2 re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800), msi, address e8:9a:8f:fa:fa:fa rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 ahci0 at pci0 dev 17 function 0 ATI SBx00 SATA rev 0x00: apic 2 int 19, AHCI 1.2 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: ATA, TOSHIBA MK2555GS, FG00 SCSI3 0/direct fixed naa.5391c6887a53 sd0: 238475MB, 512 bytes/sector, 488397168 sectors ohci0 at pci0 dev 18 function 0 ATI SB700 USB rev 0x00: apic 2 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 ATI SB700 USB2 rev 0x00: apic 2 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 ATI EHCI root hub rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 ATI SB700 USB rev 0x00: apic 2 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 ATI SB700 USB2 rev 0x00: apic 2 int 17 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 ATI EHCI root hub rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 ATI SBx00 SMBus rev 0x42: polling iic0 at piixpm0 spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-10600 SO-DIMM spdmem1 at iic0 addr 0x51: 2GB DDR3 SDRAM PC3-10600 SO-DIMM azalia1 at pci0 dev 20 function 2 ATI SBx00 HD Audio rev 0x40: apic 2 int 16 azalia1: codecs: Conexant/0x5066 audio0 at azalia1 pcib0 at pci0 dev 20 function 3 ATI SB700 ISA rev 0x40 ppb1 at pci0 dev 20 function 4 ATI SB600 PCI rev 0x40 pci2 at ppb1 bus 2 ppb2 at pci0 dev 21 function 0 ATI SB800 PCIE rev 0x00 pci3 at ppb2 bus 3 ppb3 at pci0 dev 21 function 1 ATI SB800 PCIE rev 0x00: msi pci4 at ppb3 bus 4 Realtek 8188CE rev 0x01 at pci4 dev 0 function 0 not configured pchb1 at pci0 dev 24 function
Re: touchpad slight regression (snap: 20141121-20150217)
Hi, On 2/25/15, joshua stein j...@openbsd.org wrote: On Tue, 24 Feb 2015 at 12:32:10 -0800, patrick keshishian wrote: I'm noticing slight annoyance with recent update from 20141121 snapshot to 20150217. My touchpad, while two-finger scrolling (up/down) sometimes ignores the scrolls. I have to lift my fingers and retry the gesture to initiate the scroll. There was a change to pms(4) (r1.57) but it should only affect elantech touchpads, so it's probably the r1.11 change to the synaptics xorg driver which affects all of them: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c Can you try recompiling that driver with that last revision backed out and see if it fixes the problem? Thanks for the reply and hint. Took me a while longer as I made the mistake of rebuilding the entire xenocara. Indeed this revision seems to be the cause of the issue; at least I've not been able to run into the issue in the last 10 minutes or so, whilst trying my best. Thanks to Henrik Friedrichsen for also confirming the issue and the fix. Cheers, --patrick
Re: touchpad slight regression (snap: 20141121-20150217)
On 25/02/15(Wed) 14:53, patrick keshishian wrote: Hi, On 2/25/15, joshua stein j...@openbsd.org wrote: On Tue, 24 Feb 2015 at 12:32:10 -0800, patrick keshishian wrote: I'm noticing slight annoyance with recent update from 20141121 snapshot to 20150217. My touchpad, while two-finger scrolling (up/down) sometimes ignores the scrolls. I have to lift my fingers and retry the gesture to initiate the scroll. There was a change to pms(4) (r1.57) but it should only affect elantech touchpads, so it's probably the r1.11 change to the synaptics xorg driver which affects all of them: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c Can you try recompiling that driver with that last revision backed out and see if it fixes the problem? Thanks for the reply and hint. Took me a while longer as I made the mistake of rebuilding the entire xenocara. Indeed this revision seems to be the cause of the issue; at least I've not been able to run into the issue in the last 10 minutes or so, whilst trying my best. Thanks to Henrik Friedrichsen for also confirming the issue and the fix. Do you guys mind sharing a dmesg? On which touchpad/firmware version do you see this regression?
Re: touchpad slight regression (snap: 20141121-20150217)
On Thu, Feb 26, 2015 at 01:21:23AM +0100, Martin Pieuchot wrote: Do you guys mind sharing a dmesg? On which touchpad/firmware version do you see this regression? Sure: OpenBSD 5.7-beta (GENERIC.MP) #860: Sun Feb 22 03:14:54 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8335577088 (7949MB) avail mem = 8109768704 (7734MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (66 entries) bios0: vendor LENOVO version 8DET69WW (1.39 ) date 07/18/2013 bios0: LENOVO 4290W1A acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz, 2093.50 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz, 2093.20 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz, 2093.20 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz, 2093.20 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 5 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus -1 (EXP7) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2 acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4861 serial 5714 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 2093 MHz: speeds: 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 vga1 at pci0 dev 2 function 0 Intel HD Graphics 3000 rev 0x09 intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1366x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 6 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:5a:e0:f6 ehci0 at pci0 dev 26 function 0 Intel 6 Series USB rev 0x04: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 6 Series HD Audio rev 0x04: msi azalia0: codecs: Conexant/0x506e, Intel/0x2805, using Conexant/0x506e audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 6 Series PCIE rev 0xb4: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 Intel 6 Series PCIE rev 0xb4: msi pci2 at ppb1 bus 3 iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, MIMO 2T2R, MoW, address a0:88:b4:40:98:3c ppb2 at pci0 dev 28 function 3 Intel 6 Series PCIE rev 0xb4: msi pci3
Re: touchpad slight regression (snap: 20141121-20150217)
On 2/25/15, Ulf Brosziewski ulf.brosziew...@t-online.de wrote: On 02/25/2015 11:53 PM, patrick keshishian wrote: Hi, On 2/25/15, joshua steinj...@openbsd.org wrote: On Tue, 24 Feb 2015 at 12:32:10 -0800, patrick keshishian wrote: I'm noticing slight annoyance with recent update from 20141121 snapshot to 20150217. My touchpad, while two-finger scrolling (up/down) sometimes ignores the scrolls. I have to lift my fingers and retry the gesture to initiate the scroll. There was a change to pms(4) (r1.57) but it should only affect elantech touchpads, so it's probably the r1.11 change to the synaptics xorg driver which affects all of them: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c Can you try recompiling that driver with that last revision backed out and see if it fixes the problem? Thanks for the reply and hint. Took me a while longer as I made the mistake of rebuilding the entire xenocara. Indeed this revision seems to be the cause of the issue; at least I've not been able to run into the issue in the last 10 minutes or so, whilst trying my best. Thanks to Henrik Friedrichsen for also confirming the issue and the fix. Cheers, --patrick Unfortunately that fix might reintroduce other problems, at least with other touchpads, and maybe even with yours. For example, if you start a scrolling operation by making two touches at the same time, I would expect that it begins with a jump. Would you mind check that? I can't make any tests myself, there is no synaptics touchpad around here. Hi, I'm not sure what you mean exactly by making two touches at the same time. The way I initiate a scroll is by placing two fingers (typically my index and middle fingers) on the touchpad and moving them up/down or left/right. It has never begun with any jump. The change which prompted this thread, was absolutely annoying. e.g., While reading a PDF document. I'd have to remove my fingers and touch the touchpad again, very frequently, in order to continue scrolling. Where as before (and now with the revision rollback) I can completely concentrate on reading the document. Best, --patrick
touchpad slight regression (snap: 20141121-20150217)
Hi, I'm noticing slight annoyance with recent update from 20141121 snapshot to 20150217. My touchpad, while two-finger scrolling (up/down) sometimes ignores the scrolls. I have to lift my fingers and retry the gesture to initiate the scroll. Full Xorg.0.log at the end, but here is a diff with last snapshot's one where I did not have this issue. two notes: 1. Only thing different w/respect to my configuration is, I removed sections I used to have for usbtablet. b/c after a sleep/wake cycle the usbtablet would not reattach to X (requiring an X restart). 2. two entries seen in this diff with Applying InputClass ... are marked with (**)' from config file. This is a lie. my current xorg.conf follows. --- /tmp/a Tue Feb 24 12:12:49 2015 +++ /tmp/b Tue Feb 24 12:12:32 2015 @@ -6,12 +6,12 @@ [ ] linear framebuffer access unavailable [ ] (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode (version 3.32) [ ] -[ ]er 1.16.1 -[ ]: 2014-09-21 +[ ]er 1.16.4 +[ ]: 2014-12-20 [ ] X Protocol Version 11, Revision 0 -[ ] Build Operating System: OpenBSD 5.6 amd64 -[ ] Current Operating System: OpenBSD noir.boxsoft.com 5.6 GENERIC.MP#592 amd64 -[ ] Build Date: 18 November 2014 01:12:21AM +[ ] Build Operating System: OpenBSD 5.7 amd64 +[ ] Current Operating System: OpenBSD noir.boxsoft.com 5.7 GENERIC.MP#856 amd64 +[ ] Build Date: 17 February 2015 12:12:30PM [ ] [ ] Current version of pixman: 0.32.6 [ ] Before reporting problems, check http://wiki.x.org @@ -19,17 +19,15 @@ [ ] Markers: (--) probed, (**) from config file, (==) default setting, [ ]ommand line, (!!) notice, (II) informational, [ ]g, (EE) error, (NI) not implemented, (??) unknown. -[ ] (==) Log file: /var/log/Xorg.0.log, Time: Sun Nov 23 14:10:20 2014 +[ ] (==) Log file: /var/log/Xorg.0.log, Time: Thu Feb 19 11:03:10 2015 [ ] (==) Using config file: /etc/X11/xorg.conf [ ] (==) Using system config directory /usr/X11R6/share/X11/xorg.conf.d -[ ] (==) ServerLayout Layout0 +[ ] (==) No Layout section. Using the first Screen section. [ ] (==) No screen section available. Using defaults. [ ] (**) |--Screen Default Screen Section (0) [ ] (**) | |--Monitor default monitor [ ] (==) No monitor specified for screen Default Screen Section. [ ]ault monitor configuration. -[ ] (**) |--Input Device w_stylus -[ ] (**) Option AllowMouseOpenFail True [ ] (==) Disabling SIGIO handlers for input devices [ ] (==) Automatically adding devices [ ] (==) Automatically enabling devices @@ -48,7 +46,7 @@ [ ] (==) ModulePath set to /usr/X11R6/lib/modules [ ] (II) The server relies on wscons to provide the list of input devices. [ ]es become available, reconfigure wscons or disable AutoAddDevices. -[ ] (II) Loader magic: 0x1adf0cd0a040 +[ ] (II) Loader magic: 0xd9c9eb0b6e0 [ ] (II) Module ABI versions: [ ] X.Org ANSI C Emulation: 0.4 [ ] X.Org Video Driver: 18.0 @@ -58,7 +56,7 @@ [ ] (II) LoadModule: glx [ ] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so [ ] (II) Module glx: vendor=X.Org Foundation -[ ] compiled for 1.16.1, module version = 1.0.0 +[ ] compiled for 1.16.4, module version = 1.0.0 [ ] ABI class: X.Org Server Extension, version 8.0 [ ] (==) AIGLX enabled [ ] (==) Matched ati as autoconfigured driver 0 @@ -67,28 +65,21 @@ [ ] (II) LoadModule: ati [ ] (II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.so [ ] (II) Module ati: vendor=X.Org Foundation -[ ] compiled for 1.16.1, module version = 7.3.0 +[ ] compiled for 1.16.4, module version = 7.3.0 [ ] Module class: X.Org Video Driver [ ] ABI class: X.Org Video Driver, version 18.0 [ ] (II) LoadModule: radeon [ ] (II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.so [ ] (II) Module radeon: vendor=X.Org Foundation -[ ] compiled for 1.16.1, module version = 7.3.0 +[ ] compiled for 1.16.4, module version = 7.3.0 [ ] Module class: X.Org Video Driver [ ] ABI class: X.Org Video Driver, version 18.0 [ ] (II) LoadModule: vesa [ ] (II) Loading /usr/X11R6/lib/modules/drivers/vesa_drv.so [ ] (II) Module vesa: vendor=X.Org Foundation -[ ] compiled for 1.16.1, module version = 2.3.3 +[ ] compiled for 1.16.4, module version = 2.3.3 [ ] Module class: X.Org Video Driver [ ] ABI class: X.Org Video Driver, version 18.0 -[ ] (II) LoadModule: usbtablet -[
