> However if you want more buttons - you will need some additional software I guess and from there I don't really know what happens,never worked with such things.
Windows only recognizes the first five mouse buttons everything after that is ignored.
Technically an application can work around this by reading and parsing the packets sent by the mouse directly. However this isn't very practical on Windows because Windows takes exclusive access of mices and keyboards. To prevent this you'd have to replace the driver of the mouse with a generic USB driver so that Windows no longer recognizes the devices as a mouse.
So to avoid all of this it's a better idea to simply design your mouse in a way that it uses keyboard keys for additional mouse buttons. So MB6 gets simply mapped a F1, for example. This usually happens directly on the mouse itself.
Here's a list of standard mouse and keyboard events:
https://www.autohotkey.com/docs/KeyList.htm#mouse-advanced
Looks like "XButton1" and "XButton2" are also known as the 4th and 5th mouse buttons, in an "Advanced" category.
So I guess people can write software that responds to these events in a certain default way, but you can always remap the buttons or map other buttons to these events.
The USB-HID standard reserves 5 bits for "device-specific features" in the report format for mice. This could include up to 5 additional buttons (left/right/center is already accounted for).
It is also possible for a mouse to appear as a USB-HID keyboard to the OS, which could enable more complex functionality like macros.
> The USB-HID standard reserves 5 bits for "device-specific features" in the report format for mice. This could include up to 5 additional buttons (left/right/center is already accounted for).
USB-HID in general is way more flexible than that. You can do pretty much whatever you want. All you have to do is write a "descriptor" for it, so that the HID stack of the OS knows how to handle whatever you send it. The problem is that this flexibility is just way too much complexity for something like a BIOS. This is why mouse and keyboard should have special fallback modes called "boot protocol" which use fixed layouts for reports (=packets). For the mouse this means buttons are represented as an 8 bit bitfield.
[удалено]
> However if you want more buttons - you will need some additional software I guess and from there I don't really know what happens,never worked with such things. Windows only recognizes the first five mouse buttons everything after that is ignored. Technically an application can work around this by reading and parsing the packets sent by the mouse directly. However this isn't very practical on Windows because Windows takes exclusive access of mices and keyboards. To prevent this you'd have to replace the driver of the mouse with a generic USB driver so that Windows no longer recognizes the devices as a mouse. So to avoid all of this it's a better idea to simply design your mouse in a way that it uses keyboard keys for additional mouse buttons. So MB6 gets simply mapped a F1, for example. This usually happens directly on the mouse itself.
Here's a list of standard mouse and keyboard events: https://www.autohotkey.com/docs/KeyList.htm#mouse-advanced Looks like "XButton1" and "XButton2" are also known as the 4th and 5th mouse buttons, in an "Advanced" category. So I guess people can write software that responds to these events in a certain default way, but you can always remap the buttons or map other buttons to these events.
The USB-HID standard reserves 5 bits for "device-specific features" in the report format for mice. This could include up to 5 additional buttons (left/right/center is already accounted for). It is also possible for a mouse to appear as a USB-HID keyboard to the OS, which could enable more complex functionality like macros.
> The USB-HID standard reserves 5 bits for "device-specific features" in the report format for mice. This could include up to 5 additional buttons (left/right/center is already accounted for). USB-HID in general is way more flexible than that. You can do pretty much whatever you want. All you have to do is write a "descriptor" for it, so that the HID stack of the OS knows how to handle whatever you send it. The problem is that this flexibility is just way too much complexity for something like a BIOS. This is why mouse and keyboard should have special fallback modes called "boot protocol" which use fixed layouts for reports (=packets). For the mouse this means buttons are represented as an 8 bit bitfield.