[debian etch] scrollwheel werkt niet met KVM

[MisterE]

ik gebruik een logitech mx310 op een newstar ns-411k kvm switch.
Bij opstarten werkt gewoon alles, maar na terugschakelen werkt het wieltje niet meer. De rest werkt nog gewoon prima.

Ik ben uitgegaan van het volgende:
http://gentoo-wiki.com/HO...Individual_Configurations

Mijn huidige settings zijn nu:

Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "Protocol" "ExplorerPS/2"
#Option "Protocol" "ImPS/2"
#Option "Device" "/dev/input/mice"
Option "Device" "/dev/psaux"
Option "Buttons" "7"
Option "Emulate3Buttons" "false"
Option "ZAxisMapping" "4 5"
Option "ButtonMapping" "1 2 3 6 7"
EndSection

Ik vond nog wat nuttige draadjes maar geen oplossingen:
http://forums1.itrc.hp.co...45+1178524854847+28353475
http://www.linuxquestions...?postid=778557#post778557

Mijn usb muis zit met een verloopstekker (naar ps/2) in de KVM switch. Vanaf de switch zit die direct in het PS/2 gat. Ik heb ook geproberd met een adaptertje die weer terug om te zetten naar USB. Maar dan doet de hele muis het niet...

Ik las ergens dat linux terug schakelt naar een standaard "ps/2" muis na het schakelen. En dat sommige het beschouwen als een kernel bug (die al lang bekend is).
Heeft iemand een oplossing?
(Onder suse werkte het allemaal wel goed, maar dit zal wel de 2.4 kernel geweest zijn)

[deadinspace]

PS/2 is officieel helemaal niet hot-pluggable, en sommige moederborden/BIOSsen gaan daar dan ook niet goed mee om. Dat zou ook nog de oorzaak van dit verschijnsel kunnen zijn.

Kun je na het switchen eens 'dmesg' runnen in een console, en de laatste 10 a 20 regels posten?

Wat je ook kan proberen is in je Xorg config /dev/input/mice gebruiken ipv /dev/psaux, en dan na het switchen de psmouse module te unloaden en opnieuw te laden. Niet ideaal misschien, maar als het werkt dan is het iig iets.

[MisterE]

Dit was na een herstart -> schakelen naar andere pc -> terug naar linux -> muis weg
Het gekke is dat ik ook een tijdje heb gehad dat de scrollwheel blijft werken, hoewel ie wel raar doet met omhoog scrollen.
u

i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
input: PC Speaker as /class/input/input1
Real Time Clock Driver v1.12ac
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 22 (level, low) -> IRQ 225
PCI: Setting latency timer of device 0000:00:04.0 to 64
input: PS2++ Logitech MX Mouse as /class/input/input2
ts: Compaq touchscreen protocol output
intel8x0_measure_ac97_clock: measured 58685 usecs
intel8x0: clocking to 46948
Adding 2650684k swap on /dev/sda5. Priority:-1 extents:1 across:2650684k
EXT3 FS on sda2, internal journal
loop: loaded (max 8 devices)
device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: [e-mail]
eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
lp0: using parport0 (interrupt-driven).
ppdev: user-space parallel port driver
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
eth0: no link during initialization.
ADDRCONF(NETDEV_UP): eth0: link is not ready
Linux agpgart interface v0.101 (c) Dave Jones
nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 66
PCI: Setting latency timer of device 0000:01:00.0 to 64
NVRM: loading NVIDIA UNIX x86 Kernel Module 1.0-9755 Mon Feb 26 23:21:15 PST 2007
eth1: no IPv6 routers present

[deadinspace]

Zet in je Xorg.conf het protocol eens terug op ImPS/2, en het device op /dev/input/mice. (dit heeft een Xorg restart nodig om effect te hebben)

Doe dan eens in een console, als root:

code:

cat /dev/input/mice

Als het goed is komen daar allemaal rare tekens uit als je je muis beweegt, en gebeurt er ook iets als je je scrollwheel gebruikt. Je kan dit afbreken met Ctrl-C.

Switch dan eens met je KVM naar de andere computer en terug, zodat je scrollwheel niet meer werkt. cat dan nogmaals /dev/input/mice, en kijk of je scrollwheel nog iets produceert.

Herlaad dan de PS/2 mouse driver (als root) met:

code:

rmmod psmouse; modprobe psmouse

