On Sun, Feb 14, 2021 at 01:53:19PM +0000, [email protected] wrote:

> February 14, 2021 8:35 AM, "Marcus Glocker" <[email protected]> wrote:
> 
> > On Sun, Feb 14, 2021 at 01:25:34PM +0000, [email protected] wrote:
> > 
> >> February 14, 2021 2:30 AM, "Marcus Glocker" <[email protected]> wrote:
> >> 
> >> On Sun, Feb 14, 2021 at 01:16:12AM +0000, [email protected] wrote:
> >> 
> >> February 13, 2021 5:05 PM, "Marcus Glocker" <[email protected]> wrote:
> >> 
> >> On Sat, Feb 13, 2021 at 09:35:31PM +0000, [email protected] wrote:
> >> 
> >> February 13, 2021 12:34 PM, "Marcus Glocker" <[email protected]> wrote:
> >> 
> >> On Sat, Feb 13, 2021 at 04:50:46PM +0000, [email protected] wrote:
> >> 
> >> February 13, 2021 10:44 AM, "Anton Lindqvist" <[email protected]> wrote:
> >> 
> >> Hi,
> >> 
> >> On Sat, Feb 13, 2021 at 01:58:28PM +0000, [email protected] wrote:
> >> 
> >> On amd64, upgrading from 6.8 stable to snapshot my Logitech G413 \
> >> keyboard is not sending keypresses. i.e) Pressing the "a" key \
> >> does nothing. There???s an error message saying \
> >> ???uhidev_intr: bad repid 48??? To test that it's not a \
> >> problem with my keyboard I noticed that the function keys still work. \
> >> (The keyboard light). Also to test it's not just my computer I \
> >> plugged in a different keyboard and everything works as it should. \
> >> Below is my dmesg from snapshot:
> >> 
> >> That's probably caused by the new uhidpp driver. A dmesg from a kernel
> >> before the upgrade where the keyboard did work would be helpful.
> >> 
> >> Hello, here's a dmesg from 6.8 where the keyboard works:
> >> 
> >> Can you please try to run the -current kernel with uhidpp(4) disabled?
> >> 
> >> I wasn't able to get keyboard input at the UKC prompt so I \
> >> instead ran config(8) and disabled uhidpp there. I hope \
> >> that doesn't impact any debugging. \
> >> 
> >> That's fine, too.
> >> 
> >> I disabled uhidpp but the problem still persists. There's still \
> >> the error "uhidev_intr: bad repid 48". Below is a dmesg of uhidpp \
> >> disabled:
> >> 
> >> OK, looks like related to the changes in uhidev(4) made for uhidpp(4).
> >> Can you please try this diff for a test?
> >> 
> >> Since this is the first time I'm doing something like this. I will \
> >> list out the steps I did to make sure I'm doing this correctly. \
> >> 
> >> # ftp -o - 'https://marc.info/?l=openbsd-bugs&m=161325400206085&q=raw' \
> >> | (cd /usr/src/sys/dev/usb/; patch)
> >> # cd /sys/arch/$(machine)/compile/GENERIC.MP
> >> # make obj
> >> # make config
> >> # make && make install
> >> # reboot
> >> 
> >> I noticed the error message is gone now. However the problem remains. \
> >> Below is the dmesg of the new kernel:
> >> 
> >> Thanks. Sorry, I forgot to mention. Can you please test this diff
> >> also with uhidpp(4) disabled?
> >> 
> >> Hi, with uhidpp disabled along side applying the new diff, \
> >> the problem still remains. I noticed that without disabling \
> >> uhidpp, while the problem is still there, the error message \
> >> "uhidev_intr: bad repid 48" is gone. So perhaps that's \
> >> a different issue? (Not a coder at all, just speculation.) \
> > 
> > For me that looks like the issue isn't directly related to uhidpp(4).
> > And yes, I also think the "uhidev_intr: bad repid 48" message is related
> > to the uhidpp(4) change, but not causing this issue.
> > 
> > Since we had quite some changes in this area recently it's a bit
> > difficult now to identify the culprit.
> > 
> > Can you please try to revert the USB data toggle fix for uhidev(4)?
> > Only this diff is enough. You can revert everything else to back to
> > -current and also leave uhidpp(4) enabled.
> 
> Applying this diff does make the keyboard work again and the error \
> message is gone. Below is a dmesg:

Thanks.  I'll ask for an OK to back-out this change since I'm seeing
too much issues being reported.

Reply via email to