Mauszeiger nach XFCE update am 31. Mai ist sehr träge
-
Themen Author - Neues Foren Mitglied
- Beiträge: 15
- Registriert: Mittwoch 1. Juni 2022, 14:47
- CPU: cortex-a72 bits: 64 type: MCP arch: ARMv8
- GPU: bcm2711-vc5
- Kernel: 5.15.43-1
- Desktop-Variante: XFCE4.16.0
- GPU Treiber: vc4_drm
- Hat sich bedankt: 3 Mal
Mauszeiger nach XFCE update am 31. Mai ist sehr träge
hallo Leute,
am 31. Mai (2022) gab es einen update, den ich im jugendlichen Wahnsinn durchgezogen habe...nach dem empfohlenem Neustart dann die mittelschwere Katastrophe: der Mauszeiger ist sehr träge, verhält sich so als ob der Zeiger an einer Pendelschnur hängt, die tatsächlichen Mausbewegungen werden zwar umgesetzt, aber mit Verzögerung. Das genaue Anklicken eines Details ist eine Geduldprobe, die eine ruuuhige Feinmotorik voraussetzt, und dabei den Puls immer schön niedrig halten... Irgendwie ist die Beschleunigung gestört.
Nun, in den Mauseinstellungen lässt sich das nicht beeinflussen. Alternativ habe ich eine IBM Tastatur mit touchpad eingesetzt, ist einen Tick besser, aber trotzdem eine echte Nervensäge. Andere Mäuse funktionieren genauso bescheiden.
In der Historie der Aktualisierungen habe ich den Verlauf gefunden ( und auch gespeichert ) werde aber daraus nicht schlau.
Ich bin mit meiner Latein am Ende, weiß jemand einen Ausweg ?
am 31. Mai (2022) gab es einen update, den ich im jugendlichen Wahnsinn durchgezogen habe...nach dem empfohlenem Neustart dann die mittelschwere Katastrophe: der Mauszeiger ist sehr träge, verhält sich so als ob der Zeiger an einer Pendelschnur hängt, die tatsächlichen Mausbewegungen werden zwar umgesetzt, aber mit Verzögerung. Das genaue Anklicken eines Details ist eine Geduldprobe, die eine ruuuhige Feinmotorik voraussetzt, und dabei den Puls immer schön niedrig halten... Irgendwie ist die Beschleunigung gestört.
Nun, in den Mauseinstellungen lässt sich das nicht beeinflussen. Alternativ habe ich eine IBM Tastatur mit touchpad eingesetzt, ist einen Tick besser, aber trotzdem eine echte Nervensäge. Andere Mäuse funktionieren genauso bescheiden.
In der Historie der Aktualisierungen habe ich den Verlauf gefunden ( und auch gespeichert ) werde aber daraus nicht schlau.
Ich bin mit meiner Latein am Ende, weiß jemand einen Ausweg ?
Re: Mauszeiger nach XFCE update am 31. Mai ist sehr träge
Herzlich willkommen im Forum.
Zeige uns bitte deine
Code: Alles auswählen
inxi -Fz
Wie das mit dem Codeblock funktioniert, findest du am oberen linken Rand dieser Seite unter "Regeln"
Ist deine Problematik wirklich auf den in deinem Profil beschriebenen ARM Cortex-A72 Prozessor bezogen?
-
- Moderator
- Beiträge: 2353
- Registriert: Donnerstag 19. Mai 2016, 15:49
- CPU: AMD Quad Core A8 3,6GHz
- GPU: AMD/ATI Radeon R7
- Kernel: 6.1
- Desktop-Variante: XFCE und KDE Stable, Testing, Unstable
- GPU Treiber: Free
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 153 Mal
Re: Mauszeiger nach XFCE update am 31. Mai ist sehr träge
Das habe ich dazu im englischen Forum gefunden.
Open /boot/config.txt, change fkms to kms in the dtoverlay line. Save the file and reboot.
Re: Mauszeiger nach XFCE update am 31. Mai ist sehr träge
Noch ausführlichere Informationen zum Thema und Zusammenhängen bringt natürlich ein Hinweis auf die Fundstelle: https://forum.manjaro.org/t/arm-stable- ... els/112504
Dort zu finden unter "Known Issues and Solutions"
-
Themen Author - Neues Foren Mitglied
- Beiträge: 15
- Registriert: Mittwoch 1. Juni 2022, 14:47
- CPU: cortex-a72 bits: 64 type: MCP arch: ARMv8
- GPU: bcm2711-vc5
- Kernel: 5.15.43-1
- Desktop-Variante: XFCE4.16.0
- GPU Treiber: vc4_drm
- Hat sich bedankt: 3 Mal
Re: Mauszeiger nach XFCE update am 31. Mai ist sehr träge
vielen Dank an Blueriver und Manfrago,
habe gestern Abend noch ein wenig gezielter gesucht - basierend auf meine Vermutung über die Beschleunigung - und etwas vom Arch-forum abstammend, ein wenig umfangreich die Baustelle ( typisch Arch :-) ). Aaaber, übers WE werde ich die Daten sichern, dann kann ich mich austoben, zuerst mit der Änderung in der /boot/config.txt. Wenn das hilft, ist gut, wenn nicht muss ich tiefer graben. Der englische Link ist mir auch fast nützlich, weil ich mir einen Odroid M1 zugelegt habe und dieser läuft mit Ubuntu XFCE mittelschwer katastrophal. Aber ich lasse nicht locker :-)
Nachfolgend, versuche ich die Sache mit dem Codeblock, die ich gestern gefunden habe:
ich denke, es hat geklappt :-)
habe gestern Abend noch ein wenig gezielter gesucht - basierend auf meine Vermutung über die Beschleunigung - und etwas vom Arch-forum abstammend, ein wenig umfangreich die Baustelle ( typisch Arch :-) ). Aaaber, übers WE werde ich die Daten sichern, dann kann ich mich austoben, zuerst mit der Änderung in der /boot/config.txt. Wenn das hilft, ist gut, wenn nicht muss ich tiefer graben. Der englische Link ist mir auch fast nützlich, weil ich mir einen Odroid M1 zugelegt habe und dieser läuft mit Ubuntu XFCE mittelschwer katastrophal. Aber ich lasse nicht locker :-)
Nachfolgend, versuche ich die Sache mit dem Codeblock, die ich gestern gefunden habe:
Code: Alles auswählen
[user@black-finn ~]$ inxi -Faz
System:
Kernel: 5.15.43-1-MANJARO-ARM-RPI aarch64 bits: 64 compiler: gcc v: 11.2.0
parameters: coherent_pool=1M 8250.nr_uarts=0
snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1
video=HDMI-A-1:1920x1080M@60 smsc95xx.macaddr=DC:A6:32:BF:87:8D
vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000
root=PARTUUID=c518b0c3-02 rw rootwait console=ttyS0,115200 console=tty3
selinux=0 quiet splash plymouth.ignore-serial-consoles
smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyS0,115200
usbhid.mousepoll=8 audit=0
Desktop: Xfce 4.16.0 tk: Gtk 3.24.29 info: xfce4-panel wm: xfwm 4.16.1
vt: 7 dm: LightDM 1.30.0 Distro: Manjaro ARM base: Arch Linux
Machine:
Type: ARM System: Raspberry Pi 4 Model B Rev 1.4 details: BCM2835
rev: d03114 serial: <filter>
CPU:
Info: model: N/A variant: cortex-a72 bits: 64 type: MCP arch: ARMv8
family: 8 model-id: 0 stepping: 3
Topology: cpus: 1x cores: 4 smt: N/A cache: L1: 320 KiB
desc: d-4x32 KiB; i-4x48 KiB L2: 1024 KiB desc: 1x1024 KiB
Speed (MHz): avg: 700 min/max: 600/1500 scaling: driver: cpufreq-dt
governor: schedutil cores: 1: 700 2: 700 3: 700 4: 700 bogomips: 432
Features: Use -f option to see features
Vulnerabilities:
Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: spec_store_bypass status: Vulnerable
Type: spectre_v1 mitigation: __user pointer sanitization
Type: spectre_v2 status: Vulnerable
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Graphics:
Device-1: bcm2711-vc5 driver: vc4_drm v: N/A bus-ID: N/A chip-ID: brcm:gpu
class-ID: gpu
Device-2: bcm2711-hdmi0 driver: N/A bus-ID: N/A chip-ID: brcm:soc
class-ID: hdmi
Device-3: bcm2711-hdmi1 driver: N/A bus-ID: N/A chip-ID: brcm:soc
class-ID: hdmi
Display: x11 server: X.org 1.21.1.3 compositor: xfwm4 v: 4.16.1 driver:
loaded: modesetting alternate: fbdev resolution: <missing: xdpyinfo>
Message: Unable to show advanced data. Required tool glxinfo missing.
Audio:
Device-1: bcm2835-audio driver: bcm2835_audio bus-ID: N/A
chip-ID: brcm:bcm2835_audio class-ID: bcm2835_audio
Device-2: bcm2711-hdmi0 driver: N/A bus-ID: N/A chip-ID: brcm:soc
class-ID: hdmi
Device-3: bcm2711-hdmi1 driver: N/A bus-ID: N/A chip-ID: brcm:soc
class-ID: hdmi
Sound Server-1: ALSA v: k5.15.43-1-MANJARO-ARM-RPI running: yes
Sound Server-2: JACK v: 1.9.21 running: no
Sound Server-3: PulseAudio v: 15.0 running: yes
Network:
Device-1: bcm2835-mmc driver: mmc_bcm2835 v: N/A port: N/A bus-ID: N/A
chip-ID: brcm:fe300000 class-ID: mmcnr
IF: wlan0 state: down mac: <filter>
Device-2: bcm2711-genet-v5 driver: bcmgenet v: N/A port: N/A bus-ID: N/A
chip-ID: brcm:fd580000 class-ID: ethernet
IF: eth0 state: up speed: 100 Mbps duplex: full mac: <filter>
Bluetooth:
Device-1: pl011 driver: uart_pl011 bus-ID: N/A chip-ID: arm:fe201000
class-ID: serial
Report: rfkill ID: hci0 rfk-id: 1 state: down bt-service: not found
rfk-block: hardware: no software: yes address: see --recommends
Drives:
Local Storage: total: 119.24 GiB used: 81.96 GiB (68.7%)
SMART Message: Required tool smartctl not installed. Check --recommends
ID-1: /dev/sda maj-min: 8:0 type: USB vendor: Verbatim
model: Vi550 S3 SSD size: 119.24 GiB block-size: physical: 512 B
logical: 512 B type: SSD serial: <filter> scheme: MBR
Partition:
ID-1: / raw-size: 119 GiB size: 117.06 GiB (98.37%) used: 81.9 GiB (70.0%)
fs: ext4 dev: /dev/sda2 maj-min: 8:2
ID-2: /boot raw-size: 213.6 MiB size: 213.4 MiB (99.89%)
used: 59.4 MiB (27.8%) fs: vfat dev: /dev/sda1 maj-min: 8:1
Swap:
Kernel: swappiness: 60 (default) cache-pressure: 100 (default)
ID-1: swap-1 type: zram size: 11.44 GiB used: 0 KiB (0.0%) priority: 100
dev: /dev/zram0
Sensors:
System Temperatures: cpu: 39.9 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 179 Uptime: 34m Memory: 7.7 GiB used: 1.51 GiB (19.6%)
gpu: 76 MiB Init: systemd v: 251 tool: systemctl Compilers: gcc: 11.2.0
Packages: pacman: 977 lib: 265 Shell: Bash v: 5.1.16
running-in: xfce4-terminal inxi: 3.3.11
[user@black-finn ~]$
-
Themen Author - Neues Foren Mitglied
- Beiträge: 15
- Registriert: Mittwoch 1. Juni 2022, 14:47
- CPU: cortex-a72 bits: 64 type: MCP arch: ARMv8
- GPU: bcm2711-vc5
- Kernel: 5.15.43-1
- Desktop-Variante: XFCE4.16.0
- GPU Treiber: vc4_drm
- Hat sich bedankt: 3 Mal
Re: die Problematik
ich wüsste nicht, dass ich einen Zusammenhang zwischen den Arm CPU und die Maus-Problematik aufgestellt haben soll... nachdem mein x86-er Laptop vor etwa 1,5 Jahren nach einer Systemaktualisierung beim Hochfahren stecken blieb und partout nicht mehr weiter wollte ( und das war auch Manjaro XFCE 64 bit ), dazu noch dass mein letzter windows 2000 im Frühjahr 2005 als untauglich verabschiedet wurde, wage ich es nicht mehr, irgendwelche groß- oder kleinartige Zusammenhänge aufzustellen, weil eben so gut wie alles möglich ist.Manfrago hat geschrieben: ↑Donnerstag 2. Juni 2022, 19:14Herzlich willkommen im Forum.
Zeige uns bitte deineim Codeblock, damit wir uns ein Bild darüber machen können, worum es überhaupt bei dir geht.Code: Alles auswählen
inxi -Fz
Wie das mit dem Codeblock funktioniert, findest du am oberen linken Rand dieser Seite unter "Regeln"
Ist deine Problematik wirklich auf den in deinem Profil beschriebenen ARM Cortex-A72 Prozessor bezogen?
Allerdings muss ich mich mit der Handhabung des Forums angewöhnen, bisher konnte ich meine "Problemchen" selbst lösen, aber diesmal war es zu viel auf einmal.
Re: Mauszeiger nach XFCE update am 31. Mai ist sehr träge
Das war auch so gar nicht von mir gemeint. Ich habe mich über den ARM-Prozessor in deinem Profil gewundert und erst viel später gesehen, das du ja in der Rubrik "Andere Manjaro Community Versionen Manjaro Enlightenment, Deepin, ARM, E20, JWM ,i3, PekWM, Budgie" gepostet hast. Das habe ich schlichtweg übersehen. Sorry. Zu Raspberry und Konsorten kann ich ohnehin nichts beitragen, insofern halte ich mich da jetzt sowieso raus.
-
Themen Author - Neues Foren Mitglied
- Beiträge: 15
- Registriert: Mittwoch 1. Juni 2022, 14:47
- CPU: cortex-a72 bits: 64 type: MCP arch: ARMv8
- GPU: bcm2711-vc5
- Kernel: 5.15.43-1
- Desktop-Variante: XFCE4.16.0
- GPU Treiber: vc4_drm
- Hat sich bedankt: 3 Mal
Re: Mauszeiger nach XFCE update am 31. Mai ist sehr träge
wenn du nur wüsstest wie flink meine Maus jetzt ist, würdest das "Zu Raspberry und Konsorten kann ich ohnehin nichts beitragen, insofern halte ich mich da jetzt sowieso raus" schleunigst revidieren, denn das war die absolut richtige Lösung. Wir wissen doch: alles ist eine Datei... und in der eine Datei, war einen "f" zu viel und das war die Misere. Ich habe zwar auch eine ähnliche Kleinigkeit vermutet, aber die Ursache war noch ein wenig kleiner.
Ich habe das so gemacht: die SSD - die am USB 3.0 zu SATA Adapter dran hängt, am anderen PC angestöpselt, die /boot/config.txt geändert, gespeichert, Platte ausgehängt, am Raspi angestöpselt, alles zusammengekniffen was sich zusammenkneiffen lässt, gebootet et voilá: alles im Butter !
Meinerseits, Hut ab
Also dann, sowohl Dir als auch Blueriver recht vielen herzlichen Dank. Das muss ich mir an die Wand ritzen: einen "f" zu viel...
P.S.: hmm, wozu habe ich jetzt die Daten gesichert ?? Eyy, Eyy, eyy, ich lasse mich zu sehr vom Angst treiben.
Ich habe das so gemacht: die SSD - die am USB 3.0 zu SATA Adapter dran hängt, am anderen PC angestöpselt, die /boot/config.txt geändert, gespeichert, Platte ausgehängt, am Raspi angestöpselt, alles zusammengekniffen was sich zusammenkneiffen lässt, gebootet et voilá: alles im Butter !
Meinerseits, Hut ab
Also dann, sowohl Dir als auch Blueriver recht vielen herzlichen Dank. Das muss ich mir an die Wand ritzen: einen "f" zu viel...
P.S.: hmm, wozu habe ich jetzt die Daten gesichert ?? Eyy, Eyy, eyy, ich lasse mich zu sehr vom Angst treiben.
Re: Mauszeiger nach XFCE update am 31. Mai ist sehr träge
Ganz so ist es aber nicht. Ich weiß schon, wie man eine Suchmaschine füttern muss, um eine passende Antwort zu finden. Ich unterscheide und kommuniziere hier aber auch ganz offen, was ich per Suchmaschine gefunden habe und was auf meinen eigenen Erfahrungen (meiner Ubuntu, Mint und Manjaro Datenbank) beruht. Deine Problematik zu finden und auf eine Lösung zu verweisen war relativ leicht, zumal @blueriver mir dazu die Steilvorlage für die Suchmaschine geliefert hat
-
Themen Author - Neues Foren Mitglied
- Beiträge: 15
- Registriert: Mittwoch 1. Juni 2022, 14:47
- CPU: cortex-a72 bits: 64 type: MCP arch: ARMv8
- GPU: bcm2711-vc5
- Kernel: 5.15.43-1
- Desktop-Variante: XFCE4.16.0
- GPU Treiber: vc4_drm
- Hat sich bedankt: 3 Mal
Re: Mauszeiger nach XFCE update am 31. Mai ist sehr träge
im Nachhinein habe ich doch etwas gedacht und sogar verglichen: habe noch einen Raspi 4 mit XFCE im Einsatz, der dieses Update noch nicht hinter sich hat. Dort ist das"f" in der Datei drin... allerdings ist das eine Installation die auf ein anderes image beruht und so vermute ich gewisse Unterschiede. Habe auch nach recherchiert, was der Unterschied zwischen fkms und kms sein soll, das "f" steht scheinbar für Firmware,
link hier: https://forums.raspberrypi.com/viewtopic.php?t=291546
nachdem ich die Antwort sogar übersetzt habe, stehe ich immer noch auf dem Schlauch: ist zu erwarten, dass es demnächst ein FW-Update für den Raspi gibt, oder erledigt man das extra, also händisch ? Vorausgesetzt natürlich, dass es eine neue FW gibt. Und wenn kms eh schon noch in Entwicklung ist, warum wird einem per Update das fkms aufgezwungen, mit den bekannten Folgen ? Nur verwirrend das alles... ich vermute tieferliegende Zusammenhänge zwischen fkms und weitere Pakete.
Für's Erste werde ich weiter damit arbeiten, mal sehen ob nicht auch andere Änderungen vorgekommen sind. Nach dem Entfernen des überschüssigem "f", ist der Desktophintergrund nur mit einer XFCE Maus hinterlegt, wobei die früheren Möglichkeiten nicht mehr angeboten werden. Wenn ich mal Zeit habe, werde ich danach suchen, wo die Desktophintergründe stecken...
link hier: https://forums.raspberrypi.com/viewtopic.php?t=291546
nachdem ich die Antwort sogar übersetzt habe, stehe ich immer noch auf dem Schlauch: ist zu erwarten, dass es demnächst ein FW-Update für den Raspi gibt, oder erledigt man das extra, also händisch ? Vorausgesetzt natürlich, dass es eine neue FW gibt. Und wenn kms eh schon noch in Entwicklung ist, warum wird einem per Update das fkms aufgezwungen, mit den bekannten Folgen ? Nur verwirrend das alles... ich vermute tieferliegende Zusammenhänge zwischen fkms und weitere Pakete.
Für's Erste werde ich weiter damit arbeiten, mal sehen ob nicht auch andere Änderungen vorgekommen sind. Nach dem Entfernen des überschüssigem "f", ist der Desktophintergrund nur mit einer XFCE Maus hinterlegt, wobei die früheren Möglichkeiten nicht mehr angeboten werden. Wenn ich mal Zeit habe, werde ich danach suchen, wo die Desktophintergründe stecken...