From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86D4AEB64D9 for ; Mon, 19 Jun 2023 06:09:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229802AbjFSGJa (ORCPT ); Mon, 19 Jun 2023 02:09:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229639AbjFSGJ3 (ORCPT ); Mon, 19 Jun 2023 02:09:29 -0400 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FBF4A9 for ; Sun, 18 Jun 2023 23:09:29 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-bb15165ba06so2250249276.2 for ; Sun, 18 Jun 2023 23:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687154968; x=1689746968; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=C20byiI+qbDetx7La03vWCfB4xYe9DPAdjsr8bNJWT4=; b=sec9jk6XQLTkr605jrqbNOBhEQuzIidGFoQsTVRE8IB2+riXv7VBmq4zF/lA4ldDs0 9yT5Sa39ruqgOaoXmomaEHn16iQWHzVzGGftEENtEbEVJ3VNwpLxRjyccNqbC7rtCr74 NaUl+v0ogNrJA/ZQs3V2AQnw4sTvysz4KeyFgE7L1kXtRqHQg4IMfSsTe+SYsvJsYe3x /DmB4XdIVPo/+j62xy9KEvAr6L/iNCLrPCjHhwm+rHgJkzLaI5NFFLEl2UZol3LAHVBu I9vn+6xOHuY6vP1dnPZinOWWrEAC2rSC7qPyegOiL014jgKWHXzvubdpY6uex1nJOupe m4ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687154968; x=1689746968; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=C20byiI+qbDetx7La03vWCfB4xYe9DPAdjsr8bNJWT4=; b=K2RNuyV4jLcjuTzg6ASJxHlK3a17uAbPkkvOBHktC03Xv82/D4OpnLe/Fs6IfTQd1V XhYnCEptYGm9GzYYkDL2Cb5v1Wen5lknBUI1B9ncu+BaNtI+SHUQvDYnWqp9gx7z7U+N Zabe2p3m1B+DJxidBZqLoP9OICSQhGfxZ4uFFGc7C819NPgPgqBpQm5tpBJUYPqw77YU PYad5DG/ZKMlySFu1SFWN80BjEpU01VjSMLq/O6AyN0lXXrjVuLKCL4f3xSwMcKQIIlv aErBNA0SIXVIsX76+eNDB3CjwwXZneHb4StIAe7L3/OMZK2o5lb+wGRG/Kfv1V+wQQCZ lNrA== X-Gm-Message-State: AC+VfDzcHJ+hO32j+XAV7/IdJ7DJeEjk2zUW05YyLjBaYCAyABHYURJO PFgVBBTXffwJgIY3Q3WbDUnbOoonJ2xULI09qVO1cCAuPoY= X-Google-Smtp-Source: ACHHUZ4tua5pJYspVunQJM73+DdyCJvcd881q0CqC6abTzhE7XIyjsyDw/ozkS1+SbPuWRV+A9ghX67Ta42QfOJeayw= X-Received: by 2002:a25:9391:0:b0:bd5:8625:89fc with SMTP id a17-20020a259391000000b00bd5862589fcmr116965ybm.26.1687154967750; Sun, 18 Jun 2023 23:09:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Xiaofan Chen Date: Mon, 19 Jun 2023 14:09:16 +0800 Message-ID: Subject: Clarification about the hidraw documentation on HIDIOCGFEATURE To: linux-input@vger.kernel.org Cc: Ihor Dutchak Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org I know that thurrent documentation has been there since it was created by Alan Ott many years ago. And he started the HIDAPI project around that time as well. However, I am starting to doubt whether it is correct or not based on the testing using HIDAPI. Please help to clarify. Thanks. https://docs.kernel.org/hid/hidraw.html +++++++++++++++++++++++++++++++++++++++++++++++++++++ HIDIOCGFEATURE(len): Get a Feature Report This ioctl will request a feature report from the device using the control endpoint. The first byte of the supplied buffer should be set to the report number of the requested report. For devices which do not use numbered reports, set the first byte to 0. The returned report buffer will contain the report number in the first byte, followed by the report data read from the device. For devices which do not use numbered reports, the report data will begin at the first byte of the returned buffer. ++++++++++++++++++++++++++++++++++++++++++++++++++++++ I have doubts about the last sentence. It seems to me that for devices which do not use numbered reports, the first byte will be 0 and the report data begins in the second byte. This is based on testing results using hidapi and hidapitester, which use the ioctl. int HID_API_EXPORT hid_get_feature_report(hid_device *dev, unsigned char *data, size_t length) { int res; register_device_error(dev, NULL); res = ioctl(dev->device_handle, HIDIOCGFEATURE(length), data); if (res < 0) register_device_error_format(dev, "ioctl (GFEATURE): %s", strerror(errno)); return res; } Reference discussion: https://github.com/libusb/hidapi/issues/589 Test device is Jan Axelson's generic HID example which I have tested using libusb and hidapi across platforms as well as using Windows HID API. So I believe the FW is good. http://janaxelson.com/hidpage.htm#MyExampleCode (USB PIC MCU) -- Xiaofan