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.
