Bug 313579

Confirmed. It used to be like 5%, now it's 15% making it completely useless on a touchpad (you cannot "scroll" precisely there)

I am using KDE 4.9.97 and mouseover kmix and scrolling does nothing.
I would have hope it would volume up/down
...

I can confirm this bug (two different PCs). 
Scroll volume step is now 3 times bigger than value in settings. I had to set smaller value in kmixrc, I am now using parameter VolumePercentageStep=2, which make volume step 6%.

Same here, gentoo kde-4.10RC3

Cannot reproduce that. And the code has not changed since quite some time. The code is like that:

     int inc = vol.volumeSpan() / Mixer::VOLUME_STEP_DIVISOR;
    if ( inc < 1 ) inc = 1;

VOLUME_STEP_DIVISOR is 20 as default, so if for example the control has volumes 0 - 200 , I will use  inc = 201/20 = 10.  And 10 is about 5% of 201.

I also cannot reproduce Mathieus issue, and it should not happen as I always increment by at least 1.

I also checked the code and wondered how it could have broken but here it did. Here it always in/decreases by 15% when using the mousewheel and 5 when using function keys. The mousehweel scroll setting (how many pages are scrolled, which is 3, so I thought maybe it's there because 3*5=15) has no effect.

I am seeing this also 4.9.98/F18. However it only happens here if I scroll on the system tray icon.
If you Click on the icon and scroll the volume slider from the pop up box the steps are how they where ~ 5%

Thanks everybody for all the your insightful input.

I have now read the Qt docs again. It is clearer now than in the past about specifying the magical number "120", see http://doc.qt.digia.com/main-snapshot/qwheelevent.html#delta :

 > Returns the distance that the wheel is rotated, in eighths of a degree. [...]
 > Most mouse types work in steps of 15 degrees, in which case the delta value is a multiple of 120; i.e., 120 units * 1/8 = 15 degrees.
 > However, some mice have finer-resolution wheels and send delta values that are less than 120 units (less than 15 degrees).

So what does this mean:

a) The 0% issue (Mathieus issue):
So, if delta is less than 120, I will finally end with a "change value" of cv = 0:
  long int cv = inc * (delta / 120 );  // delta/120 == 0  (for all delta <120). Thus cv == 0

b) The 15% issue (original bug report):
If your page scroll is 3, then the KMix behavior is correct. 3*5% = 15%.

There would be one universal "solution". Ignore all "delta" values, because a "page step" does not seem to make sense in the context of KMix. Thus always head for a predefined value. Though this has the risk to break optimal use of alternative input devices (Touchpad, Track Pad, Trackball), I will consider to go this way.

Yes, this looks like an old TODO. I added the following to the Slider class some time ago:

/**
 * TOOD This should go to the Volume class, so we can use it anywhere,
 * like mouse wheel, OSD, Keyboard Shortcuts
 */
long MDWSlider::calculateStepIncrement ( Volume&vol, bool decrease )
{
  	long inc = vol.volumeSpan() / Mixer::VOLUME_STEP_DIVISOR;
	if ( inc == 0 )	inc = 1;
	if ( decrease ) inc *= -1;
	return inc;
}

Created attachment 76912 [details]
Patch for branch KDE 4.10

The patch can be applied to KDE 4.10 branch. In trunk I will do the real/full solution.

Git commit 207fa53763d83e8031be622c9006e41b97195d48 by Christian Esken.
Committed on 04/02/2013 at 23:30.
Pushed by esken into branch 'master'.

Use a fixed volume step of n% instead of honoring mouse delta (which is more appropriate for text documents). Also Mouse Wheel now only affects EITHER playback OR capture
Related: bug 300783

M  +1    -1    apps/kmix.cpp
M  +0    -1    core/mixdevice.cpp
M  +14   -14   core/mixer.cpp
M  +0    -3    core/mixer.h
M  +29   -8    core/volume.cpp
M  +6    -1    core/volume.h
M  +9    -9    gui/kmixdockwidget.cpp
M  +9    -7    gui/ksmallslider.cpp
M  +67   -46   gui/mdwslider.cpp
M  +1    -3    gui/mdwslider.h

http://commits.kde.org/kmix/207fa53763d83e8031be622c9006e41b97195d48

*** Bug 314577 has been marked as a duplicate of this bug. ***

*** Bug 315173 has been marked as a duplicate of this bug. ***

Resolved for KDE 4.11.
There is also a certain chance that the whole code gets copied back to the 4.10 branch. But don't take it for granted.

*** Bug 314543 has been marked as a duplicate of this bug. ***

Created attachment 77944 [details]
kDebug output for kmix

Hi there, I have more or less the same problem here (mouse wheel makes 15% volume change from 4.10), but I'm not sure this is the same issue. From comment #8 it seems if you set page scroll to 1, you should get 5%, and this is not what happens it seems.

I enabled kDebug() and I can see that the function trayWheelEvent is called 3 times, so the volume is increased/decreased 3 times, hence 15%. But again I have the page scroll set to 1, so this seems a separate bug isn't it? Also this happens for all Qt application it seems: using the mouse wheel over the amarok icon in the systray has a 12% volume increase, but using the wheel on the volume control inside the amarok application just works as expected and does 1% volume change with page scroll set to 1 (3% if set to 3). The 12% if fixed, not matter the page scroll value. In VLC using the scroll wheel on the video area now change the volume more then before (again 12.5% it seems), using the wheel on the volume bar does increase/descrease the volume by 5% as expected.

I think this is related/triggered by KDE since it happens from KDE 4.10 update... but can be a Qt bug. Any help is appreciated (this issue is very annoying)

attached is the kDebug() for a single mouse wheel movement

*** Bug 317024 has been marked as a duplicate of this bug. ***

*** Bug 316546 has been marked as a duplicate of this bug. ***

Christian, why didn't you push your fix from #10 or a backport of the full fix to the 4.10 branch?
This is a big usability bug after all.

The patch from #10 doesn't seem to fix the issue. The volume still changes by 15% points.

Confirmed. The problem still exists in 4.10.2.

Kubuntu 13.04 x86.

*** Bug 319810 has been marked as a duplicate of this bug. ***

When it says "Patch for branch KDE 4.10" does that mean the patch has been applied to 4.10? Should 4.10.2 be working properly?

If so, please re-open this bug. Thanks!

*** This bug has been marked as a duplicate of bug 316546 ***

It appears that there is a bug in KStatusNotifierItem causing mouse wheel events to be processed 3 times, listed as bug 316546.  I don't know if these are two separate bugs or if patching kmix was just the wrong way to fix it.  Either way, since this report has a patch that fixes perhaps a different bug, I don't think these should be marked as duplicates.

i don't know which is the bug that causes this behavior but that patch didn't fix the problem on my pc. so i ended up using "long cv = inc/3;" and now it seems ok.

*** Bug 324454 has been marked as a duplicate of this bug. ***

Workaround. Insert the following in the [Global]-section in kmixrc

VolumePercentageStep=1.6666

Git commit e318bedab3022b2972f0fe9699529afa75d68372 by Christian Esken.
Committed on 20/01/2015 at 21:09.
Pushed by esken into branch 'master'.

Fix kmix tray icon scrolling for high-precision scroll devices like
touchpads.
Related: bug 341536
REVIEW: 121725

M  +23   -6    gui/kmixdockwidget.cpp
M  +1    -0    gui/kmixdockwidget.h

http://commits.kde.org/kmix/e318bedab3022b2972f0fe9699529afa75d68372