En kijk of hierna je scrollwheel weer werkt (zowel met cat /dev/input/mice, als gewoon).

[MisterE]

Switch dan eens met je KVM naar de andere computer en terug, zodat je scrollwheel niet meer werkt. cat dan nogmaals /dev/input/mice, en kijk of je scrollwheel nog iets produceert.

Na het schakelen zie ik niets meer veranderen als ik het scrollwheel gebruik

Herlaad dan de PS/2 mouse driver (als root) met:

code:

rmmod psmouse; modprobe psmouse

En kijk of hierna je scrollwheel weer werkt (zowel met cat /dev/input/mice, als gewoon).

Hierna doet ie het wel weer. Maar is er een oplossing voor? Kan ik mij als gewone gebruik machtigen om eventueel die modprobe te runnen? Maar het liefst heb ik een "nette" oplossing. Immers, oudere debian's en suse hebben gewoon goed gewerkt.

[Jungian]

sudo installeren en dan

visudo

Daarna deze lijn toevoegen :

code:

user ALL=(root) NOPASSWD: /sbin/modprobe

Zou perfect moeten werken, als ik er niet compleet naastzit (user is in dit geval je username).

Bash alias (toevoegen in .bash_aliases in je home-map bijvoorbeeld) :

alias ls='modprobe -r psmouse && modprobe psmouse'

[ Voor 52% gewijzigd door Jungian op 14-05-2007 23:14 . Reden: bash alias + uitleg wat user in deze context is + verwijdering overbodige rmmod ]

[deadinspace]

MisterE schreef op maandag 14 mei 2007 @ 22:49:
Hierna doet ie het wel weer.

Ok, mooi, da's al iets!

Zou je eens

code:

rmmod psmouse; modprobe psmouse resetafter=1

kunnen doen, en daarna kijken of na switchen de scrollwheel het nog doet?

Als dat niet werkt, dan mag je in plaats van resetafter=1 de volgende opties (een voor een) proberen:

• resync_time=1
• proto=imps
• proto=exps
• proto=any

Mocht dat allemaal niet werken, dan kun je ook nog een aantal van die parameters samen gaan proberen. Hopelijk werkt een van deze dingen

[deadinspace]

Jungian schreef op maandag 14 mei 2007 @ 23:03:
Bash alias (toevoegen in .bash_aliases in je home-map bijvoorbeeld) :

alias ls='modprobe -r psmouse && modprobe psmouse'

Zodat hij geen 'ls' meer kan doen? Handig

Daarnaast, zelfs al neem je ls op in het alias, erg charmant vind ik dat niet... Dan nog liever periodiek met cron ofzo

[MisterE]

ik zal het vanavond eens proberen, alvast bedankt voor alle hulp:
Maar:
A: is het een kernelprobleem? Of van een andere laag?
B: Is het bekend bij de kerneldevelopers?
C: Word er aan gewerkt?

Natuurlijk valt er wat te zeggen of dat ps/2 niet hot-pluggable is maar als dit een bekend probleem is met kvm switches dan moet daar vast een oplossing voor zijn.
Daarbij ga ik ervan uit dat de pc niet weet dat hij de muis kwijtraakt.

[deadinspace]

Een heldere uitleg voor wat waarschijnlijk het probleem is staat hier. Het belangrijkste stuk heb ik hier gequoot:

The root cause for this erratic behavior with the mouse rests in the fact that the PS/2 specification was not designed to be hot-pluggable. So, why is this a problem? Read on.

All PS/2 mice can work in what we will call "Basic PS/2 Mouse Mode" — no scroll wheel and only 2 or three buttons work. This is the default mode when the mouse initially gets power. To activate the scroll wheel and/or any extra buttons, the mouse must receive a special reset code. This switches the mouse to "Advanced Mouse Mode" and changes the mouse data protocol a little.

Many KVM switches may stop feeding power to the mouse when switching from one system to another. This causes the mouse to reset to "Basic PS/2 Mouse Mode". The system has no way of detecting that the mouse was reverted back to the basic mode. If the system was in a state where it had detected the mouse with "Advanced" capabilities and had sent it the appropriate reset code, it will expect the mouse to still be in "Advanced" mode and will misinterpret the mouse data (remember the mouse data protocol is different between Advanced and Basic mouse mode).

