--- a/sys/dev/pckbc/pms.c
+++ b/sys/dev/pckbc/pms.c
@@ -1946,7 +1946,10 @@ elantech_get_hwinfo_v4(struct pms_softc *sc)
if (synaptics_query(sc, ELANTECH_QUE_FW_VER, &fw_version))
return (-1);
- if ((fw_version & 0x0f0000) >> 16 < 6)
+ if ((fw_version & 0x0f0000) >> 16 != 6
+ && (fw_version & 0x0f0000) >> 16 != 8
+ && (fw_version & 0x0f0000) >> 16 != 15
+ && (fw_version & 0x0f0000) >> 16 < 6)
return (-1);
elantech->fw_version = fw_version;
First, thanks for all good advices.
Ok I finally had time to sit down and figure it out, and my first guess
was wrong, it was a change in pms.c which made the touchpad stop
working. The patch that made it stop work was revision 1.89 committed
Mon Aug 19 21:08 UTC. Most of the patch is probably correct, I've not
worked with hardware drivers on this level before so someone that knows
what they are doing should probably look into this - but I also made a
patch to fix it, however I might have broken the support of other
touchpads or so with my suggested change. What I did was bringing back
the three lines deleted from elantech_get_hwinfo_v4 and re-added them to
the new if statement. I'm attaching a diff for this change.
On 30/08/2019, 17:16, Stuart Henderson wrote:
>Mikal, as your problem started before the problematic snapshot, while
>it may seem a similar issue, it definitely needs investigating differently.
>
>On 2019/08/30 17:26, Mikal Villa wrote:
>> I tried that, booted with #248 but I'm sorry to say the issues are still
>> here. I wrote wrong in the last mail, wsmouse0 is the touchscreen which
>> as last time, is no responsive. wsmouse1, the trackpad is "sometimes"
>> acting on input but not nessesarry where you meant it to go, however
>> right clicking seem to work, and has in all tries of mine worked.
>>
>> Is there a place I can read about whats already known about this issue?
>> I know you don't do bugtrackers, but maybe if I knew more I could make a
>> brave attempt to help fixing it myself. Unfamiliar with the openbsd
>> kernel, but has a little experience from xnu and linux. Dmesg has all
>> it's output from pms0, but I've read the pms driver code and I suspect
>> it's not the trouble maker but something else where it's just a
>> biproduct of it.
>
>The best easy-ish thing you could do would be to try to identify a time
>range (or even better the actual commit) when the problem started occurring.
>
>The pms entries in dmesg seem to point at something kernel-side rather
>than X so I would start by just trying different kernels. You could e.g.
>fetch the src tree if you don't already have it, then do a date-based
>update in /sys ("cvs up -Pd -D 2019/08/01"). Start with a date before
>you think the problem started, to confirm that it was indeed working at
>that point and to confirm that the process of just building kernels is
>good enough for these tests. (If you go back too far you may run into
>syscall or kernel structure incompatibilities, but I can't think of any
>that will cause major problems in the suggested time window).
>Build/install a kernel and test, if it works then do another cvs up
>moving forward through time (forwards a week or so?) until it stops
>working, then backwards again with smaller increments to narrow it down.
>
--
Best regards,
Mikal Villa
No comments:
Post a Comment