From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15548 invoked from network); 10 Feb 2023 00:18:04 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 10 Feb 2023 00:18:04 -0000 Received: from mx.sdf.org ([205.166.94.24]) by 9front; Thu Feb 9 19:16:30 -0500 2023 Received: from sdf.org (IDENT:adr@sdf.org [205.166.94.16]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 31A0GRhi014042 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO) for <9front@9front.org>; Fri, 10 Feb 2023 00:16:28 GMT Received: from localhost (adr@localhost) by sdf.org (8.15.2/8.12.8/Submit) with ESMTP id 31A0GR7e005334 for <9front@9front.org>; Fri, 10 Feb 2023 00:16:27 GMT Date: Fri, 10 Feb 2023 00:16:27 +0000 (UTC) From: adr To: 9front@9front.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: structured leveraged SVG over HTML realtime-java reduce/map controller Subject: [9front] Huion, gaomon, &c tablets Reply-To: 9front@9front.org Precedence: bulk Hi, these tablets (huion, gaomon, &c) are all the same under the hood, the chipset is known as uclogic. They don't conform hid, a report descriptor has to be provided by the driver, as you did, but then the parameters logical and physical maximum for x and y, and logical maximum pressure have to be extracted from a string descriptor. The morons changed the string index where the settings are stored, first was 100, then 200. Some tablets has to be initialized by sending some data, others are set to non-mobile mode just getting this string. Take a look at the linux driver, it's pretty straightforward: https://raw.githubusercontent.com/DIGImend/digimend-kernel-drivers/master/hid-uclogic-params.c The idea is to try first the old way, check if it's ok, if not try the new way and take into account particularities of some models. In the other hand, I know my device's model string is in 0xc9, so what the heck... /sys/src/cmd/nusb/kb/kb.c: ========================== [...] #define UCLOGIC_XLM 49 #define UCLOGIC_XPM 54 #define UCLOGIC_YLM 63 #define UCLOGIC_YPM 68 #define UCLOGIC_PLM 80 static void gaomons620(Hiddev *f) { [...] // static int idx[] = { 0x64, 0x65, 0x6e, 0x79, 0x7a, 0x7b, 0xc8, 0xc9 }; Dev *d = f->dev; // int i; // /* we have to fetch a bunch of strings to switch to non-phone mode */ // for(i=0; i < nelem(idx); i++) // free(loaddevstr(d, idx[i])); model = loaddevstr(d, 0xc9); if(strcmp("HUION_T176_190314", model) == 0){ /* fully-functional tablet mode */ free(loaddevstr(d, 0xc8)); descr[UCLOGIC_XLM] = 0x40; descr[UCLOGIC_XLM+1] = 0x5f; descr[UCLOGIC_XLM+2] = 0x00; descr[UCLOGIC_XLM+3] = 0x00; descr[UCLOGIC_XPM] = 0xc0; descr[UCLOGIC_XPM+1] = 0x12; descr[UCLOGIC_XPM+2] = 0x00; descr[UCLOGIC_XPM+3] = 0x00; descr[UCLOGIC_YLM] = 0x88; descr[UCLOGIC_YLM+1] = 0x3b; descr[UCLOGIC_YLM+2] = 0x00; descr[UCLOGIC_YLM+3] = 0x00; descr[UCLOGIC_YPM] = 0xb8; descr[UCLOGIC_YPM+1] = 0x0b; descr[UCLOGIC_YPM+2] = 0x00; descr[UCLOGIC_YPM+3] = 0x00; descr[UCLOGIC_PLM] = 0xff; descr[UCLOGIC_PLM+1] = 0x1f; descr[UCLOGIC_PLM+2] = 0x00; descr[UCLOGIC_PLM+3] = 0x00; } free(model); [...] So my tablet is now in "fully-functional tablet mode" (that's what they called it in the linux driver) and using all its surface (this model is a bit bigger than the gaomons620). You have two paths, include some code as in the linux driver, or make a table with model string, x logical maximum, &c and possibly model string index (I don't know if it is the same in all devices) and some little functions to insert these values in little endian in f->rep. The pros and cons are obvious. Regards, adr