GIGABYTE AERO 15-YA different device ID

[derde]

This code seems to work on this device too:

+++ b/src/kbd.rs
@@ -87,7 +87,7 @@ pub struct FusionKBD<'a> {
 impl<'a> FusionKBD<'a> {
     #[allow(clippy::new_ret_no_self)]
     pub fn new(context: &'a libusb::Context) -> Result<Self, libusb::Error> {
-        let mut handle = match context.open_device_with_vid_pid(0x1044, 0x7a39) {
+        let mut handle = match context.open_device_with_vid_pid(0x1044, 0x7a3f) {
             Some(handle) => handle,
             None => {
                 eprintln!("Failed to open device! Are you running as root?");

[daniel5151]

I'm not surprised - I doubt Gigabyte changed the firmware much between different revisions.

This seems like an easy feature to support. A cleaner approach might be to tweak the code to look for both devices, and open the first one that's available.

i.e: something like

let dev = context.open_device_with_vid_pid(0x1044, 0x7a3f)
      .or(context.open_device_with_vid_pid(0x1044, 0x7a39));
let mut handle = match dev {

I don't have the project + deps set up on current dev machine, but I might have time to push an update at some point this week.

Alternatively, if you've got the project set up and building, see if my fix works, and feel free to open up a PR. It would be much appreciated :wink:

[derde]

It works nicely ... here's the patch ... I might see if I can make it a PR ...

--- a/src/kbd.rs
+++ b/src/kbd.rs
@@ -87,7 +87,9 @@ pub struct FusionKBD<'a> {
 impl<'a> FusionKBD<'a> {
     #[allow(clippy::new_ret_no_self)]
     pub fn new(context: &'a libusb::Context) -> Result<Self, libusb::Error> {
-        let mut handle = match context.open_device_with_vid_pid(0x1044, 0x7a39) {
+        let dev = context.open_device_with_vid_pid(0x1044, 0x7a39)
+              .or(context.open_device_with_vid_pid(0x1044, 0x7a3f));
+        let mut handle = match dev {
             Some(handle) => handle,
             None => {
                 eprintln!("Failed to open device! Are you running as root?");

On this keyboard, there's a 25 second lock of some sort, during which the keyboard is unresponsive after the program has run - but I haven't looked into it in detail.

[daniel5151]

Ah, nice! Cool to see that it seems to be working :)

That 25 second lock is definitely a bit spooky. Unfortunately, given that I haven't worked on this codebase in >2 years, and don't have your specific Aero 15x model, I don't think I can be much help :'(

I saw that you already have a fork of my repo - in that case, it's really easy to make a PR! Check out the Github docs on how to open a PR.