NetBSD Problem Report #23931
Received: (qmail 28355 invoked by uid 605); 30 Dec 2003 14:52:50 -0000
Message-Id: <200312301452.hBUEqkwL000195@socrates.olib.org>
Date: Tue, 30 Dec 2003 08:52:46 -0600 (CST)
From: Richard Rauch <rkr@socrates.olib.org>
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: rkr@olib.org
To: gnats-bugs@gnats.netbsd.org
Subject: X (umouse?) can sometimes lose button-up events.
X-Send-Pr-Version: 3.95
>Number: 23931
>Category: xsrc
>Synopsis: X (umouse?) can sometimes lose button-up events.
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: xsrc-manager
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Dec 30 14:53:00 +0000 2003
>Closed-Date:
>Last-Modified: Thu Jun 10 06:38:14 +0000 2010
>Originator: Richard Rauch
>Release: NetBSD 1.6ZG (Nov. 10 snapshot for userland)
>Organization:
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
>Environment:
System: NetBSD socrates 1.6ZG NetBSD 1.6ZG (socrates) #0: Tue Dec 23 06:30:20 CST 2003 root@socrates:/usr/netbsd/current/src/sys/arch/amd64/compile/obj.amd64/socrates amd64
Architecture: x86_64
Machine: amd64
>Description:
I've noticed sometimes that when I let go of a window, it stays
"stuck" to my mouse-pointer. I also can observe this in
applications with, e.g., scrollbars.
I can *very* consistantly produce this error if I am moving the
mouse with any rapidity roughly when I release the button.
I can *very* consistantly avoid the problem by not moving the
mouse at the moment of release.
I've noticed it for some time, but only now have I been able to
notice that it's related to moving the mouse while releasing
the button.
I do not recall ever seeing this on NetBSD/i386, but I don't
run those machines on -current too much, so I do not know if this
is port-specific. Could be port-amd64 or kern, rather than
xsrc.
Here's a full dmesg, in case it helps:
NetBSD 1.6ZG (socrates) #0: Tue Dec 23 06:30:20 CST 2003
root@socrates:/usr/netbsd/current/src/sys/arch/amd64/compile/obj.amd64/socrates
total memory = 511 MB
avail memory = 457 MB
using 6144 buffers containing 26292 KB of memory
mainbus0 (root)
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD Athlon(tm) 64 Processor 3200+, 1994.98 MHz
cpu0: features: e7dbfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features: e7dbfbff<PGE,MCA,CMOV,PAT,PSE36,MPC,NOX,MMXX,MMX>
cpu0: features: e7dbfbff<FXSR,SSE,SSE2,LONG,3DNOW2,3DNOW>
cpu0: I-cache 64 KB 64b/line 2-way, D-cache 64 KB 64b/line 2-way
cpu0: L2 cache 1 MB 64b/line 16-way
cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully associative
cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully associative
cpu0: 16 page colors
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0
pchb0: Nvidia Corporation nForce3 Host-PCI bridge (rev. 0xa4)
pcib0 at pci0 dev 1 function 0
pcib0: Nvidia Corporation nForce3 PCI-ISA bridge (rev. 0xa6)
Nvidia Corporation nForce3 SMBus controller (SMBus serial bus, revision 0xa4) at pci0 dev 1 function 1 not configured
ohci0 at pci0 dev 2 function 0: Nvidia Corporation nForce3 USB Host Controller (rev. 0xa5)
ohci0: interrupting at irq 11
ohci0: OHCI version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Nvidia Corporat OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1 at pci0 dev 2 function 1: Nvidia Corporation nForce3 USB Host Controller (rev. 0xa5)
ohci1: interrupting at irq 11
ohci1: OHCI version 1.0, legacy support
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: Nvidia Corporat OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
Nvidia Corporation nForce3 USB2 Host Controller (USB serial bus, interface 0x20, revision 0xa2) at pci0 dev 2 function 2 not configured
auich0 at pci0 dev 6 function 0: nForce3 MCP-T AC-97 Audio
auich0: interrupting at irq 9
auich0: ac97: Avance Logic unknown (0x414c4780) codec; 20 bit DAC, 18 bit ADC, no 3D stereo
auich0: ac97: ext id 9c7<AC97_23,LDAC,SDAC,CDAC,SPDIF,DRA,VRA>
pciide0 at pci0 dev 8 function 0
pciide0: Nvidia Corporation nForce3 ATA133 IDE (rev. 0xa5)
pciide0: bus-master DMA support present, but unused (no driver support)
pciide0: primary channel configured to compatibility mode
pciide0: primary channel interrupting at irq 14
atabus0 at pciide0 channel 0
pciide0: secondary channel configured to compatibility mode
pciide0: secondary channel interrupting at irq 15
atabus1 at pciide0 channel 1
ppb0 at pci0 dev 10 function 0: Nvidia Corporation nforce3 PCI-PCI bridge (rev. 0xa2)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled
fxp0 at pci1 dev 9 function 0: i82558 Ethernet, rev 5
fxp0: interrupting at irq 10
fxp0: Ethernet address 00:03:47:72:7f:87
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rtk0 at pci1 dev 10 function 0: RealTek 8139 10/100BaseTX
rtk0: interrupting at irq 9
rtk0: Ethernet address 00:90:47:05:bc:75
ukphy0 at rtk0 phy 7: Generic IEEE 802.3u media interface
ukphy0: OUI 0x000000, model 0x0000, rev. 0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Realtek Semiconductor 8169 10/100/1000 Ethernet (ethernet network, revision 0x10) at pci1 dev 11 function 0 not configured
Integrated Technology Express, Inc. product 0x8212 (RAID mass storage, revision 0x11) at pci1 dev 12 function 0 not configured
Texas Instruments TSB43AA23 OHCI IEEE 1394 Host Controller (Firewire serial bus, interface 0x10) at pci1 dev 14 function 0 not configured
ppb1 at pci0 dev 11 function 0: Nvidia Corporation product 0x00d2 (rev. 0xa4)
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled
vga0 at pci2 dev 0 function 0: ATI Technologies Radeon 9200SE (rev. 0x01)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
pchb1 at pci0 dev 24 function 0
pchb1: Advanced Micro Devices AMD64 HyperTransport configuration (rev. 0x00)
pchb2 at pci0 dev 24 function 1
pchb2: Advanced Micro Devices AMD64 Address Map configuration (rev. 0x00)
pchb3 at pci0 dev 24 function 2
pchb3: Advanced Micro Devices AMD64 DRAM configuration (rev. 0x00)
pchb4 at pci0 dev 24 function 3
pchb4: Advanced Micro Devices AMD64 Miscellaneous configuration (rev. 0x00)
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
pckbc0 at isa0 port 0x60-0x64
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
lpt0 at isa0 port 0x378-0x37b irq 7
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
auich0: measured ac97 link rate at 15990 Hz, will use 48000 Hz
audio0 at auich0: full duplex, mmap, independent
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
Kernelized RAIDframe activated
uhub2 at uhub1 port 3
uhub2: vendor 0x04b4 USB Keyboard/Hub, class 9/1, rev 1.10/0.01, addr 2
uhidev0 at uhub0 port 3 configuration 1 interface 0uhub2: 5 ports with 4 removable, bus powered
uhidev0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1
ums0 at uhidev0: 3 buttons and Z dir.
wsmouse0 at ums0 mux 0
uhidev1 at uhub2 port 5 configuration 1 interface 0
uhidev1: vendor 0x05d5 Multimedia Hub Keyboard, rev 1.10/0.01, addr 3, iclass 3/1
ukbd0 at uhidev1
wskbd1 at ukbd0 mux 1
wd0 at atabus0 drive 0wskbd1: connecting to wsdisplay0
uhidev2 at uhub2 port 5 configuration 1 interface 1: <WDC WD400BB-75DKA0>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 38146 MB, 77504 cyl, 16 head, 63 sec, 512 bytes/sect x 78125000 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
atapibus0 at atabus1: 2 targets
uhidev2: vendor 0x05d5 Multimedia Hub Keyboard, rev 1.10/0.01, addr 3, iclass 3/1
cd0 at atapibus0 drive 1: <LG DVD-ROM DRD-8160B, , 1.01> cdrom removable
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
uhidev2: 2 report ids
uhid0 at uhidev2 reportid 1: input=2, output=0, feature=0
uhid1 at uhidev2 reportid 2: input=1, output=0, feature=0
boot device: wd0
root on wd0a dumps on wd0b
WARNING: invalid time in clock chip
WARNING: CHECK AND RESET THE DATE!
root file system type: ffs
IP Filter: v3.4.29 initialized. Default = pass all, Logging = enabled
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x50, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
>How-To-Repeat:
On my system, hold down a mouse button, and move the mouse
while releasing the mouse.
>Fix:
Dunno. I just have observed behavior at this point.
>Release-Note:
>Audit-Trail:
From: Lennart Augustsson <lennart@augustsson.net>
To: rkr@olib.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Tue, 30 Dec 2003 16:08:00 +0100
Richard Rauch wrote:
>>Number: 23931
>>Category: xsrc
>>Synopsis: X (umouse?) can sometimes lose button-up events.
Have you tried with a different mouse?
From: Michal Pasternak <michal@pasternak.w.lub.pl>
To: rkr@olib.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Tue, 30 Dec 2003 15:11:05 +0100
> I've noticed sometimes that when I let go of a window, it stays
> "stuck" to my mouse-pointer. I also can observe this in
> applications with, e.g., scrollbars.
>
> I can *very* consistantly produce this error if I am moving the
> mouse with any rapidity roughly when I release the button.
Can you check it on other OS? This can be hardware issue.
I once bought a serial mouse, that exposed the same behaviour you describe
-- no matter which platform was using it (eg. the same "button release
ignored during move" behaviour on Windows, FreeBSD on my computer and on my
PC dealer's machine). It was much cheaper, than Logitechs are, anyway.
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Tue, 30 Dec 2003 09:18:34 -0600
On Tue, Dec 30, 2003 at 04:08:00PM +0100, Lennart Augustsson wrote:
> Richard Rauch wrote:
> >>Number: 23931
> >>Category: xsrc
> >>Synopsis: X (umouse?) can sometimes lose button-up events.
>
> Have you tried with a different mouse?
The mouse was used heavily on my 1.6 i386 machine, which was recently
demoused. I never had this problem with this mouse on another system.
(But I never ran anything close to the -current that is on the
amd64.)
Just to verify that it's not the mouse, I plugged in a different USB
mouse and can reproduce the behavior.
In both cases, the mice were plugged directly into a USB port on the
system, not an external hub. On the i386, I had generally plugged
the mouse into a 2-port hub built into the keyboard that I was using.
The two mice that I have just tested on the amd64 box are: A Logitech
optical mouse (3 button + wheel) and an AOpen mechanical mouse (3 button
+ wheel). If desired, I can explicitly test with a Microsoft 5-button
+ wheel trackball, as well.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Richard Rauch <rkr@olib.org>
To: Michal Pasternak <michal@pasternak.w.lub.pl>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Tue, 30 Dec 2003 09:21:17 -0600
On Tue, Dec 30, 2003 at 03:11:05PM +0100, Michal Pasternak wrote:
> > I've noticed sometimes that when I let go of a window, it stays
> > "stuck" to my mouse-pointer. I also can observe this in
> > applications with, e.g., scrollbars.
> >
> > I can *very* consistantly produce this error if I am moving the
> > mouse with any rapidity roughly when I release the button.
>
> Can you check it on other OS? This can be hardware issue.
No, but I have checked another mouse. And this mouse was used a *lot*
on NetBSD 1.6 (not -current) on an i386 machine.
> I once bought a serial mouse, that exposed the same behaviour you describe
> -- no matter which platform was using it (eg. the same "button release
> ignored during move" behaviour on Windows, FreeBSD on my computer and on my
> PC dealer's machine). It was much cheaper, than Logitechs are, anyway.
Hm. I'll try to remember that in the future. (^&
But, in this case, I don't think that it is in the mouse.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Tue, 30 Dec 2003 13:10:35 -0600
This may be of interest. I have a laptop running -current from mid-September
(NetBSD/i386). It does *not* exhibit this problem that I can see (tested
with the same mechanical mouse with which I verified that the initial
report was not strictly dependant upon the mouse).
A full dmesg of that machine follows. I can update it to a more recent
current, though it will take a while before I have a kernel. (I'm doing
that now, but figure that it's out of date enough that I should update
"tools" first...(^& I may also need to re-instate the if_ne_pcmcia.c
hack to use its NIC. But, there was something changed in
that area recently, so I'll try a "raw" build.)
dmesg:
NetBSD 1.6ZC (odysseus) #11: Thu Sep 18 23:54:04 CDT 2003
root@odysseus:/usr/home/rkr/netbsd/current/src/sys/arch/i386/compile/obj/odysseus
total memory = 127 MB
avail memory = 112 MB
using 1658 buffers containing 6632 KB of memory
BIOS32 rev. 0 found at 0xf5e30
PCI BIOS rev. 2.1 found at 0xf603d
pcibios: config mechanism [1][x], special cycles [x][x], last bus 0
PCI IRQ Routing Table rev. 1.0 found at 0xf6620, size 224 bytes (12 entries)
PCI Interrupt Router at 000:07:0
pciintr_link_init: bus 0 device 7 link 0x60: bad irq bitmap 0xdef8, should be 0x0400
pciintr_link_init: bus 0 device 7 link 0x61: bad irq bitmap 0xdef8, should be 0x0400
------------------------------------------
device vendor product pin PIRQ IRQ stage
------------------------------------------
000:02:0 0x10c8 0x0004 A 0x00 10 0 already assigned
000:07:2 0x8086 0x7112 D 0x03 10 0 already assigned
000:10:0 0x104c 0xac17 A 0x00 10 0 fixed up
000:10:1 0x104c 0xac17 B 0x01 10 0 fixed up
------------------------------------------
PCI fixup examining 8086:7100
PCI fixup examining 10c8:04
PCI fixup examining 8086:7110
PCI fixup examining 8086:7111
PCI fixup examining 8086:7112
PCI fixup examining 8086:7113
PCI fixup examining 104c:ac17
PCI bridge 0: primary 0, secondary 1, subordinate 1
PCI fixup examining 104c:ac17
PCI bridge 1: primary 0, secondary 2, subordinate 2
PCI bus #2 is the last bus
[System BIOS Setting]-----------------------
device vendor product
register space address size
--------------------------------------------
000:00:0 0x8086 0x7100
[OK]
000:02:0 0x10c8 0x0004
10h mem 0xfd000000 0x01000000
14h mem 0xfea00000 0x00200000
18h mem 0xfed00000 0x00100000
[OK]
000:07:0 0x8086 0x7110
[OK]
000:07:1 0x8086 0x7111
20h port 0x0000fcd0 0x00000010
[OK]
000:07:2 0x8086 0x7112
20h port 0x0000fce0 0x00000020
[OK]
000:07:3 0x8086 0x7113
[OK]
000:10:0 0x104c 0xac17
10h mem 0x00000000 0x00001000
[NG]
000:10:1 0x104c 0xac17
10h mem 0x00000000 0x00001000
[NG]
--------------------------[ 2 devices bogus]
Physical memory end: 0x07ff7000
PCI memory mapped I/O space start: 0x08000000
[PCIBIOS fixup stage]-----------------------
device vendor product
register space address size
--------------------------------------------
000:00:0 0x8086 0x7100
[OK]
000:02:0 0x10c8 0x0004
10h mem 0xfd000000 0x01000000
14h mem 0xfea00000 0x00200000
18h mem 0xfed00000 0x00100000
[OK]
000:07:0 0x8086 0x7110
[OK]
000:07:1 0x8086 0x7111
20h port 0x0000fcd0 0x00000010
[OK]
000:07:2 0x8086 0x7112
20h port 0x0000fce0 0x00000020
[OK]
000:07:3 0x8086 0x7113
[OK]
000:10:0 0x104c 0xac17
10h mem 0x08000000 0x00001000
[OK]
000:10:1 0x104c 0xac17
10h mem 0x08001000 0x00001000
[OK]
--------------------------[ 0 devices bogus]
mainbus0 (root)
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel Pentium/MMX (Tillamook) (586-class), 233.88 MHz, id 0x581
cpu0: features 8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8>
cpu0: features 8001bf<MMX>
pnpbios0 at mainbus0: nodes 18, max len 118
wss0 at pnpbios0 index 3 (NMX2210)
wss0: io 220-22f 530-537 388-38f 330-331 370-371, irq 11, DMA 0 1
wss0: CS4231
audio0 at wss0: full duplex, mmap
opl0 at wss0: model OPL3
midi0 at opl0: WSS Yamaha OPL3
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0
pchb0: Intel 82439TX System Controller (MTXC) (rev. 0x01)
vga1 at pci0 dev 2 function 0: Neomagic MagicGraph 128XD (rev. 0x01)
wsdisplay0 at vga1 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
pcib0 at pci0 dev 7 function 0
pcib0: Intel 82371AB PCI-to-ISA Bridge (PIIX4) (rev. 0x02)
pciide0 at pci0 dev 7 function 1: Intel 82371AB IDE controller (PIIX4) (rev. 0x01)
pciide0: bus-master DMA support present
pciide0: primary channel wired to compatibility mode
wd0 at pciide0 channel 0 drive 0: <HITACHI_DK227A-41>
wd0: drive supports 16-sector PIO transfers, LBA addressing
wd0: 3909 MB, 7944 cyl, 16 head, 63 sec, 512 bytes/sect x 8007552 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
pciide0: primary channel interrupting at irq 14
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA data transfers)
pciide0: secondary channel wired to compatibility mode
atapibus0 at pciide0 channel 1: 2 targets
cd0 at atapibus0 drive 0: <UJDA110, , 1.21> cdrom removable
cd0: 32-bit data port
cd0: drive supports PIO mode 4, DMA mode 1
pciide0: secondary channel interrupting at irq 15
cd0(pciide0:1:0): using PIO mode 0, DMA mode 1 (using DMA data transfers)
uhci0 at pci0 dev 7 function 2: Intel 82371AB USB Host Controller (PIIX4) (rev. 0x01)
uhci0: interrupting at irq 10
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
Intel 82371AB Power Management Controller (PIIX4) (miscellaneous bridge, revision 0x02) at pci0 dev 7 function 3 not configured
cbb0 at pci0 dev 10 function 0: Texas Instruments PCI1220 PCI-CardBus Bridge (rev. 0x02)
cbb1 at pci0 dev 10 function 1: Texas Instruments PCI1220 PCI-CardBus Bridge (rev. 0x02)
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
pckbc0 at isa0 port 0x60-0x64
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
lpt0 at isa0 port 0x378-0x37b irq 7
sb0 at isa0 port 0x220-0x237 irq 5 drq 1: dsp v3.01
audio1 at sb0: half duplex, mmap, independent
midi1 at sb0: SB MIDI UART
opl1 at sb0: model OPL3
midi2 at opl1: SB Yamaha OPL3
pas: can't map base register 388 in probe
pcppi0 at isa0 port 0x61
midi3 at pcppi0: PC speaker
sysbeep0 at pcppi0
isapnp0 at isa0 port 0x279: ISA Plug 'n Play device support
npx0 at isa0 port 0xf0-0xff: using exception 16
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
isapnp0: no ISA Plug 'n Play devices found
cbb0: interrupting at irq 10
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 1 device 0
pcmcia0 at cardslot0
cbb1: interrupting at irq 10
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 2 device 0
pcmcia1 at cardslot1
apm0 at mainbus0: Power Management spec V1.2
raidattach: Asked for 8 units
Kernelized RAIDframe activated
ne0 at pcmcia0 function 0
ne0: LAN iobase 0x300 (0x4300) -> 0x300
ne0: Melco LPC3-TX (AX88190) Ethernet
ne0: Ethernet address 00:02:dd:77:2b:1d
ukphy0 at ne0 phy 1: Generic IEEE 802.3u media interface
ukphy0: OUI 0x0008bb, model 0x0002, rev. 1
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
uhidev0 at uhub0 port 2 configuration 1 interface 0
uhidev0: vendor 0x1241 product 0x1122, rev 1.00/1.00, addr 2, iclass 3/1
ums0 at uhidev0: 5 buttons and Z dir.
wsmouse1 at ums0 mux 0
Searching for RAID components...
boot device: wd0
root on wd0a dumps on wd0b
mountroot: trying coda...
mountroot: trying msdos...
mountroot: trying cd9660...
mountroot: trying ntfs...
mountroot: trying nfs...
mountroot: trying lfs...
mountroot: trying ext2fs...
mountroot: trying ffs...
root file system type: ffs
init: copying out path `/sbin/init' 11
ne0: LAN iobase 0x300 (0x4300) -> 0x300
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x25, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: kpneal@pobox.com
To: rkr@olib.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Tue, 30 Dec 2003 14:35:08 -0500
On Tue, Dec 30, 2003 at 08:52:46AM -0600, Richard Rauch wrote:
>
> >Number: 23931
> >Category: xsrc
> >Synopsis: X (umouse?) can sometimes lose button-up events.
I *hate* that.
I thought it was my mouse, since when I switched X servers I switched
mice as well. Huh.
> Architecture: x86_64
> Machine: amd64
I'm seeing this on NetBSD/alpha 1.6 with XFree86 4.3.
> >Description:
> I've noticed sometimes that when I let go of a window, it stays
> "stuck" to my mouse-pointer. I also can observe this in
> applications with, e.g., scrollbars.
>
> I can *very* consistantly produce this error if I am moving the
> mouse with any rapidity roughly when I release the button.
>
> I can *very* consistantly avoid the problem by not moving the
> mouse at the moment of release.
>
> I've noticed it for some time, but only now have I been able to
> notice that it's related to moving the mouse while releasing
> the button.
>
> I do not recall ever seeing this on NetBSD/i386, but I don't
> run those machines on -current too much, so I do not know if this
> is port-specific. Could be port-amd64 or kern, rather than
> xsrc.
I don't run -current on my box, and I don't have an amd64 box.
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 1.6 (TOME-$Revision: 1.2 $) #59: Tue Nov 18 18:15:52 EST 2003
kpn@rune.int.neutralgood.org:/local/kernel/compile/TOME
AlphaStation 200 4/233, 233MHz, s/n
8192 byte page size, 1 processor.
total memory = 160 MB
(2000 KB reserved for PROM, 158 MB used by NetBSD)
avail memory = 143 MB
using 1024 buffers containing 8192 KB of memory
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064A-0
cpu0: Architecture extensions: 6<CIX,FIX>
apecs0 at mainbus0: DECchip 21071 Core Logic chipset
apecs0: DC21071-CA pass 2, 64-bit memory bus
apecs0: DC21071-DA pass 2
pci0 at apecs0 bus 0
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)
siop0: interrupting at isa irq 11
scsibus0 at siop0: 8 targets, 8 luns per target
sio0 at pci0 dev 7 function 0: Intel 82378ZB System I/O (SIO) (rev. 0x43)
tlp0 at pci0 dev 11 function 0: DECchip 21040 Ethernet, pass 2.4
tlp0: interrupting at isa irq 5
tlp0: Ethernet address 00:00:f8:23:5c:7b
tlp0: 10baseT, 10baseT-FDX, 10base5, manual
tlp1 at pci0 dev 12 function 0: DECchip 21143 Ethernet, pass 3.0
tlp1: interrupting at isa irq 10
tlp1: DEC DE500-BA, Ethernet address 08:00:2b:c5:11:02
tlp1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vga0 at pci0 dev 13 function 0: Texas Instruments TVP4020 Permedia 2 (rev. 0x01)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
isa0 at sio0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
pckbc0 at isa0 port 0x60-0x64
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
lpt0 at isa0 port 0x3bc-0x3bf irq 7
wss0 at isa0 port 0x530-0x537 irq 9 drq 0: CS4231A
audio0 at wss0: half duplex, mmap
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
isabeep0 at pcppi0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
mcclock0 at isa0 port 0x70-0x71: mc146818 or compatible
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 1 lun 0: <SEAGATE, ST39173N, 6244> SCSI2 0/direct fixed
sd0: 8683 MB, 7501 cyl, 10 head, 237 sec, 512 bytes/sect x 17783240 sectors
sd0: sync (100.0ns offset 8), 8-bit (10.000MB/s) transfers, tagged queueing
sd1 at scsibus0 target 3 lun 0: <SEAGATE, ST15230W SUN4.2G, 0738> SCSI2 0/direct fixed
sd1: 4095 MB, 3992 cyl, 19 head, 110 sec, 512 bytes/sect x 8386733 sectors
sd1: sync (100.0ns offset 8), 8-bit (10.000MB/s) transfers, tagged queueing
cd0 at scsibus0 target 5 lun 0: <DEC, RRD43 (C) DEC, 1084> SCSI2 5/cdrom removable
cd0: async, 8-bit transfers
root on sd1a dumps on sd1b
root file system type: ffs
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x25, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
wsdisplay0: screen 5 added (80x25, vt100 emulation)
wsdisplay0: screen 6 added (80x25, vt100 emulation)
Accounting started
--
Kevin P. Neal http://www.pobox.com/~kpn/
"Not even the dumbest terrorist would choose an encryption program that
allowed the U.S. government to hold the key." -- (Fortune magazine
is smarter than the US government, Oct 29 2001, page 196.)
From: Richard Rauch <rkr@olib.org>
To: kpneal@pobox.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Tue, 30 Dec 2003 14:05:03 -0600
On Tue, Dec 30, 2003 at 02:35:08PM -0500, kpneal@pobox.com wrote:
> On Tue, Dec 30, 2003 at 08:52:46AM -0600, Richard Rauch wrote:
> >
> > >Number: 23931
> > >Category: xsrc
> > >Synopsis: X (umouse?) can sometimes lose button-up events.
>
> I *hate* that.
>
> I thought it was my mouse, since when I switched X servers I switched
> mice as well. Huh.
>
> > Architecture: x86_64
> > Machine: amd64
>
> I'm seeing this on NetBSD/alpha 1.6 with XFree86 4.3.
Hm. Well, my problem is almost certainly not my mouse, since I've tried
swapping mice around.
However, someone else has said he had exactly the same problem and that
in his case it was a mouse.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Tue, 30 Dec 2003 19:33:05 -0600
Well, I finished building a -current kernel (sources from CVS a few days
ago). (In fact, the same source tree as I used to build my AMD64
kernel. The AMD64 can't use DMA and the laptop is just slow, so I serve
both from a shared NFS tree.)
The i386 laptop build does *not* seem to lose button-up events.
The caveat is that the laptop's userland is relatively old. In particular,
xsrc is old, so this doesn't help a whole lot. (But it is running
XFree86 4.3.0, the same as the AMD64.)
If you have a favorite snapshot ISO for i386 to suggest that I download
and install, I can do that on the laptop. (The laptop has nothing of value
on it. Right now, its purpose in life is to be an i386 guinea-pig.)
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Lennart Augustsson <lennart@augustsson.net>
To: Richard Rauch <rkr@olib.org>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Wed, 31 Dec 2003 11:15:52 +0100
I'll write a small utility that opens /dev/wsmouse and counts mouse
events. Together with a small patch for the kernel driver to count
events we should be able to determine where the mouse-up is lost.
-- Lennart
Richard Rauch wrote:
> Well, I finished building a -current kernel (sources from CVS a few days
> ago). (In fact, the same source tree as I used to build my AMD64
> kernel. The AMD64 can't use DMA and the laptop is just slow, so I serve
> both from a shared NFS tree.)
>
> The i386 laptop build does *not* seem to lose button-up events.
>
> The caveat is that the laptop's userland is relatively old. In particular,
> xsrc is old, so this doesn't help a whole lot. (But it is running
> XFree86 4.3.0, the same as the AMD64.)
>
>
> If you have a favorite snapshot ISO for i386 to suggest that I download
> and install, I can do that on the laptop. (The laptop has nothing of value
> on it. Right now, its purpose in life is to be an i386 guinea-pig.)
>
>
From: Lennart Augustsson <lennart@augustsson.net>
To: Richard Rauch <rkr@olib.org>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Wed, 31 Dec 2003 12:04:52 +0100
This is a multi-part message in MIME format.
--------------030409040304010009020702
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Richard Rauch wrote:
> Well, I finished building a -current kernel (sources from CVS a few days
> ago). (In fact, the same source tree as I used to build my AMD64
> kernel. The AMD64 can't use DMA and the laptop is just slow, so I serve
> both from a shared NFS tree.)
>
> The i386 laptop build does *not* seem to lose button-up events.
>
> The caveat is that the laptop's userland is relatively old. In particular,
> xsrc is old, so this doesn't help a whole lot. (But it is running
> XFree86 4.3.0, the same as the AMD64.)
>
>
> If you have a favorite snapshot ISO for i386 to suggest that I download
> and install, I can do that on the laptop. (The laptop has nothing of value
> on it. Right now, its purpose in life is to be an i386 guinea-pig.)
>
>
Can you try this patch for the kernel driver? It should start printing
messages if the down-up>1.
-- Lennart
--------------030409040304010009020702
Content-Type: text/plain;
name="ums.c.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ums.c.diff"
Index: ums.c
===================================================================
RCS file: /cvsroot/src/sys/dev/usb/ums.c,v
retrieving revision 1.60
diff -c -r1.60 ums.c
*** ums.c 11 Mar 2003 16:44:00 -0000 1.60
--- ums.c 31 Dec 2003 11:00:30 -0000
***************
*** 301,306 ****
--- 301,335 ----
if (hid_get_data(ibuf, &sc->sc_loc_btn[i]))
buttons |= (1 << UMS_BUT(i));
+ if (buttons != sc->sc_buttons) {
+ static int up0, up1, up2, dn0, dn1, dn2;
+ u_int32_t d = buttons ^ sc->sc_buttons;
+ if (d & 1) {
+ if (buttons & 1)
+ up0++;
+ else
+ dn0++;
+ }
+ if (d & 2) {
+ if (buttons & 2)
+ up1++;
+ else
+ dn1++;
+ }
+ if (d & 4) {
+ if (buttons & 4)
+ up2++;
+ else
+ dn2++;
+ }
+ if (dn0 - up0 > 1)
+ printf("dn0=%d up0=%d\n", dn0, up0);
+ if (dn1 - up1 > 1)
+ printf("dn1=%d up1=%d\n", dn1, up1);
+ if (dn2 - up2 > 1)
+ printf("dn2=%d up2=%d\n", dn2, up2);
+ }
+
if (dx != 0 || dy != 0 || dz != 0 || buttons != sc->sc_buttons) {
DPRINTFN(10, ("ums_intr: x:%d y:%d z:%d buttons:0x%x\n",
dx, dy, dz, buttons));
--------------030409040304010009020702--
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: rkr@olib.org
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Wed, 31 Dec 2003 14:51:07 +0100
On Tue, Dec 30, 2003 at 08:52:46AM -0600, Richard Rauch wrote:
> [...]
> I do not recall ever seeing this on NetBSD/i386, but I don't
> run those machines on -current too much, so I do not know if this
> is port-specific. Could be port-amd64 or kern, rather than
> xsrc.
I don't think it's port-specific. I noticed it on NetBSD/alpha 1.6.x too
(running XFree4)
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 23 ans d'experience feront toujours la difference
--
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Wed, 31 Dec 2003 13:50:12 -0600
On Wed, Dec 31, 2003 at 12:04:52PM +0100, Lennart Augustsson wrote:
[...]
> Can you try this patch for the kernel driver? It should start printing
> messages if the down-up>1.
In a few hours, I should get back to you. (I was late getting the email,
and still have some other things to do, but the kernel has been built.)
In your timezone, you may already be gone until tomorrow, but I should have
news for you by the time you get back in. (^&
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Wed, 31 Dec 2003 15:45:31 -0600
On Wed, Dec 31, 2003 at 12:04:52PM +0100, Lennart Augustsson wrote:
[...]
> Can you try this patch for the kernel driver? It should start printing
> messages if the down-up>1.
[...]
No messages appeared on the xconsole, in dmesg, or in /var/log/messages.
The window still stuck to the mouse. (^& I tried a few times, so
if it was getting lost in ums or before, it should definitely have
shown up.
I also tried using /dev/wsmouse0 instead of /dev/wsmouse to rule out
wsmux being involved. The mouse was still "sticky".
So, I guess that it's down to wsmouse, the X server (I had a peek,
but wasn't sure where in the X sources mouse input is read), or
somehow button-up events are being conditionally postponed until
a button-down comes through.
Another datapoint: It looks like spinning the mouse-wheel while
moving the mouse causes X to not see the "up" half of the wheel
event. (As you are probably well aware, XFree86 translates wheel
events into button-pairs.) I am not 100% certain on that point,
but ticking the wheel while moving the mouse rapidly seems to result
in some damaged state information for the wheel. X recovers after
a regular button is pressed.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Lennart Augustsson <lennart@augustsson.net>
To: Richard Rauch <rkr@olib.org>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Thu, 01 Jan 2004 12:04:03 +0100
This is a multi-part message in MIME format.
--------------020902090405060502030207
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Attached is a small program that reads wsmouse events and checks for
lost up events. Run it outside X with `a.out < /dev/wsmouse'
-- Lennart
Richard Rauch wrote:
> On Wed, Dec 31, 2003 at 12:04:52PM +0100, Lennart Augustsson wrote:
> [...]
>
>>Can you try this patch for the kernel driver? It should start printing
>>messages if the down-up>1.
>
> [...]
>
> No messages appeared on the xconsole, in dmesg, or in /var/log/messages.
> The window still stuck to the mouse. (^& I tried a few times, so
> if it was getting lost in ums or before, it should definitely have
> shown up.
>
> I also tried using /dev/wsmouse0 instead of /dev/wsmouse to rule out
> wsmux being involved. The mouse was still "sticky".
>
> So, I guess that it's down to wsmouse, the X server (I had a peek,
> but wasn't sure where in the X sources mouse input is read), or
> somehow button-up events are being conditionally postponed until
> a button-down comes through.
>
>
> Another datapoint: It looks like spinning the mouse-wheel while
> moving the mouse causes X to not see the "up" half of the wheel
> event. (As you are probably well aware, XFree86 translates wheel
> events into button-pairs.) I am not 100% certain on that point,
> but ticking the wheel while moving the mouse rapidly seems to result
> in some damaged state information for the wheel. X recovers after
> a regular button is pressed.
>
>
--------------020902090405060502030207
Content-Type: text/plain;
name="ws.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ws.c"
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>
#include <dev/wscons/wsconsio.h>
#define N 10
int
main(int argc, char **argv)
{
struct wscons_event ev;
int i;
int ups[N], dns[N];
for (i = 0; i < N; i++)
ups[i] = dns[i] = 0;
for (;;) {
if (read(0, &ev, sizeof ev) != sizeof ev)
abort();
switch (ev.type) {
case WSCONS_EVENT_MOUSE_UP:
/*printf("u"); fflush(stdout);*/
ups[ev.value]++;
break;
case WSCONS_EVENT_MOUSE_DOWN:
/*printf("d"); fflush(stdout);*/
dns[ev.value]++;
break;
default:
break;
}
for (i = 0; i < N; i++) {
if (dns[i] - ups[i] > 1)
printf("button %d up lost\n", i);
}
}
}
--------------020902090405060502030207--
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Thu, 1 Jan 2004 09:44:11 -0600
On Thu, Jan 01, 2004 at 12:04:03PM +0100, Lennart Augustsson wrote:
> Attached is a small program that reads wsmouse events and checks for
> lost up events. Run it outside X with `a.out < /dev/wsmouse'
No button up events seemed to be lost.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Lennart Augustsson <lennart@augustsson.net>
To: Richard Rauch <rkr@olib.org>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Thu, 01 Jan 2004 16:50:12 +0100
Richard Rauch wrote:
> On Thu, Jan 01, 2004 at 12:04:03PM +0100, Lennart Augustsson wrote:
>
>>Attached is a small program that reads wsmouse events and checks for
>>lost up events. Run it outside X with `a.out < /dev/wsmouse'
>
>
> No button up events seemed to be lost.
Then I blame X. Are you using different settings for X on the
working and non-working machine? Maybe Emulate3Buttons?
-- Lennart
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Thu, 1 Jan 2004 10:16:19 -0600
On Thu, Jan 01, 2004 at 04:50:12PM +0100, Lennart Augustsson wrote:
> Richard Rauch wrote:
> >On Thu, Jan 01, 2004 at 12:04:03PM +0100, Lennart Augustsson wrote:
> >
> >>Attached is a small program that reads wsmouse events and checks for
> >>lost up events. Run it outside X with `a.out < /dev/wsmouse'
> >
> >
> >No button up events seemed to be lost.
>
> Then I blame X. Are you using different settings for X on the
> working and non-working machine? Maybe Emulate3Buttons?
Not Emulate3Buttons.
Because I use a 5-button trackball with the i386 laptop, I have
Buttons == 7 on that machine.
The AMD64 doesn't use XFree86 modules, it looks like. (I didn't
manually diddle the file much aside from selecting the "vesa"
sub-driver for the ATI card in the AMD. Since XFree86 4.x went
into NetBSD, I've tended to install a system and let X autoconfigure
most stuff. And I don't do 2-button mice. (^&)
If you like, I can include diff's between the i386 laptop and the
AMD64, and also between the laptop and the (1.6) i386 Athlon.
(The AMD64 is the only one of the three that is giving me trouble.)
Another random point that may be related: xmms has a tendancy to die
with a failed assertion in pthreads. I haven't sat down to explicitly
try to reproduce it, yet, but it *seems* to happen when the system is
put under (even relatively mild) stress. Perhaps the effort of having
X track the mouse events is triggering some lossage in ums/wsmouse?
Or if X is using threads..?
I tried taking your program and having it write() to stdout what it
read from stdin, and redirected the messags to stderr. I sent the
tdout to a fifo, and told X to read that fifo for mouse events.
(stderr went to a log file.)
That didn't work, however. I assume that X is doing some kind of
device-type operations in addition to opening-and-reading. (X
would start, but the mouse didn't move. Doing an "od" of the
fifo would produce the mouse event stream, though.) Then again,
I may have just done something stupid that made it not work.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
From: Richard Rauch <rkr@olib.org>
To: Lennart Augustsson <lennart@augustsson.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/23931: X (umouse?) can sometimes lose button-up events.
Date: Thu, 8 Jan 2004 10:20:09 -0600
I haven't spent much time thinking about this for the past week,
since it seems likely to be in X and I haven't wandered into the
X source tree to play with this.
However, I was taking a random poke at pkgsrc on the AMD64 this
morning, and after patching xdoom to build, I noticed:
I do not seem able to make the mouse lose its button up event
when in the xdoom window.
This seems to back up the theory that it is in fact X.
(xdoom is another issue for another PR, though. (^&)
(Lennart, if you don't want to see this thread anymore, now
that USB no longer seems to be involved, let me know. But
replying on the thread seemed the easiest way to attach a note
to the PR. (^&)
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
State-Changed-From-To: open->feedback
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Wed, 02 Jun 2010 04:11:49 +0000
State-Changed-Why:
is this a problem with modern X on amd64?
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Thu, 10 Jun 2010 06:37:53 +0000
State-Changed-Why:
I can replicate the problem pretty readily by clicking and dragging
with the right mouse over a loaded page in seamonkey; the popup menu
remains posted. This is with pms(4), not a usb mouse, and the machine
I'm on at the moment is using pkgsrc X but I've seen it with native X
also. I always assumed it was a gtk bug.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home