NetBSD Problem Report #53744
From www@NetBSD.org Sun Nov 25 21:12:18 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 7467A7A1DF
for <gnats-bugs@gnats.NetBSD.org>; Sun, 25 Nov 2018 21:12:18 +0000 (UTC)
Message-Id: <20181125211217.616247A1F6@mollari.NetBSD.org>
Date: Sun, 25 Nov 2018 21:12:17 +0000 (UTC)
From: bbraun@synack.net
Reply-To: bbraun@synack.net
To: gnats-bugs@NetBSD.org
Subject: No usbhidctl on ums devices
X-Send-Pr-Version: www-1.0
>Number: 53744
>Category: kern
>Synopsis: No usbhidctl on ums devices
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Nov 25 21:15:01 +0000 2018
>Originator: Rob Braun
>Release: 8.99.26
>Organization:
>Environment:
pinebook
>Description:
USB mice (ums driver) do not have exposed uhid device files, except through wsmouse entries. That means there's no device entry to run usbhidctl against other than wsmouse#.
wsmouse passes ioctls through to the ums device, however ums_ioctl doesn't implement the necessary uhid ioctls, although it could (and could likely share uhid's ioctl implementation with some refactoring).
I'm specifically running this on a pinebook, attempting to run usbhidctl against the trackpad, but it seems generally applicable to the ums driver.
>How-To-Repeat:
Try to run usbhidctl against a usb mouse.
>Fix:
Implement uhid ioctls in ums, or ideally refactor uhid's ioctl to be shared with ums. Or expose a uhid device for usb nice?
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.