Het artikel gaat voornamelijk over muizen die raar doen (cursor schiet alle kanten op bv) na een KVM switch. Dat komt dus doordat de muis in protocol bla gezet wordt, en Linux verwacht dan ook dat de muis bla praat. Als door een kvm switch de muis gereset wordt, dan praat hij weer PS/2, maar Linux interpreteert het gebrabbel van de muis nog steeds als protocol bla, wat dat rare gedrag tot gevolg heeft.

In jouw geval lijkt het erop dat de muis op het ImPS/2 protocol gezet wordt (dat is inclusief scrollwheel), en na een kvm switch weer terugvalt naar PS/2 (zonder scrollwheel). Linux verwacht nog steeds ImPS/2 van de muis, maar als al het PS/2 gepraat van de muis ook geldige ImPS/2 is (en dat ligt voor de hand, als ImPS/2 een uitbreiding van PS/2 is), dan doet de muis niks raars, alleen het scrollwheel werkt niet meer (omdat de muis daar geen signalen meer voor stuurt).

Met een beetje mazzel is de psmouse driver met de juiste argumenten te overtuigen dat hij op de het juiste moment de muis moet resetten om hem zo weer naar ImPS/2 te helpen.

En om je vraag te beantwoorden: het is dus eigenlijk een hardware probleem (de niet-hotpluggability van PS/2 gecombineerd met het feit dat je KVM switch waarschijnlijk de muis heel even stroomloos laat).

[Jungian]

deadinspace schreef op dinsdag 15 mei 2007 @ 01:10:
[...]

Zodat hij geen 'ls' meer kan doen? Handig

Mja ik was nog met andere dingen bezig. Je kunt er ook stoephoer, muisfix, kutding, kutalias, aliasmuis, stoephoermuisfixkutdingkutalias van maken (etc.). Waarom je in godsnaam cron zou willen gebruiken in dit geval is me echt een raadsel. Krijg je om de zoveel tijd dat je muis uitflikkert als je ermee werkt.

[MisterE]

deadinspace schreef op dinsdag 15 mei 2007 @ 01:08:
[...]

Ok, mooi, da's al iets!

Zou je eens

code:

rmmod psmouse; modprobe psmouse resetafter=1

kunnen doen, en daarna kijken of na switchen de scrollwheel het nog doet?

Als dat niet werkt, dan mag je in plaats van resetafter=1 de volgende opties (een voor een) proberen:

• resync_time=1
• proto=imps
• proto=exps
• proto=any

Mocht dat allemaal niet werken, dan kun je ook nog een aantal van die parameters samen gaan proberen. Hopelijk werkt een van deze dingen

Alleen bij "imps" en "exps" blijft ie werken na het switchen. Ik neem nu aan dat ik dit automatisch moet gaan runnen bij het opstarten? Op welke plek kan ik dit het beste doen? Bij de KDE autostart? (Maar dan zal ik wel het probleem wel hebben bij gnome?).

Iig, kan het voorlopig een oplossing zijn. Hoop alleen dat het wel dat het een keer gefixt wordt...

[eamelink]

Maak een filetje aan : /etc/modprobe.d/kvmmuisfix (of iets dergelijks )

Met als inhoud :

options psmouse proto=imps

[deadinspace]

MisterE schreef op donderdag 17 mei 2007 @ 20:21:
Alleen bij "imps" en "exps" blijft ie werken na het switchen. Ik neem nu aan dat ik dit automatisch moet gaan runnen bij het opstarten? Op welke plek kan ik dit het beste doen? Bij de KDE autostart? (Maar dan zal ik wel het probleem wel hebben bij gnome?).

Nee, je kan instellen dat psmouse altijd met bepaalde parameters wordt geladen. Daarvoor maak je een file aan in /etc/modprobe.d/ met de volgende inhoud:

code:

options psmouse proto=imps

(of welke parameters je dan ook exact gebruikte om het werkend te houden)

En daarna even

update-initramfs -u

doen (dat is misschien niet noodzakelijk, maar zou iig geen kwaad moeten kunnen).

Hoop alleen dat het wel dat het een keer gefixt wordt...

Mja, ik zou zeggen; file een bug, of klaag op de kernel mailinglist. (maar het zou me niet verschrikkelijk verbazen als bepaalde developers van mening zijn dat het geen echte bug is, omdat PS/2 nou eenmaal niet hotswappable is)

[eamelink]

Tsja, in principe is het een bug in de KVM switch; blijkbaar werkt dat ding niet volledig transparant.

[MisterE]

het werkt nu perfect. Bedankt allemaal...