-
-
Save jnettlet/afb20a048b8720f3b4eb8506d8b05643 to your computer and use it in GitHub Desktop.
| evdev:input:b*v0B05p193Ee0111* | |
| KEYBOARD_KEY_10081=reserved | |
| KEYBOARD_KEY_10082=reserved | |
| KEYBOARD_KEY_70070=reserved | |
| KEYBOARD_KEY_70071=reserved | |
| KEYBOARD_KEY_70072=reserved | |
| KEYBOARD_KEY_70073=reserved | |
| KEYBOARD_KEY_70074=reserved | |
| KEYBOARD_KEY_70075=reserved | |
| KEYBOARD_KEY_70076=reserved | |
| KEYBOARD_KEY_70077=reserved |
Works perfectly on ChimeraOS. Thanks!
You can use my package https://aur.archlinux.org/packages/falchion-shutdown
How did you find the bits in the first line ? I have a Strix Scope RX TKL Wireless Deluxe (what a name) and i'm still blocked to use it on Linux because of all the hassle I have.
From what I understand:
- v0B05 is the Vendor ID
- p193E is the Part ID
Both are found with lsusb, in my case:
lsusb |grep ASUS
Bus 001 Device 019: ID 0b05:1a07 ASUSTek Computer, Inc. ROG STRIX SCOPE RX TKL WIRELESS DELUXEBut the last part ? What should I replace for e0111 ? I'm puzzled because even kernel events does not tells me much about the device (look at that mess):
[jeu. juin 25 04:17:40 2026] usb 1-2: New USB device found, idVendor=0b05, idProduct=1a07, bcdDevice= 2.05
[jeu. juin 25 04:17:40 2026] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[jeu. juin 25 04:17:40 2026] usb 1-2: Product: ROG STRIX SCOPE RX TKL WIRELESS DELUXE
[jeu. juin 25 04:17:40 2026] usb 1-2: Manufacturer: ASUSTeK
[jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.0/0003:0B05:1A07.001A/input/input44
[jeu. juin 25 04:17:40 2026] hid-generic 0003:0B05:1A07.001A: input,hidraw1: USB HID v1.11 Keyboard [ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE] on usb-0000:c4:00.3-2/input0
[jeu. juin 25 04:17:40 2026] hid-generic 0003:0B05:1A07.001B: hiddev96,hidraw2: USB HID v1.11 Device [ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE] on usb-0000:c4:00.3-2/input1
[jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.2/0003:0B05:1A07.001C/input/input45
[jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE System Control as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.2/0003:0B05:1A07.001C/input/input46
[jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.2/0003:0B05:1A07.001C/input/input47
[jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE Mouse as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.2/0003:0B05:1A07.001C/input/input48
[jeu. juin 25 04:17:40 2026] hid-generic 0003:0B05:1A07.001C: input,hiddev97,hidraw3: USB HID v1.11 Mouse [ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE] on usb-0000:c4:00.3-2/input2
[jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.3/0003:0B05:1A07.001D/input/input49
[jeu. juin 25 04:17:40 2026] hid-generic 0003:0B05:1A07.001D: input,hidraw4: USB HID v1.11 Keyboard [ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE] on usb-0000:c4:00.3-2/input3
How did you find the bits in the first line ? I have a Strix Scope RX TKL Wireless Deluxe (what a name) and i'm still blocked to use it on Linux because of all the hassle I have.
From what I understand:
- v0B05 is the Vendor ID
- p193E is the Part ID
Both are found with lsusb, in my case:lsusb |grep ASUS Bus 001 Device 019: ID 0b05:1a07 ASUSTek Computer, Inc. ROG STRIX SCOPE RX TKL WIRELESS DELUXEBut the last part ? What should I replace for e0111 ? I'm puzzled because even kernel events does not tells me much about the device (look at that mess):
[jeu. juin 25 04:17:40 2026] usb 1-2: New USB device found, idVendor=0b05, idProduct=1a07, bcdDevice= 2.05 [jeu. juin 25 04:17:40 2026] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [jeu. juin 25 04:17:40 2026] usb 1-2: Product: ROG STRIX SCOPE RX TKL WIRELESS DELUXE [jeu. juin 25 04:17:40 2026] usb 1-2: Manufacturer: ASUSTeK [jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.0/0003:0B05:1A07.001A/input/input44 [jeu. juin 25 04:17:40 2026] hid-generic 0003:0B05:1A07.001A: input,hidraw1: USB HID v1.11 Keyboard [ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE] on usb-0000:c4:00.3-2/input0 [jeu. juin 25 04:17:40 2026] hid-generic 0003:0B05:1A07.001B: hiddev96,hidraw2: USB HID v1.11 Device [ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE] on usb-0000:c4:00.3-2/input1 [jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.2/0003:0B05:1A07.001C/input/input45 [jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE System Control as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.2/0003:0B05:1A07.001C/input/input46 [jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.2/0003:0B05:1A07.001C/input/input47 [jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE Mouse as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.2/0003:0B05:1A07.001C/input/input48 [jeu. juin 25 04:17:40 2026] hid-generic 0003:0B05:1A07.001C: input,hiddev97,hidraw3: USB HID v1.11 Mouse [ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE] on usb-0000:c4:00.3-2/input2 [jeu. juin 25 04:17:40 2026] input: ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2:1.3/0003:0B05:1A07.001D/input/input49 [jeu. juin 25 04:17:40 2026] hid-generic 0003:0B05:1A07.001D: input,hidraw4: USB HID v1.11 Keyboard [ASUSTeK ROG STRIX SCOPE RX TKL WIRELESS DELUXE] on usb-0000:c4:00.3-2/input3
This info is from the modalias line that you get out of sysfs.
find /sys -name *modalias | xargs grep -i v0B05p1a07
should work for you. it will most likely be e0111-e0 and you just take everything before the -e0 to match all versions.
Indeed, I found way too many lines in this, but the "e0111" is there:
$ find /sys -name *modalias | xargs grep -i v0B05p1a07
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.1/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc00ip00in01
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input40/modalias:input:b0003v0B05p1A07e0111-e0,3,kra28,mlsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input39/modalias:input:b0003v0B05p1A07e0111-e0,1,4,k74,8E,8F,ram4,lsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input41/modalias:input:b0003v0B05p1A07e0111-e0,1,2,4,k110,111,112,r0,1,8,B,am4,lsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input38/modalias:input:b0003v0B05p1A07e0111-e0,1,4,k71,72,73,80,8C,90,9B,9C,9E,9F,A3,A4,A5,A6,AB,AC,AD,D9,ram4,lsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc00ip00in02
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.0/0003:0B05:1A07.0011/input/input37/modalias:input:b0003v0B05p1A07e0111-e0,1,4,11,14,k71,72,73,74,75,77,79,7A,7B,7C,7D,7E,7F,80,81,83,85,87,88,89,B7,B8,B9,BA,BB,BC,BD,BE,F0,ram4,l0,1,2,3,4,sfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.0/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc01ip01in00
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.3/0003:0B05:1A07.0014/input/input42/modalias:input:b0003v0B05p1A07e0111-e0,1,4,14,k74,75,77,7F,80,B7,B8,B9,BA,BB,BC,BD,BE,ram4,lsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.3/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc00ip01in03Still don't know exactly what "e" stands for in this string, but glad to know how to find it for other people, thank you very much. FYI I just applied the same events "reservation" and also had to reboot for this to be taken into account ;)
Indeed, I found way too many lines in this, but the "e0111" is there:
$ find /sys -name *modalias | xargs grep -i v0B05p1a07 /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.1/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc00ip00in01 /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input40/modalias:input:b0003v0B05p1A07e0111-e0,3,kra28,mlsfw /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input39/modalias:input:b0003v0B05p1A07e0111-e0,1,4,k74,8E,8F,ram4,lsfw /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input41/modalias:input:b0003v0B05p1A07e0111-e0,1,2,4,k110,111,112,r0,1,8,B,am4,lsfw /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input38/modalias:input:b0003v0B05p1A07e0111-e0,1,4,k71,72,73,80,8C,90,9B,9C,9E,9F,A3,A4,A5,A6,AB,AC,AD,D9,ram4,lsfw /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc00ip00in02 /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.0/0003:0B05:1A07.0011/input/input37/modalias:input:b0003v0B05p1A07e0111-e0,1,4,11,14,k71,72,73,74,75,77,79,7A,7B,7C,7D,7E,7F,80,81,83,85,87,88,89,B7,B8,B9,BA,BB,BC,BD,BE,F0,ram4,l0,1,2,3,4,sfw /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.0/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc01ip01in00 /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.3/0003:0B05:1A07.0014/input/input42/modalias:input:b0003v0B05p1A07e0111-e0,1,4,14,k74,75,77,7F,80,B7,B8,B9,BA,BB,BC,BD,BE,ram4,lsfw /sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.3/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc00ip01in03Still don't know exactly what "e" stands for in this string, but glad to know how to find it for other people, thank you very much. FYI I just applied the same events "reservation" and also had to reboot for this to be taken into account ;)
Indeed, I found way too many lines in this, but the "e0111" is there:
$ find /sys -name *modalias | xargs grep -i v0B05p1a07
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.1/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc00ip00in01
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input40/modalias:input:b0003v0B05p1A07e0111-e0,3,kra28,mlsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input39/modalias:input:b0003v0B05p1A07e0111-e0,1,4,k74,8E,8F,ram4,lsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input41/modalias:input:b0003v0B05p1A07e0111-e0,1,2,4,k110,111,112,r0,1,8,B,am4,lsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/0003:0B05:1A07.0013/input/input38/modalias:input:b0003v0B05p1A07e0111-e0,1,4,k71,72,73,80,8C,90,9B,9C,9E,9F,A3,A4,A5,A6,AB,AC,AD,D9,ram4,lsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.2/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc00ip00in02
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.0/0003:0B05:1A07.0011/input/input37/modalias:input:b0003v0B05p1A07e0111-e0,1,4,11,14,k71,72,73,74,75,77,79,7A,7B,7C,7D,7E,7F,80,81,83,85,87,88,89,B7,B8,B9,BA,BB,BC,BD,BE,F0,ram4,l0,1,2,3,4,sfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.0/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc01ip01in00
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.3/0003:0B05:1A07.0014/input/input42/modalias:input:b0003v0B05p1A07e0111-e0,1,4,14,k74,75,77,7F,80,B7,B8,B9,BA,BB,BC,BD,BE,ram4,lsfw
/sys/devices/pci0000:00/0000:00:08.3/0000:c6:00.4/usb7/7-1/7-1.4/7-1.4:1.3/modalias:usb:v0B05p1A07d0205dc00dsc00dp00ic03isc00ip01in03(bus type b0003 is Bluetooth) manufactured by vendor 0B05 (ASUS) with product ID 1A07, specifically matching the e0111 event capability extension
I think I found the answer in USB HID Usage Tables 1.5: https://usb.org/sites/default/files/hut1_5.pdf I think 10081 and 10082 correspond to 81 and 82 (System Power Down and System Sleep) in Generic Desktop Page (0x01).
The ones beginning with 7 correspond to values in Keyboard/Keypad Page (0x07), right?Yes that is correct, however I have no idea why they are being sent simultaneous to the expected key codes. It could be a firmware bug, or maybe they trap the keycodes in their software and decided what keycode to pass to the host os depending on software settings. My main objective was just to get the keyboard functional under Linux.
I did some root cause analysis on this for a different class of ROG keyboard, and the root cause appears to be a firmware-level bug in the device's report descriptors being sent.
For the CLAYMORE II, per this issue, the HID descriptor sent by the device appears to be:
bLength : 0x09 (9 bytes)
bDescriptorType : 0x21 (HID Descriptor)
bcdHID : 0x0111 (HID Version 1.11)
bCountryCode : 0x00 (00 = not localized)
bNumDescriptors : 0x01
Descriptor 1:
bDescriptorType : 0x22 (Class=Report)
wDescriptorLength : 0x00B9 (185 bytes)
05 0C Usage Page (Consumer)
09 01 Usage (Consumer Control)
A1 01 Collection (Application)
85 01 Report ID (0x01)
05 0C Usage Page (Consumer)
75 01 Report Size (1)
95 12 Report Count (18)
15 00 Logical Minimum (0)
25 01 Logical Maximum (1)
0A 83 01 Usage (AL Consumer Control Configuration)
0A 8A 01 Usage (AL Email Reader)
0A 92 01 Usage (AL Calculator)
0A 94 01 Usage (AL Local Machine Browser)
09 CD Usage (Play/Pause)
09 B7 Usage (Stop)
09 B6 Usage (Scan Previous Track)
09 B5 Usage (Scan Next Track)
09 E2 Usage (Mute)
09 EA Usage (Volume Decrement)
09 E9 Usage (Volume Increment)
0A 21 02 Usage (AC Search)
0A 23 02 Usage (AC Home)
0A 24 02 Usage (AC Back)
0A 25 02 Usage (AC Forward)
0A 26 02 Usage (AC Stop)
0A 27 02 Usage (AC Refresh)
0A 2A 02 Usage (AC Bookmarks)
81 02 Input (Var)
75 06 Report Size (6)
95 01 Report Count (1)
81 01 Input (Const)
C0 End Collection
05 01 Usage Page (Generic Desktop Controls)
09 80 Usage (System Control)
A1 01 Collection (Application)
85 02 Report ID (0x02)
75 01 Report Size (1)
95 03 Report Count (3)
15 01 Logical Minimum (1)
25 03 Logical Maximum (3)
09 81 Usage (System Power Down)
09 82 Usage (System Sleep)
09 83 Usage (System Wake Up)
81 02 Input (Var)
75 05 Report Size (5)
95 01 Report Count (1)
81 01 Input (Const)
C0 End Collection
06 C0 FF Usage Page (Vendor Defined)
09 01 Usage (unknown)
A1 01 Collection (Application)
85 03 Report ID (0x03)
19 00 Usage Minimum (0)
2A FF 00 Usage Maximum (255)
15 00 Logical Minimum (0)
26 FF 00 Logical Maximum (255)
75 08 Report Size (8)
95 14 Report Count (20)
81 00 Input ()
C0 End Collection
05 01 Usage Page (Generic Desktop Controls)
09 02 Usage (Mouse)
A1 01 Collection (Application)
09 01 Usage (Pointer)
A1 00 Collection (Physical)
85 04 Report ID (0x04)
05 09 Usage Page (Buttons)
19 01 Usage Minimum (1)
29 03 Usage Maximum (3)
15 00 Logical Minimum (0)
25 01 Logical Maximum (1)
95 03 Report Count (3)
75 01 Report Size (1)
81 02 Input (Var)
95 01 Report Count (1)
75 05 Report Size (5)
81 01 Input (Const)
05 01 Usage Page (Generic Desktop Controls)
09 30 Usage (Direction-X)
09 31 Usage (Direction-Y)
09 38 Usage (Wheel)
15 81 Logical Minimum (-127)
25 7F Logical Maximum (+127)
75 08 Report Size (8)
95 03 Report Count (3)
81 06 Input (Var, Rel)
C0 End Collection
C0 End Collection
This defines the types of packets sent by the device. Notably, Report ID 2, which is defined for sending system control events, looks like this:
05 01 Usage Page (Generic Desktop Controls)
09 80 Usage (System Control)
A1 01 Collection (Application)
85 02 Report ID (0x02)
75 01 Report Size (1)
95 03 Report Count (3)
15 01 Logical Minimum (1)
25 03 Logical Maximum (3)
09 81 Usage (System Power Down)
09 82 Usage (System Sleep)
09 83 Usage (System Wake Up)
81 02 Input (Var)
75 05 Report Size (5)
95 01 Report Count (1)
81 01 Input (Const)
C0 End Collection
Roughly, this defines the report using four fields totaling 8 bytes with the following structure:
00000 0 0 0
CONST W S P
where CONST is a constant input (serving as padding to get the report to 8 bytes), W is a bit for controlling wake-up, S is a bit for controlling sleep, and P is a bit for controlling power. Unfortunately there is a bug in the descriptor, because these values:
15 01 Logical Minimum (1)
25 03 Logical Maximum (3)
imply that each of the three fields are only allowed to have numerical values between 1 and 3, which is obviously a bug as a bit can only have values between 0 and 1. So when something like 0x02 0x00 is being sent by the device on sleep/wake, which is intended to report that the user is not pressing either of the keys (thereby canceling any previous press before the device was put to sleep), Linux treats 0 as an invalid value according to the device's own descriptor and clamps the value to 1, meaning the values of all fields W/S/P will be set to 1. Because of this, 0x02 0x00 (or in fact any report that begins with 0x02) ends up meaning "device wants to sleep, wake, and power off" (as also reported by this guy on Unix Stack Exchange).
In the case of other ASUS keyboards, depending on what their exact HID descriptor looks like, the report ID or the exact message being sent might be different, but the mechanism of action is probably the same in all cases.
There are hard-coded fixes for this behavior in the Linux kernel for some ASUS keyboards, but not others, although I don't think they cover all cases in which this bug can cause your device to suspend or turn off unintentionally.
As for why this is not a problem on Windows, I have no idea. I assume its handling of this particular out-of-bounds condition is different from Linux, which is why the device does not do the same thing under Windows. But it seems, looking at the clamping code and its history of changes, that it was a compromise reached in Linux due to the HID spec being ambiguous as to what to do with values outside of the allowed range, so it is possible that Microsoft just drops these values before they can be interpreted by the OS instead of clamping them.
Yes that is correct, however I have no idea why they are being sent simultaneous to the expected key codes. It could be a firmware bug, or maybe they trap the keycodes in their software and decided what keycode to pass to the host os depending on software settings. My main objective was just to get the keyboard functional under Linux.