resending-- Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)!]
resending another lost message - Forwarded message from Linas Vepstas <[EMAIL PROTECTED]>, [EMAIL PROTECTED] - Subject: Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)! In-Reply-To: <[EMAIL PROTECTED]> "from Gunther Mayer at Apr 8, 2001 10:23:09 pm" To: Gunther Mayer <[EMAIL PROTECTED]> Date: Mon, 9 Apr 2001 18:42:51 -0500 (CDT) From: Linas Vepstas <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED] X-Mailer: ELM [version 2.4ME+ PL87 (25)] It's been rumoured that Gunther Mayer said: > Losing bytes on psaux is a bug! [...] > This patch printk's necessary information on the first 2 cases and I had applied a similar set of printk's several weeks ago; however, now the problem refuses to recur. Hmmm ... the last time I had a problem that went away when I added printf's ... Just to be sure, I'm going to try running the kernel without the printk's again. Unfortunately, I upgraded the xserver yesterday, and so I fear that may mask further re-occurances ... --linas - End forwarded message - -- Linas Vepstas -- [EMAIL PROTECTED] -- http://linas.org/ PGP signature
resending Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)!]
Resending ... - Forwarded message from Linas Vepstas <[EMAIL PROTECTED]>, [EMAIL PROTECTED] - Subject: Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)! In-Reply-To: <[EMAIL PROTECTED]> "from Gunther Mayer at Apr 8, 2001 10:23:09 pm" To: Gunther Mayer <[EMAIL PROTECTED]> Date: Thu, 12 Apr 2001 22:18:10 -0500 (CDT) From: Linas Vepstas <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED] X-Mailer: ELM [version 2.4ME+ PL87 (25)] The 'mouse-lost-byte' saga continues: It's been rumoured that Gunther Mayer said: > > Original Problem: PS/2 mouse pointer goes upper right corner and stays there. > Diagnosis: one byte was lost > > Losing bytes on psaux is a bug! > > We must first understand, how bytes can be lost (most probable first): [...] > > This patch printk's necessary information on the first 2 cases and > should be applied to the stable kernel, as this will help to resolve a severe bug ! > [ Attachment, skipping... ] I now am having a terrible time reproducing the problem. Based on this, I nominate another possibility: race conditions involving APM/ACPI/bios. Here's some more diagnostic info, as best as I can remember it: Long ago (circa 2.3.99/2.4.0) I enabled APM/ACPI in the kernel, and in the bios, with the intent of auto-shutting off the monitor after a few hours. (This is a desktop machine, so no battery concerns, but I was feeling green, what with the cost of solar cells and all ...). This, coupled with XFree86-3.3 seemed to work fine, for a long time (months). I think (don't quite remember) upgrading to 2.4.2 is when the mouse problems started. And also some screen-saver problems. Every now-and-then, it seemed I would move my mouse just as the screen-saver kicked in (at least thats what I think was happening). Screen would flash, X would freeze for half a second, some confusion, and back to normal. Or not: sometimes the pointer would fly up to top left, and do the 'lost byte' symptoms. Don't know if this really was apm/acpi triggering this, but some freinds warned me of possible bad interactions, so I started shutting down apm/acpi. First in the kernel (one week), later in bios (another week). This seemed to make matters worse. Towards the end, the screensaver would kick in after a minute. And, very oddly, would kick in whenever I clicked on a netscape link (!really!). After reviewing/fiddling my bios settings for apm for the umpteenth time I reported my 'missing mouse byte' problem to LKML. And ever since, I've been unable to reproduce the problem. I am now trying to fiddle with bios to turn APM back on (and also in the kernel), but so far, no luck in destabizing the kernel (and also, no luck in getting the monitor to auto-shutoff...) --linas - End forwarded message - -- Linas Vepstas -- [EMAIL PROTECTED] -- http://linas.org/ PGP signature
Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)!
Original Problem: PS/2 mouse pointer goes upper right corner and stays there.
Diagnosis: one byte was lost and this is fatal for the mouse driver.
Various people wrote:
>
> On Wed, Mar 28, 2001 at 05:19:33PM -0600, [EMAIL PROTECTED] wrote:
..
> > > > > > > I am experiencing debilitating intermittent mouse problems & was about
> > > > > >
> > > > > > This is easily explained: some byte of the mouse protocol was lost.
>
> Plus, it's very likely the new PS/2 code will break on some systems that
> have not-so-compatible i8042 chips, so it is really something that can't
Losing bytes on psaux is a bug!
We must first understand, how bytes can be lost (most probable first):
- transmission error on the line can easily happen in noisy environments
and is _not_ handled correctly by linux (i.e. should do RESEND)
- 0xAA is always handled as reconnect, if the mouse generates this byte,
Linux will de-sync the mouse driver
- Mouse is defective or keyboard controller defective
- An error in the linux kbd/mouse driver (e.g. triggered by X11<->console switching)
This patch printk's necessary information on the first 2 cases and
should be applied to the stable kernel, as this will help to resolve a severe bug !
Regards, Gunther
P.S.
These messages can be generated:
Apr 8 21:49:23 linux kernel: psaux: reconnect 0xAA detected
Apr 8 21:49:42 linux kernel: pc_keyb: mouse error (0x75), byte ignored(ff).
Apr 8 21:49:43 linux kernel: psaux: reconnect 0xAA detected
--- linux-2.4.3-orig/drivers/char/pc_keyb.c Wed Apr 4 19:46:42 2001
+++ linux/drivers/char/pc_keyb.cSun Apr 8 21:45:37 2001
@@ -404,6 +404,11 @@
mouse_reply_expected = 0;
}
else if(scancode == AUX_RECONNECT){
+ // Under normal operation most mice don't generate 0xAA.
+ // But, Other devices might be unusable with this policy.
+ // (My mouse easily generates 0xAAs on rapid movements,
+ // when set to 10 samples/sec.)
+ printk("psaux: reconnect detected(0xaa), sending AUX_ENABLE.\n");
queue->head = queue->tail = 0; /* Flush input queue */
__aux_write_ack(AUX_ENABLE_DEV); /* ping the mouse :) */
return;
@@ -420,6 +425,9 @@
kill_fasync(&queue->fasync, SIGIO, POLL_IN);
wake_up_interruptible(&queue->proc_list);
}
+ else
+ // 2K buffer is enough for about 10 sec under normal
+operations, here.
+ printk("psaux: buffer overflow, byte dropped.\n");
}
#endif
}
@@ -465,6 +473,11 @@
else
handle_keyboard_event(scancode);
}
+ else
+ // Fixme: Ignoring bytes will de-sync mouse protocol.
+ printk("pc_keyb: %s error (0x%02x), byte ignored(%02x).\n",
+ (status & KBD_STAT_MOUSE_OBF)?"mouse":"kbd",status,scancode);
+
status = kbd_read_status();
}
gmdiff-lx243-psaux-error-reporting
Re: mouse problems in 2.4.2 -> lost byte
On Wed, Mar 28, 2001 at 05:19:33PM -0600, [EMAIL PROTECTED] wrote: > It's been rumoured that Vojtech Pavlik said: > > On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote: > > > [EMAIL PROTECTED] wrote: > > > > It's been rumoured that Gunther Mayer said: > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > > > > > I am experiencing debilitating intermittent mouse problems & was about > > > > > > > > > > This is easily explained: some byte of the mouse protocol was lost. > > > > > > > Getting resync right is not as easy as detecting zero bytes. You > > > should account for wild protocol variations in the world wide mouse > > > population, too. > > > > The new input psmouse driver can resync when bytes are lost and also > > shouldn't lose any bytes if there are not transmission problems on the > > wire. But this is 2.5 stuff. > > umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be > years away ... and this seems 'minor', wouldn't it be better to > submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x > patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this > cant be more than a few hundred lines of code? Requireing no other > changes to the kernel? To work correctly, this requires to kill the current psaux and keyboard driver, and those two are one file, and are very very builtin into the console system. Thus it's a patch of almost thousand lines to pc_keyb.c and keyboard.c and can't easily added as a CONFIG_ option. Plus, it's very likely the new PS/2 code will break on some systems that have not-so-compatible i8042 chips, so it is really something that can't go in 2.4. And I would love to have it in 2.4, really. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
>> The new input psmouse driver can resync when bytes are lost and also >> shouldn't lose any bytes if there are not transmission problems on the >> wire. But this is 2.5 stuff. > >umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be >years away ... and this seems 'minor', wouldn't it be better to >submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x >patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this >cant be more than a few hundred lines of code? Requireing no other >changes to the kernel? Its more than a few hundred lines. Mind you it wouldn't be hard to patch 2.4.X to use the new PS/2 drivers but it is a pretty big change. I seriously don't it would go in. Your welcomed to try out these drivers. I have personally been using these new PS/2 drivers for several months now with now problems. In fact this driver can trick my i8042 chipset to allow me to plug two PS/2 keyboards in :-) MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
>So you recommend to connect the mouse to USB (instead of psaux) because >psaux+Xfree86 are losing bytes under circumstances (e.g. some load >pattern). > >This is a fine solution for users with dual protocol mice, but doesn't >resolve the problem for other poor ps/2 mouse owners ! You misunderstood me. For 2.4.X it is: Real PS/2 mouse -> /dev/psaux -> PS/2 protocol -> X server All mice using /dev/input/mice -> PS/2 protocol -> X server Yes mice. I have had 5 mice attached and going to the X server. It was no problem. Multiple keyboards, well that is another story :-( It doesn't matter to the X server if two different devices are sending the same protocol. Since the protocol is coming in from two different devices theri is no conflict. I believe we was having problems with another type of mouse. >Even with PS/2 mouse support in the "new input" driver I wouldn't expect >the psaux-byte-lost bug to disappear magically. I see Vojtech has answered this already. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
It's been rumoured that Vojtech Pavlik said: > On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote: > > [EMAIL PROTECTED] wrote: > > > It's been rumoured that Gunther Mayer said: > > > > [EMAIL PROTECTED] wrote: > > > > > > > > > > I am experiencing debilitating intermittent mouse problems & was about > > > > > > > > This is easily explained: some byte of the mouse protocol was lost. > > > > > Getting resync right is not as easy as detecting zero bytes. You > > should account for wild protocol variations in the world wide mouse > > population, too. > > The new input psmouse driver can resync when bytes are lost and also > shouldn't lose any bytes if there are not transmission problems on the > wire. But this is 2.5 stuff. umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be years away ... and this seems 'minor', wouldn't it be better to submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this cant be more than a few hundred lines of code? Requireing no other changes to the kernel? --linas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote: > [EMAIL PROTECTED] wrote: > > > > It's been rumoured that Gunther Mayer said: > > > > > > > I am experiencing debilitating intermittent mouse problems & was about > > > ... > > > > Symptoms: > > > > After a long time of flawless operation (ranging from nearly a week to > > > > as little as five minutes), the X11 pointer flies up to top-right corner, > > > > > > > and mostly wants to stay there. Moving the mouse causes a cascade of > > > > spurious button-press events get generated. > > > > > > This is easily explained: some byte of the mouse protocol was lost. > > > > Bing! > > > > That's it! This would also explain why gpm seems to work i.e. correctly > > process the events, even when X11 can't. I will take this up on the > > Xf86 lists ... > > > > > (Some mouse protocols are even designed to allow > > > easy resync/recovery by fixed bit patterns!) > > > > This mouse seems to set every fourth byte to zero, which should allow > > syncing ... > > The fourth byte is propably the wheel or 5 button support, see > http://www.microsoft.com/hwdev/input/5b_wheel.htm > to get a hint about mouse protocol variations. > > Getting resync right is not as easy as detecting zero bytes. You > should account for wild protocol variations in the world wide mouse > population, too. The new input psmouse driver can resync when bytes are lost and also shouldn't lose any bytes if there are not transmission problems on the wire. But this is 2.5 stuff. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
[EMAIL PROTECTED] wrote: > > It's been rumoured that Gunther Mayer said: > > > > > I am experiencing debilitating intermittent mouse problems & was about > > ... > > > Symptoms: > > > After a long time of flawless operation (ranging from nearly a week to > > > as little as five minutes), the X11 pointer flies up to top-right corner, > > > > > and mostly wants to stay there. Moving the mouse causes a cascade of > > > spurious button-press events get generated. > > > > This is easily explained: some byte of the mouse protocol was lost. > > Bing! > > That's it! This would also explain why gpm seems to work i.e. correctly > process the events, even when X11 can't. I will take this up on the > Xf86 lists ... > > > (Some mouse protocols are even designed to allow > > easy resync/recovery by fixed bit patterns!) > > This mouse seems to set every fourth byte to zero, which should allow > syncing ... The fourth byte is propably the wheel or 5 button support, see http://www.microsoft.com/hwdev/input/5b_wheel.htm to get a hint about mouse protocol variations. Getting resync right is not as easy as detecting zero bytes. You should account for wild protocol variations in the world wide mouse population, too. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
James Simmons wrote: > > >Where can I get your driver? > > I attach it to the other posting to this thread. I also have it in CVS at > http://linuxconsole.sourceforge.net with a bunch of other input drivers. > > >> Section "Pointer" > >> Protocol"ImPS/2" > >> Device "/dev/input/mice" > > > >What is better in using /dev/input/mice than /dev/psaux > >on this problem exactly? > > The reason to use /dev/input/mice is the PS/2 mouse driver itself has not ^^^ So you recommend to connect the mouse to USB (instead of psaux) because psaux+Xfree86 are losing bytes under circumstances (e.g. some load pattern). This is a fine solution for users with dual protocol mice, but doesn't resolve the problem for other poor ps/2 mouse owners ! > been ported over to the input suite for 2.4.X. You can use the above for > the USB mouse now. Now if you have a USB mouse plus a PS/2 mouse then > having both use /dev/psaux would require a reworking of the PS/2 driver. > I rather port over the PS/2 mouse to use /dev/input/mice. I have done this > for my CVS but since the PS/2 mouse shares the same chipset as the PS/2 > keyboard you have to use both input drivers. It would be better if XFree86 > would have a /dev/eventX driver but we would wait a long time for that to > happen :-( Even with PS/2 mouse support in the "new input" driver I wouldn't expect the psaux-byte-lost bug to disappear magically. - Gunther - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
>Where can I get your driver? I attach it to the other posting to this thread. I also have it in CVS at http://linuxconsole.sourceforge.net with a bunch of other input drivers. >> Section "Pointer" >> Protocol"ImPS/2" >> Device "/dev/input/mice" > >What is better in using /dev/input/mice than /dev/psaux >on this problem exactly? The reason to use /dev/input/mice is the PS/2 mouse driver itself has not been ported over to the input suite for 2.4.X. You can use the above for the USB mouse now. Now if you have a USB mouse plus a PS/2 mouse then having both use /dev/psaux would require a reworking of the PS/2 driver. I rather port over the PS/2 mouse to use /dev/input/mice. I have done this for my CVS but since the PS/2 mouse shares the same chipset as the PS/2 keyboard you have to use both input drivers. It would be better if XFree86 would have a /dev/eventX driver but we would wait a long time for that to happen :-( MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
>logitech trackman marble wheel.
>
>send me the driver.
Attached :-) I'm assuming you use the logitech busmouse driver. Logitech
makes many kinds of mice.
>Are you working on getting the thing incorporated
>into xf86? should I pester someone over there about it? should I assume
>that 'everything will be OK', if I wait long enough?
This is a kernel driver so it is independent of XFree86. Use the
configuration I told you about with X and it will work. Well as long as
XFree86 doesn't break its PS/2 driver.
If you have any problems setting it up let me know.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[EMAIL PROTECTED]] /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net
/*
* $Id: logibm.c,v 1.7 2000/05/29 11:19:51 vojtech Exp $
*
* Copyright (c) 1999-2000 Vojtech Pavlik
*
* Based on the work of:
* James Banks Matthew Dillon
* David GillerNathan Laredo
* Linus Torvalds Johan Myreen
* Cliff Matthews Philip Blundell
* Russell King
*
* Sponsored by SuSE
*/
/*
* Logitech Bus Mouse Driver for Linux
*/
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Should you need to contact me, the author, you can do so either by
* e-mail - mail your message to <[EMAIL PROTECTED]>, or by paper mail:
* Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic
*/
#include
#include
#include
#include
#include
#include
#include
#define LOGIBM_BASE 0x23c
#define LOGIBM_EXTENT 4
#define LOGIBM_DATA_PORTLOGIBM_BASE + 0
#define LOGIBM_SIGNATURE_PORT LOGIBM_BASE + 1
#define LOGIBM_CONTROL_PORT LOGIBM_BASE + 2
#define LOGIBM_CONFIG_PORT LOGIBM_BASE + 3
#define LOGIBM_ENABLE_IRQ 0x00
#define LOGIBM_DISABLE_IRQ 0x10
#define LOGIBM_READ_X_LOW 0x80
#define LOGIBM_READ_X_HIGH 0xa0
#define LOGIBM_READ_Y_LOW 0xc0
#define LOGIBM_READ_Y_HIGH 0xe0
#define LOGIBM_DEFAULT_MODE 0x90
#define LOGIBM_CONFIG_BYTE 0x91
#define LOGIBM_SIGNATURE_BYTE 0xa5
#define LOGIBM_IRQ 5
MODULE_PARM(logibm_irq, "i");
static int logibm_irq = LOGIBM_IRQ;
static int logibm_used = 0;
static void logibm_interrupt(int irq, void *dev_id, struct pt_regs *regs);
static int logibm_open(struct input_dev *dev)
{
if (logibm_used++)
return 0;
if (request_irq(logibm_irq, logibm_interrupt, 0, "logibm", NULL)) {
logibm_used--;
printk(KERN_ERR "logibm.c: Can't allocate irq %d\n", logibm_irq);
return -EBUSY;
}
outb(LOGIBM_ENABLE_IRQ, LOGIBM_CONTROL_PORT);
return 0;
}
static void logibm_close(struct input_dev *dev)
{
if (--logibm_used)
return;
outb(LOGIBM_DISABLE_IRQ, LOGIBM_CONTROL_PORT);
free_irq(logibm_irq, NULL);
}
static struct input_dev logibm_dev = {
evbit: { BIT(EV_KEY) | BIT(EV_REL) },
keybit: { [LONG(BTN_LEFT)] = BIT(BTN_LEFT) | BIT(BTN_MIDDLE) |
BIT(BTN_RIGHT) },
relbit: { BIT(REL_X) | BIT(REL_Y) },
open: logibm_open,
close: logibm_close,
name: "Logitech bus mouse",
idbus: BUS_ISA,
idvendor: 0x0002,
idproduct: 0x0001,
idversion: 0x0100,
};
static void logibm_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
char dx, dy;
unsigned char buttons;
outb(LOGIBM_READ_X_LOW, LOGIBM_CONTROL_PORT);
dx = (inb(LOGIBM_DATA_PORT) & 0xf);
outb(LOGIBM_READ_X_HIGH, LOGIBM_CONTROL_PORT);
dx |= (inb(LOGIBM_DATA_PORT) & 0xf) << 4;
outb(LOGIBM_READ_Y_LOW, LOGIBM_CONTROL_PORT);
dy = (inb(LOGIBM_DATA_PORT) & 0xf);
outb(LOGIBM_READ_Y_HIGH, LOGIBM_CONTROL_PORT);
buttons = inb(LOGIBM_DATA_PORT);
dy |= (bu
Re: mouse problems in 2.4.2 -> lost byte
It's been rumoured that James Simmons said: > > > >This is easily explained: some byte of the mouse protocol was lost. > >(Some mouse protocols are even designed to allow > >easy resync/recovery by fixed bit patterns!) > > > >Write an intelligent mouse driver for XFree86 to compensate for > >lost bytes. > > Or write a kernel input device driver. In fact I probable have a mouse > driver for you. What kind of mouse do you have? logitech trackman marble wheel. send me the driver. Are you working on getting the thing incorporated into xf86? should I pester someone over there about it? should I assume that 'everything will be OK', if I wait long enough? --linas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
James Simmons wrote: > > >This is easily explained: some byte of the mouse protocol was lost. > >(Some mouse protocols are even designed to allow > >easy resync/recovery by fixed bit patterns!) > > > >Write an intelligent mouse driver for XFree86 to compensate for > >lost bytes. > > Or write a kernel input device driver. In fact I probable have a mouse > driver for you. Where can I get your driver? >What kind of mouse do you have? Then set your X config to > have the following: > > Section "Pointer" > Protocol"ImPS/2" > Device "/dev/input/mice" What is better in using /dev/input/mice than /dev/psaux on this problem exactly? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
It's been rumoured that Gunther Mayer said: > > > I am experiencing debilitating intermittent mouse problems & was about > ... > > Symptoms: > > After a long time of flawless operation (ranging from nearly a week to > > as little as five minutes), the X11 pointer flies up to top-right corner, > > > and mostly wants to stay there. Moving the mouse causes a cascade of > > spurious button-press events get generated. > > This is easily explained: some byte of the mouse protocol was lost. Bing! That's it! This would also explain why gpm seems to work i.e. correctly process the events, even when X11 can't. I will take this up on the Xf86 lists ... > (Some mouse protocols are even designed to allow > easy resync/recovery by fixed bit patterns!) This mouse seems to set every fourth byte to zero, which should allow syncing ... I'm still investigating to see if the kernel buffer is overflowing ... --linas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
>This is easily explained: some byte of the mouse protocol was lost. >(Some mouse protocols are even designed to allow >easy resync/recovery by fixed bit patterns!) > >Write an intelligent mouse driver for XFree86 to compensate for >lost bytes. Or write a kernel input device driver. In fact I probable have a mouse driver for you. What kind of mouse do you have? Then set your X config to have the following: Section "Pointer" Protocol"ImPS/2" Device "/dev/input/mice" ZAxisMapping 4 5 EndSection This way you don't have to wait a few months before the bug is fixed by XFree86. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mouse problems in 2.4.2 -> lost byte
[EMAIL PROTECTED] wrote: > > I am experiencing debilitating intermittent mouse problems & was about ... > Symptoms: > After a long time of flawless operation (ranging from nearly a week to > as little as five minutes), the X11 pointer flies up to top-right corner, > and mostly wants to stay there. Moving the mouse causes a cascade of > spurious button-press events get generated. This is easily explained: some byte of the mouse protocol was lost. (Some mouse protocols are even designed to allow easy resync/recovery by fixed bit patterns!) Write an intelligent mouse driver for XFree86 to compensate for lost bytes. Regards, Gunther APPENDIX Output ot litte test program: > a.out Simulating 1 lost byte 1 -- ff 00 08 --- -256 : -248 Buttons=MRL Overflow/errors:XY 2 -- 00 04 08 --- 4 :8 Buttons=Overflow/errors: T 3 -- 00 04 08 --- 4 :8 Buttons=Overflow/errors: T 4 -- 00 03 08 --- 3 :8 Buttons=Overflow/errors: T 5 -- 00 03 18 --- 3 : 24 Buttons=Overflow/errors: T 6 -- ff 02 08 --- -254 : -248 Buttons=MRL Overflow/errors:XY 7 -- 00 02 08 --- 2 :8 Buttons=Overflow/errors: T 8 -- 00 03 18 --- 3 : 24 Buttons=Overflow/errors: T 9 -- ff 03 18 --- -253 : -232 Buttons=MRL Overflow/errors:XY 10 -- ff 03 08 --- -253 : -248 Buttons=MRL Overflow/errors:XY ... Probably XFree ignores data packets with XY overflow set. All other packets move you to top-right corner. Moving your mouse will quickly show button mania, as described by your post. gm_psauxprint.c
