-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Gaomon M106K Support #609
Comments
The "best" solution here is to drop the S620 file and update to the M106K instead. This will make any S620 show up as M106K but it's better to expose buttons that don't exist than to limit the number of buttons. We've done this in the past with some other devices though don't ask me which one :) Mind you, that only pushes the problem out by a bit, sooner or later those vendors will have the great idea of shipping backwards incompatible changes with the same ID. They do work under windows I'd expect which means there's something on the device level that tells the host which specific model is connected, we need to get this exported into userspace. Let's see what #610 amounts to over the next few days. |
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names. This patch exposes the firmware version name via sysfs attribute. [1] linuxwacom/libwacom#609 Link: linuxwacom/libwacom#610 Signed-off-by: José Expósito <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name via sysfs attribute. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name via sysfs attribute. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name via sysfs attribute. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name via sysfs attribute. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name in the hid->uniq field. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name in the hid->uniq field. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name in the hid->uniq field. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name in the hid->uniq field. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name in the hid->uniq field. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]>
Some vendors reuse the same product ID for different tablets, making it difficult for userspace to figure out which table is connected. While matching the device name has been used in the past by userspace to workaround this limitation, some devices have shown that this is not always a valid approach [1]. However, if userspace could access the firmware version name, it would be possible to know which tablet is actually connected by matching it against a list of known firmware names [2]. This patch exposes the firmware version name in the hid->uniq field. Link: linuxwacom/libwacom#609 [1] Link: linuxwacom/libwacom#610 [2] Signed-off-by: José Expósito <[email protected]>
This tablet has the same name as Gaomon M106K [1], making it impossible to differentiate between them without matching by their firmware name. Add an extra match including the firmware to facilitate matching the Gaomon M106K. [1] linuxwacom#609
@TacticalCode I created a PR matching by firmware name the Gaomon S620, the tablet that clashed with your M106K: Now that we can match by firmware name, you should be able to add a .tablet file for your tablet. Your tablet's firmware should be EDIT: Useful links: |
This tablet has the same name as Gaomon M106K [1], making it impossible to differentiate between them without matching by their firmware name. Add an extra match including the firmware to facilitate matching the Gaomon M106K. [1] #609
The link hash doesn't work nicely when I resolve the relevant conversation in PR #654, so I'm going to post José's comment here for posterity.
And checking if your device is detected (after updating libwacom's database as described in the readme) by running Have in mind that you'd need to compile and install the latest libwacom code. I don't know if it is documented, but, to run the latest
That last command should (hopefully) detect your tablet correctly. If you want GNOME/KDE settings to recognize your tablet, you'd need to override your distro libwacom with the latest master, which I won't recommend unless you are testing in a VM or in a test PC that you plan to format. Originally posted by @jexposit in #654 (comment) |
We now have the M106K and M106K Pro both in the tablet files thaks to #659. It may not work yet (you'll need kernel 6.10 or Jose's kernel patches locally) but from the libwacom side I think we're good now, so let's close this. (If I'm wrong please re-open). Any fixes to the tablet file please feel free to submit as MR. |
Hello,
I'm using a Gaomon M106K pad, which is recognized as
Gaomon S620
due to identical hardware IDs.The M106K is a "clone" of the Huion New 1060 Plus (see https://digimend.github.io/tablets/). The Gaomon M106K is already in wacom-hid-descriptors: https://github.com/linuxwacom/wacom-hid-descriptors/tree/master/Gaomon%20M106K
I've copied over the S620 data + Huion layout files to /etc/libwacom and modified the DeviceMatch and Buttons, now my pad is recognized correctly and I can configure all buttons in gnome settings.
My question is: Can we add support for the M106K without regression for the S620 support?
dmesg
when I plug in the pad via USB:lsusb -tv
My custom gaomon-m106k.tablet definition (layout SVG is just a copy of
huion-new-1060-plus.svg
):Original DeviceMatch from the S620 model:
libwacom-list-local-devices
with my custom M106K.tablet:When I include the "Dial" and "Touch Strip" devices in the
DeviceMatch
rule,libwacom-list-local-devices
lists those too, but gnome settings displays 3x Pads + 1x Pen.I suppose my M106K config would cause all S620 devices the be recognized as M106K because of the identical hardware IDs... Is there any way in libwacom to differentiate between the S620 and M106K models?
If that's not possible, can we ship the M106K definition anyway, so users can at least copy over the existing file to /etc to override the S620 definition?
The text was updated successfully, but these errors were encountered: