Highrez

Hello,
I have a Logitech M590 mouse.
How do I adjust the sound volume on my PC by pushing a mouse button and using the mouse scroll wheel at the same time?

Look at button chording for the button you wish to combine with the wheel...

Enable button chording on that button, then in the chord configuration window that pops up (or press the cog button to open it) you can change the wheel to adjust the volume... Wheel up should be mapped to "Media: Volume Up" and wheel down to "Media: Volume Down"

I use this all the time and it works nicely...

Let me know if you need further assistance (tell me which button you want this to work on) and I can send you an example profile that you can import or something.

Thanks,
Phil

Hello,
Thank you for that answer. I don't know if I am well described.
On the right side of the mouse there are two buttons, what I would like is to push on one of the two buttons and the wheel to adjust the sound and if I don't push this button to be able to use the wheel to scroll.

I managed to do what you advised me and it worked (translation problem with Google)
Unfortunately sometimes it works then it doesn't work anymore and I have to put the mouse cursor on the speaker sympole of the taskbar or I have to put the mouse cursor on the music player, it's not very convenient.

I join the profile file I created. I don't know if I configured everything correctly

Hi, that profile seems to work fine here. Maybe its not working because you have "unblock when mouse moves" or unbloch after 750ms. Try turning them off and see what works best for you!

It is working very well now with your advice. A very big thank you

Great, thanks for letting me know!

Hello,
I have a problem with scrolling the mouse cursor to adjust the sound on Youtube and Vimeo videos.
When I click the mouse button and touch the mouse wheel, the sound cursor moves all the way up or down. I don't have this problem on my own videos. Can you advise me, thank you

sorry, I have no idea why one video would be different from any other!

But I think I know what the problem is and how it can be fixed in XMouse Button Control.

The problem are Mice with a high resolution wheel which send more messages per angle, but often only in web browsers. Thats why it appears only in a video on the YouTube web page and not in a video played by a media player outside a browser.

To solve this you have to change how XMouse Button Control handles the WM_MOUSEWHEEL message. It should only take the user-selected action (e. g. changing the volume level) when the accumulated delta reaches the delta per line. Here is some C code snippet taken from the internet:
Of course you can extend this e. g. to change the volume level by 1 instead of 2 when (iAccumDelta >= iDeltaPerLine div 2) or (iAccumDelta <= -iDeltaPerLine div 2).

Hi, I don't believe this theory (good as it my be) is correct in this case...

The mouse can't send more "messages" per angle only in a web browser or any other application. A web browser (or any application) *could* change they way it behaves to each scroll message but thats irrelevant here as were talking XMBC - the scroll messages are never seen by the web browser because XMBC has intercepted them and changed them.

The mouse wheel sends ONE scroll message per "notch" where "notch" is the traditional single movement on a traditional wheeled mouse. Now with the free-scrolling (Logitech and others) mice, there is no notch, but the distance for said notch is still a fixed unit and as each hole on the fly wheel travels past the light sensor (thats effectively how the wheel is picked up) it will send one notch. It can do this VERY quickly in freewheel mode.

XMBC runs at global mouse hook level, so I don't see how it could be different in any particular application - because XMBC is handling these messages long before they get to the application.

XMBC already makes use of SPI_GETWHEELSCROLLLINES (and can change it on the fly too) but that is handled after the mouse hook is run, not before it. So XMBC should be above all of that in this case.

phil wrote: ↑Mon Mar 01, 2021 9:51 pmThe mouse can't send more "messages" per angle only in a web browser or any other application.

It does it the same way as your application does, it checks which application has the focus. In the older Logitech SetPoint software there was a browser add-on needed which switched the mode on activating/deactivating by sending a TCP request to the always running SetPoint service (you can find the code on the internet).

You can prove this behaviour by scrolling in Word when the browser has the focus and vice versa. In the first case you can also smooth scroll in Word which is otherwise not possible and in the second case you can scroll only in line steps also in the browser.

The mouse wheel sends ONE scroll message per "notch" where "notch" is the traditional single movement on a traditional wheeled mouse. Now with the free-scrolling (Logitech and others) mice, there is no notch, but the distance for said notch is still a fixed unit and as each hole on the fly wheel travels past the light sensor (thats effectively how the wheel is picked up) it will send one notch.

A wheel in normal mode sends one message per notch with a delta of 120, a wheel with double resolution sends two messages per notch each with a delta of 60, a wheel with triple resolution sends three messages per notch each with a delta of 40 and so on. By the way that's why Microsoft choose 120 as the default, it has a good factoring.

It can do this VERY quickly in freewheel mode.

That is true but that is not the point here.

XMBC runs at global mouse hook level, so I don't see how it could be different in any particular application - because XMBC is handling these messages long before they get to the application.

As I have written before the Logitech service checks which application is active and enables/disables the high resolution mode of the mouse driver respectively.

OK That is interesting, I didn't realize the Logitech software did this - I tend not to install the Logitech bloatware at all and rely solely on XMBC
Maybe I'll have to install it on a test machine and see what I can find.

XMBC does already read the delta's so in theory it should be honoring it - but if they have changed in the meantime that will be a problem - XMBC does not read them every time it receives a message (that would be a real problem as it will introduce more lag which is the worst enemy in that bit of code dealing with rapid scroll messages) when maybe not in some cases such as remapping the scroll...
Again, even with high res, it shouldn't move the volume down that much immediately - so I'm still not convinced its the same problem.

Ive added this to my bug list to investigate. But I cant promise when I will actually find the time to spend on it in detail - very little time for XMBC these days (which is odd given in theory there is nothing else to do stuck indoors all day - its amazing what distractions are out/in there!)

phil wrote: ↑Mon Mar 01, 2021 11:54 pmXMBC does already read the delta's so in theory it should be honoring it - but if they have changed in the meantime that will be a problem - XMBC does not read them every time it receives a message (that would be a real problem as it will introduce more lag which is the worst enemy in that bit of code dealing with rapid scroll messages) when maybe not in some cases such as remapping the scroll...

To make it clear, the Logitech driver doesn't change the SPI_GETWHEELSCROLLLINES value, only the delta value in the wParam-argument of the WM_MOUSEWHEEL-message changes between normal and high resolution scrolling.

The only thing you have to do is to put the few lines shown in my first code snippet in your handling of the WM_MOUSEWHEEL-message when an user-selected action is supplied. You have to honor always the delta value in the wParam-argument, than it is irrelevant how the mouse works. This is a thing every application should do and most of them do. Otherwise a high resolution mouse wheel wouldn't work correctly with them.

Again, even with high res, it shouldn't move the volume down that much immediately - so I'm still not convinced its the same problem.

Of course it does it so much because the driver sends about ten messages (with a delta of 12) instead of one message (with a delta of 120). So if you change the volume every message it will be changed ten times faster. The correct way would be to change the volume only when the accumulated delta reaches the value 120 as shown in the code snippet.

Yes I get that, but what I was getting at was that even with a delta of 120, there are thousands of messages per second when free-wheeling - and this often can cause problems in XMBC. Nothing major but it still has to be considered. Just intercepting that many messages in a mouse hook is a bit resource hungry, because the thread scheduler comes into play and all that. So not having to read the deltas from the registry each time is a good thing - apologies I'm typing all this without looking at the code - but yes I believe the delta info is there in the mouse hook structure (its a bit different from the message W/LParam arguments (the WPARAM is the message and the LPARAM of the hook call points to the MSLLHOOKSTRUCT which contains much info, including the delta (I don't think I've ever seen it change from +-120 - but maybe thats because I don't install any Logitech software).