Unexpected button behavior with shift - Xwindows

This is a discussion on Unexpected button behavior with shift - Xwindows ; [searched high and wide, found nothing that addresses this] Run xev, press shift, click button-1, hold button AND key shows (relevant events only - well, what I _THINK_ is relevant): KeyPress event, serial 24, synthetic NO, window 0x2c00001, root 0x36, ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Unexpected button behavior with shift

  1. Unexpected button behavior with shift

    [searched high and wide, found nothing that addresses this]

    Run xev, press shift, click button-1, hold button AND key
    shows (relevant events only - well, what I _THINK_ is relevant):

    KeyPress event, serial 24, synthetic NO, window 0x2c00001,
    root 0x36, subw 0x0, time 2870161388, (151,102), root168,780),
    state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: ""

    ButtonPress event, serial 24, synthetic NO, window 0x2c00001,
    root 0x36, subw 0x0, time 2870162315, (151,102), root168,780),
    state 0x11, button 1, same_screen YES

    [pause of maybe 100 msec]

    ButtonRelease event, serial 24, synthetic NO, window 0x2c00001,
    root 0x36, subw 0x0, time 2870162391, (151,102), root168,780),
    state 0x111, button 1, same_screen YES


    KEEP HOLDING

    [nothing]

    release button-1

    [nothing]

    release shift

    KeyRelease event, serial 24, synthetic NO, window 0x2c00001,
    root 0x36, subw 0x0, time 2870166075, (287,72), root304,750),
    state 0x11, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: ""

    If I do the same thing WITHOUT shift, it waits until I let go of the button
    to send the KeyRelease event. If I hold down shift, it sends the KeyRelease
    almost immediately. If I wait for the auto-release event, and then drag the
    pointer, xev receives a NEW buttonPress event, THEN a motion event, then
    another auto-button-release event.

    A colleague reports that it does NOT happen that way on his machine, while
    it most certainly does on a different colleague's machine. All are Linux
    boxen. Mine is: Red Hat Enterprise Linux WS release 4 (Nahant Update 1)


    Are my expectations broken? Is my system misconfigured? If so, how to fix?
    Or is this "working as designed"?

    Thanks,
    MH

  2. Re: Unexpected button behavior with shift

    In article ,
    MH wrote:
    >[searched high and wide, found nothing that addresses this]
    >
    >Run xev, press shift, click button-1, hold button AND key
    >shows (relevant events only - well, what I _THINK_ is relevant):
    >
    >KeyPress event, serial 24, synthetic NO, window 0x2c00001,
    > root 0x36, subw 0x0, time 2870161388, (151,102), root168,780),
    > state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    > XLookupString gives 0 bytes: ""
    >
    >ButtonPress event, serial 24, synthetic NO, window 0x2c00001,
    > root 0x36, subw 0x0, time 2870162315, (151,102), root168,780),
    > state 0x11, button 1, same_screen YES
    >
    >[pause of maybe 100 msec]
    >
    >ButtonRelease event, serial 24, synthetic NO, window 0x2c00001,
    > root 0x36, subw 0x0, time 2870162391, (151,102), root168,780),
    > state 0x111, button 1, same_screen YES
    >
    >
    >KEEP HOLDING
    >
    >[nothing]
    >
    >release button-1
    >
    >[nothing]
    >
    >release shift
    >
    >KeyRelease event, serial 24, synthetic NO, window 0x2c00001,
    > root 0x36, subw 0x0, time 2870166075, (287,72), root304,750),
    > state 0x11, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    > XLookupString gives 0 bytes: ""
    >
    >If I do the same thing WITHOUT shift, it waits until I let go of the button
    >to send the KeyRelease event. If I hold down shift, it sends the KeyRelease
    >almost immediately. If I wait for the auto-release event, and then drag the
    >pointer, xev receives a NEW buttonPress event, THEN a motion event, then
    >another auto-button-release event.


    Summary:
    Microsoft Optical Desktop Pro combo (wireless mouse + keyboard) together
    (maybe only in PS/2 mode?) were the cause of the problem. Swapping EITHER
    the mouse or the keyboard solved the problem.

    MH

+ Reply to Thread