I just updated to 2.6.12-rc4 and now /dev/input/mouse0 seems to be my ps2
keyboard. My ps2 mouse is now on /dev/input/mouse1.
Good thing to catch before you release 2.6.12 and get the usual swarm of "my
mouse stopped working" reports. It seems to be getting to be a pattern:
upgrade linux kernel -- debug why mouse stopped working.
--
greg
On Monday 16 May 2005 00:12, Greg Stark wrote:
>
> I just updated to 2.6.12-rc4 and now /dev/input/mouse0 seems to be my ps2
> keyboard. My ps2 mouse is now on /dev/input/mouse1.
>
>
> Good thing to catch before you release 2.6.12 and get the usual swarm of "my
> mouse stopped working" reports. It seems to be getting to be a pattern:
> upgrade linux kernel -- debug why mouse stopped working.
>
atkbd's scroll support was turned on by default causing mouse moved over a
bit.
Please use /dev/input/mice for accessing your mouse. /dev/input/mouseX are
not guaranteed to be stable, if you need stable names you'll have to adjust
your hotplug scripts.
--
Dmitry
Dmitry Torokhov wrote:
>On Monday 16 May 2005 00:12, Greg Stark wrote:
>
>
>>I just updated to 2.6.12-rc4 and now /dev/input/mouse0 seems to be my ps2
>>keyboard.
>>
>Please use /dev/input/mice for accessing your mouse.
>
One possibly interesting mouse issue in 2.6.12-rc[1..4] is that when
using /dev/psaux, I have found that my mouse cursor under GPM seems to
be triggered into un-hiding when I issue some random number of
non-hiding key-down events. That is, press and release the keyboard
shift key say 3 or 5 or 10 times, and the console mouse cursor will
appear, just as if the mouse had been moved. This bug is not in 2.6.11
(nor Alan's 2.6.11-ac7, fwiw).
Kris
On Monday 16 May 2005 22:42, Kris Karas wrote:
> Dmitry Torokhov wrote:
>
> >On Monday 16 May 2005 00:12, Greg Stark wrote:
> >
> >
> >>I just updated to 2.6.12-rc4 and now /dev/input/mouse0 seems to be my ps2
> >>keyboard.
> >>
> >Please use /dev/input/mice for accessing your mouse.
> >
>
> One possibly interesting mouse issue in 2.6.12-rc[1..4] is that when
> using /dev/psaux, I have found that my mouse cursor under GPM seems to
> be triggered into un-hiding when I issue some random number of
> non-hiding key-down events. That is, press and release the keyboard
> shift key say 3 or 5 or 10 times, and the console mouse cursor will
> appear, just as if the mouse had been moved. This bug is not in 2.6.11
> (nor Alan's 2.6.11-ac7, fwiw).
>
This is caused by atkbd's scrolling support + GPM not expecting to see a
0-motion packets from devices... I'd say we need to fix GPM not to set
GPM_MOVE in these cases; I have looked into adjusting mousedev but it is
too ugly for words to suppress them there.
Although... maybe the patch below is not too ugly.
--
Dmitry
Input: mousedev - try not to report 0-motion 0-button mouse events
to userspace. GPM considers such packets motion data and
starts displaying selection cursor.
Signed-off-by: Dmitry Torokhov <[email protected]>
--
mousedev.c | 23 ++++++++++++++---------
1 files changed, 14 insertions(+), 9 deletions(-)
Index: dtor/drivers/input/mousedev.c
===================================================================
--- dtor.orig/drivers/input/mousedev.c
+++ dtor/drivers/input/mousedev.c
@@ -9,7 +9,7 @@
* the Free Software Foundation.
*/
-#define MOUSEDEV_MINOR_BASE 32
+#define MOUSEDEV_MINOR_BASE 32
#define MOUSEDEV_MINORS 32
#define MOUSEDEV_MIX 31
@@ -101,6 +101,7 @@ struct mousedev_list {
unsigned char ready, buffer, bufsiz;
unsigned char imexseq, impsseq;
enum mousedev_emul mode;
+ unsigned long last_buttons;
};
#define MOUSEDEV_SEQ_LEN 6
@@ -202,7 +203,7 @@ static void mousedev_key_event(struct mo
case BTN_SIDE: index = 3; break;
case BTN_4:
case BTN_EXTRA: index = 4; break;
- default: return;
+ default: return;
}
if (value) {
@@ -224,7 +225,7 @@ static void mousedev_notify_readers(stru
spin_lock_irqsave(&list->packet_lock, flags);
p = &list->packets[list->head];
- if (list->ready && p->buttons != packet->buttons) {
+ if (list->ready && p->buttons != mousedev->packet.buttons) {
unsigned int new_head = (list->head + 1) % PACKET_QUEUE_LEN;
if (new_head != list->tail) {
p = &list->packets[list->head = new_head];
@@ -249,10 +250,13 @@ static void mousedev_notify_readers(stru
p->dz += packet->dz;
p->buttons = mousedev->packet.buttons;
- list->ready = 1;
+ if (p->dx || p->dy || p->dz || p->buttons != list->last_buttons)
+ list->ready = 1;
spin_unlock_irqrestore(&list->packet_lock, flags);
- kill_fasync(&list->fasync, SIGIO, POLL_IN);
+
+ if (list->ready)
+ kill_fasync(&list->fasync, SIGIO, POLL_IN);
}
wake_up_interruptible(&mousedev->wait);
@@ -320,7 +324,7 @@ static void mousedev_event(struct input_
mousedev->pkt_count++;
/* Input system eats duplicate events, but we need all of them
* to do correct averaging so apply present one forward
- */
+ */
fx(0) = fx(1);
fy(0) = fy(1);
}
@@ -477,9 +481,10 @@ static void mousedev_packet(struct mouse
}
if (!p->dx && !p->dy && !p->dz) {
- if (list->tail == list->head)
+ if (list->tail == list->head) {
list->ready = 0;
- else
+ list->last_buttons = p->buttons;
+ } else
list->tail = (list->tail + 1) % PACKET_QUEUE_LEN;
}
@@ -695,7 +700,7 @@ static struct input_device_id mousedev_i
.absbit = { BIT(ABS_X) | BIT(ABS_Y) | BIT(ABS_PRESSURE) | BIT(ABS_TOOL_WIDTH) },
}, /* A touchpad */
- { }, /* Terminating entry */
+ { }, /* Terminating entry */
};
MODULE_DEVICE_TABLE(input, mousedev_ids);
Hi!
> > I just updated to 2.6.12-rc4 and now /dev/input/mouse0 seems to be my ps2
> > keyboard. My ps2 mouse is now on /dev/input/mouse1.
> >
> >
> > Good thing to catch before you release 2.6.12 and get the usual swarm of "my
> > mouse stopped working" reports. It seems to be getting to be a pattern:
> > upgrade linux kernel -- debug why mouse stopped working.
> >
>
> atkbd's scroll support was turned on by default causing mouse moved over a
> bit.
>
> Please use /dev/input/mice for accessing your mouse. /dev/input/mouseX are
> not guaranteed to be stable, if you need stable names you'll have to adjust
> your hotplug scripts.
Please please, fix this one. It causes spurious events in /dev/psaux
when you type on keyboard. Events are nops (no movement, no clicks),
but they still wake up gpm (ugly) and make it show mouse cursor. So
you have second, blinking! cursor on your screen when you type.
Pavel
Hi!
> > >>I just updated to 2.6.12-rc4 and now /dev/input/mouse0 seems to be my ps2
> > >>keyboard.
> > >>
> > >Please use /dev/input/mice for accessing your mouse.
> > >
> >
> > One possibly interesting mouse issue in 2.6.12-rc[1..4] is that when
> > using /dev/psaux, I have found that my mouse cursor under GPM seems to
> > be triggered into un-hiding when I issue some random number of
> > non-hiding key-down events. That is, press and release the keyboard
> > shift key say 3 or 5 or 10 times, and the console mouse cursor will
> > appear, just as if the mouse had been moved. This bug is not in 2.6.11
> > (nor Alan's 2.6.11-ac7, fwiw).
> >
>
> This is caused by atkbd's scrolling support + GPM not expecting to see a
> 0-motion packets from devices... I'd say we need to fix GPM not to set
> GPM_MOVE in these cases; I have looked into adjusting mousedev but it is
> too ugly for words to suppress them there.
>
> Although... maybe the patch below is not too ugly.
Looks pretty much okay to me...
Pavel
On 5/18/05, Pavel Machek <[email protected]> wrote:
> Hi!
>
> > > >>I just updated to 2.6.12-rc4 and now /dev/input/mouse0 seems to be my ps2
> > > >>keyboard.
> > > >>
> > > >Please use /dev/input/mice for accessing your mouse.
> > > >
> > >
> > > One possibly interesting mouse issue in 2.6.12-rc[1..4] is that when
> > > using /dev/psaux, I have found that my mouse cursor under GPM seems to
> > > be triggered into un-hiding when I issue some random number of
> > > non-hiding key-down events. That is, press and release the keyboard
> > > shift key say 3 or 5 or 10 times, and the console mouse cursor will
> > > appear, just as if the mouse had been moved. This bug is not in 2.6.11
> > > (nor Alan's 2.6.11-ac7, fwiw).
> > >
> >
> > This is caused by atkbd's scrolling support + GPM not expecting to see a
> > 0-motion packets from devices... I'd say we need to fix GPM not to set
> > GPM_MOVE in these cases; I have looked into adjusting mousedev but it is
> > too ugly for words to suppress them there.
> >
> > Although... maybe the patch below is not too ugly.
>
> Looks pretty much okay to me...
Hi Pavel,
Does it work for you? If so I'll send it to Andrew to simmer in -mm.
--
Dmitry
Dmitry Torokhov wrote:
>On 5/18/05, Pavel Machek <[email protected]> wrote:
>
>
>>>Although... maybe the patch below is not too ugly.
>>>
>>>
>>Looks pretty much okay to me...
>>
>>
>
>Does it work for you? If so I'll send it to Andrew to simmer in -mm.
>
>
FWIW, I've tested the patch and it seems to be working just fine. Thanks!
There is one exception, though it does not appear to be related to the
mouse code or the patch, as far as I can tell. Pressing or releasing
the right-windows key sends a blank event to GPM (as reported by 'mev')
causing the mouse cursor to reappear. If I use "showkey -s" to tell me
the scancode, nothing happens. The key is evidently bound in the kernel
table, else I'd see the obligatory PRINTK encouraging me to bind it. So
something is intercepting the key and sending it to GPM.
Experimentally, it appears as if the key press is delivered only if it
has not been pressed for roughly 3 seconds (256 Jiffies???).
Kris
On Wednesday 18 May 2005 17:17, Kris Karas wrote:
> Dmitry Torokhov wrote:
>
> >On 5/18/05, Pavel Machek <[email protected]> wrote:
> >
> >
> >>>Although... maybe the patch below is not too ugly.
> >>>
> >>>
> >>Looks pretty much okay to me...
> >>
> >>
> >
> >Does it work for you? If so I'll send it to Andrew to simmer in -mm.
> >
> >
>
> FWIW, I've tested the patch and it seems to be working just fine. Thanks!
>
> There is one exception, though it does not appear to be related to the
> mouse code or the patch, as far as I can tell. Pressing or releasing
> the right-windows key sends a blank event to GPM (as reported by 'mev')
> causing the mouse cursor to reappear. If I use "showkey -s" to tell me
> the scancode, nothing happens. The key is evidently bound in the kernel
> table, else I'd see the obligatory PRINTK encouraging me to bind it. So
> something is intercepting the key and sending it to GPM.
> Experimentally, it appears as if the key press is delivered only if it
> has not been pressed for roughly 3 seconds (256 Jiffies???).
>
I wonder if the this patch from Vojtech will cure that problem...
--
Dmitry
===================================================================
From: Vojtech Pavlik <[email protected]>
Input: Fix fast scrolling scancodes in atkbd.c
Signed-off-by: Vojtech Pavlik <[email protected]>
--
atkbd.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Index: dtor/drivers/input/keyboard/atkbd.c
===================================================================
--- dtor.orig/drivers/input/keyboard/atkbd.c
+++ dtor/drivers/input/keyboard/atkbd.c
@@ -171,9 +171,9 @@ static struct {
unsigned char set2;
} atkbd_scroll_keys[] = {
{ ATKBD_SCR_1, 0xc5 },
- { ATKBD_SCR_2, 0xa9 },
- { ATKBD_SCR_4, 0xb6 },
- { ATKBD_SCR_8, 0xa7 },
+ { ATKBD_SCR_2, 0x9d },
+ { ATKBD_SCR_4, 0xa4 },
+ { ATKBD_SCR_8, 0x9b },
{ ATKBD_SCR_CLICK, 0xe0 },
{ ATKBD_SCR_LEFT, 0xcb },
{ ATKBD_SCR_RIGHT, 0xd2 },