On Wed, 28 May 2025 17:10:26 -0500
izzy Meyer <izder...@disroot.org> wrote:
> On Wed, 28 May 2025 19:58:36 +0000
> Miod Vallat <m...@online.fr> wrote:
>
> > The following diff *might* solve the issue, but might also break
> > other systems.
> >
> > Index: pckbc_acpi.c
> > ===================================================================
> > RCS file: /OpenBSD/src/sys/dev/acpi/pckbc_acpi.c,v
> > diff -u -p -r1.2 pckbc_acpi.c
> > --- pckbc_acpi.c 13 Feb 2025 19:54:44 -0000 1.2
> > +++ pckbc_acpi.c 28 May 2025 19:57:33 -0000
> > @@ -80,6 +80,7 @@ struct pckbc_acpi_softc {
> > /* gpio interrupts */
> > struct pckbc_acpi_gpio_intr sc_gpioint[2];
> > unsigned int sc_nints, sc_ngpioints;
> > + uint32_t sc_intflags; /* copy of interrupt flags for
> > sc_ih[0] */ };
> >
> > const struct cfattach pckbc_acpi_ca = {
> > @@ -293,6 +294,8 @@ pckbc_acpi_attach_kbd(struct device *par
> > self->dv_xname,
> > aaa->aaa_irq[irq]); goto fail_intr;
> > }
> > + if (pasc->sc_nints == 0)
> > + pasc->sc_intflags =
> > aaa->aaa_irq_flags[irq]; pasc->sc_nints++;
> > }
> > }
> > @@ -384,6 +387,20 @@ pckbc_acpi_attach_mouse(struct device *p
> > }
> > } else {
> > base = pasc->sc_nints;
> > + /*
> > + * There seem to be systems, such as Panasonic
> > Let's Note CF-NX4
> > + * where the keyboard node has correct interrupt
> > flags
> > + * (edge-triggered, active high) while the mouse
> > node has
> > + * IrqNoFlags and thus would be considered as
> > level-triggered.
> > + *
> > + * We unconditionally override IrqNoFlags here with
> > the same
> > + * flags as the keyboard node, and hope for the
> > best.
> > + */
> > + if (pasc->sc_nints == 1 &&
> > + (aaa->aaa_irq_flags[0] &
> > + (LR_EXTIRQ_MODE | LR_EXTIRQ_POLARITY)) == 0) {
> > + aaa->aaa_irq_flags[0] = pasc->sc_intflags;
> > + }
> > for (irq = 0; irq < aaa->aaa_nirq; irq++) {
> > if (pasc->sc_nints == nitems(pasc->sc_ih))
> > break;
>
> I'll have to test this, but i thought this to be of note in diagnosis
>
> i rebooted since sending that email and automagically the touchpad
> *did* in fact attach in ps/2 mode. still, thats incorrect, it
> *should* attach as a synaptics pointing device. but progress.
>
> the only thing that changed from that first boot into #674 and the
> subsequent reboot(s) was that i had a usb mouse plugged in. the
> touchpad attaching as pms0 persisted across reboots since, with or
> without the mouse attached, so idk how relevant it is. it was an apple
> mighty mouse, if that's notable. I'll attach this boot's dmesg as well
> as the other stuff sendbug scrapes as a file as well for inspection
> aptly named "notableboot.info"
>
> Thanks for all the help. Its been a headache for sure.
>
> Best-
>
I tested this diff, and nothing seemed to change from the above shown
behavior.
I was able to get it to attach as a synaptics device with the attached
diff though. I took it from chris's tips (CC'd) on that linked thread in
the initial email here. I dunno if this is notable, but chris mentioned
an xfer error that would occasionally show up. I've been running this
diff with the #675 userland (i sysupgrade'd last night) for all of
today so far and the error has yet to pop up. Is there a possibility of
supporting active multiplexing in the future so i don't need to patch
this #define?
Thanks!
--
iz (she/her)
> i like to say mundane things,
> there are too many uninteresting things
> that go unnoticed.
izder456 (dot) neocities (dot) org
diff --git i8042reg.h i8042reg.h
index 01ccc71c6..c0dfa1cd4 100644
--- i8042reg.h
+++ i8042reg.h
@@ -20,7 +20,7 @@
#define KBC_CMDWOUT 0xd1 /* write output port */
#define KBC_KBDECHO 0xd2 /* echo to keyboard port */
#define KBC_AUXECHO 0xd3 /* echo to auxiliary port */
-#define KBC_AUXWRITE 0xd4 /* write to auxiliary port */
+#define KBC_AUXWRITE 0x91 /* write to auxiliary port */
#define KBC_SELFTEST 0xaa /* start self-test */
#define KBC_KBDTEST 0xab /* test keyboard port */
#define KBC_KBDDISABLE 0xad /* disable keyboard port */
