Bug 117540 - scrollwheel skips channels
scrollwheel skips channels
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-04 19:57 EST by John Ellson
Modified: 2015-01-04 17:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 19:43:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Ellson 2004-03-04 19:57:10 EST
Description of problem:
Changing channel with the scrollwheel (nice feature) changes by
two channels each increment, making it impossible to reach the
intervening channels without resorting to the keyboard.

Version-Release number of selected component (if applicable):
tvtime-0.9.12-3
logitech optical mouse with mousewheel

How reproducible:
100%

Steps to Reproduce:
1.tvtime
2.change channels with smallest possible mousewheel rotation
3.
  
Actual results:
Increments two channels

Expected results:
Increment one channel

Additional info:
Comment 1 Billy Biggs 2004-06-22 08:39:58 EDT
I have seen this once before where a mouse scroll wheel caused two
MouseDown events for each 'tick' of the mousewheel.

To test, try running the program 'xev' from a terminal window.  It
will pop up a window and show every X event received by it.  Move your
mouse into the window and tick the mousewheel one step up.  How many
MouseDown events do you see?
Comment 2 John Ellson 2004-06-22 13:17:08 EDT
Sure enough, for each click of the wheel I'm getting press-release
twice.    Can you use the time stamp to suppress the extras?

The events from  single tick of the wheel all have the same timestamp.

Rolling the wheel as fast as possible produced the groups of 4 events
with the same timestamp, but the timestamps were always different
between the groups AFAICT.

Here is a sequence of 12 events (3 ticks I assume) from a fast scroll.

ButtonPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382048, (120,76), root:(126,144),
    state 0x0, button 5, same_screen YES
 
ButtonRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382048, (120,76), root:(126,144),
    state 0x1000, button 5, same_screen YES
 
ButtonPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382048, (120,76), root:(126,144),
    state 0x0, button 5, same_screen YES
 
ButtonRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382048, (120,76), root:(126,144),
    state 0x1000, button 5, same_screen YES
 
ButtonPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382064, (120,76), root:(126,144),
    state 0x0, button 5, same_screen YES
 
ButtonRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382064, (120,76), root:(126,144),
    state 0x1000, button 5, same_screen YES
 
ButtonPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382064, (120,76), root:(126,144),
    state 0x0, button 5, same_screen YES
 
ButtonRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382064, (120,76), root:(126,144),
    state 0x1000, button 5, same_screen YES
 
ButtonPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382080, (120,76), root:(126,144),
    state 0x0, button 5, same_screen YES
 
ButtonRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382080, (120,76), root:(126,144),
    state 0x1000, button 5, same_screen YES
 
ButtonPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382080, (120,76), root:(126,144),
    state 0x0, button 5, same_screen YES
 
ButtonRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x58, subw 0x0, time 56382080, (120,76), root:(126,144),
    state 0x1000, button 5, same_screen YES
 
Comment 3 Billy Biggs 2004-06-22 13:43:18 EDT
I could look at the timestamps but this seems like a hack.  Is this
maybe a bug in the kernel mouse driver?  Do you have a USB mouse?

I will try and do the hack in tvtime tonight anyway.
Comment 4 John Ellson 2004-06-22 14:14:11 EDT
The fact that the 4 timestamps are always identical (AFAICT) does seem
to suggest that this is a software driver issue.

Yes it is a USB mouse.
Comment 5 John Ellson 2004-07-02 09:19:13 EDT
Where are we on this?  Should I generate a separate bug report against
the kernel and link it to this one?
Comment 6 Billy Biggs 2004-07-02 11:10:50 EDT
I've committed the workaround to tvtime CVS to watch the event times,
so it will be released in 0.9.13.  I think making a new bug for the
kernel issue is a good idea, but Than should be able to say more.  Than?
Comment 7 John Ellson 2004-10-09 10:20:59 EDT
This is fixed for me in Fedora-Development Oct 9, 2004

tvtime-0.9.13-1
kernel-smp-2.6.8-1.603.

Thanks.
Comment 8 Ngo Than 2004-10-11 04:18:40 EDT
John, i will reassign it to kernel component.
Comment 9 Dave Jones 2004-12-08 19:22:52 EST
can you test the 2.6.9 kernel update with the earlier tvtime release that
doesn't contain this workaround please?
Comment 10 John Ellson 2004-12-08 19:32:23 EST
Problem still exists with:
  tvtime-0.9.12-5
  kernel-smp-2.6.9-1.1020_FC4
Comment 11 John Ellson 2004-12-09 16:26:11 EST
Problem still exists with:
  tvtime-0.9.12-5
  kernel-smp-2.6.9-1.1021_FC4

Also, the problem can be seen quite clearly with xev, without needing
to downgrade tvtime.
Comment 12 Dave Jones 2005-10-05 19:43:31 EDT
on current kernels, xev shows increasing time stamps for me, so I'm going to
close this. Feel free to reopen if it reoccurs.

Note You need to log in before you can comment on or make changes to this bug.