bob123 | Hi all. I would appreciate your help! I constantly get an error related to the kernel! | 17:52 |
---|---|---|
bob123 | kernel: [ 362.059103] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 | 17:52 |
bob123 | 2024-01-29T11:06:02.376836-05:00 bob123 kernel: [ 362.059948] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. | 17:52 |
bob123 | Please tell me how to solve this problem | 17:52 |
bob123 | sudo dmesg -t | grep psm | 17:53 |
djph | bob123: quick google says it's a problem with your hypervisor | 17:55 |
djph | or well, seems to be anyway; not a whole lot of "answer" type info | 17:58 |
bob123 | djph thanks for the answer . It won't be difficult for you to read this link, I found different answers (not the same) and the dmesg command points to the kernel | 17:59 |
bob123 | kernel: [ 362.059103] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 | 18:00 |
djph | well, yeah, it's the guest kernel getting 'strange' info from the faked hardware in the hypervisor (er, least as I'm reading it) | 18:04 |
bob123 | That is, on my Devuan machine (guest kernel), I get strange information from the local machine (Devuan). How critical is this and is it possible to fix it? I changed mice, but it didn't help. | 18:11 |
djph | bob123: as in 'changed the mouse in the hypervisor' ? | 18:18 |
bob123 | no, I meant physically replacing the mouse. If you know how to change it in the hypervisor, let's try it. I'm worried about why it shows a kernel error... | 18:22 |
djph | bob123: wait, that *IS* the guest crying about the mouse, right? | 18:25 |
djph | or am I completely mis-interpreting everything and it's the HOST pitching a fit? | 18:25 |
bob123 | Yes, you are right, it is the guest who has problems, not the host machine. | 18:36 |
djph | bob123: well, then changing the physical mouse on the host isn't gonna do anything for the guest ... | 19:14 |
bob123_ | yes, I already understood that) that’s why I’m looking for answers, no one knows anything unfortunately.... everyone has different versions | 19:21 |
djph | bob123_: again, looks like an issue with the implementation of "a mouse" by qemu/kvm in general (or rather "which mouse" it presents itself as) | 19:27 |
debdog | I wonder whether actually is a problem or just some message causing one? | 19:28 |
djph | my kvm here is just 'ps2' for the mouse bus (i.e. <input type="mouse" bus="ps2"> ) | 19:30 |
bob123_ | I'm experiencing bigger problems than just a message in dmesg, the cursor starts moving to the side on its own .. it's annoying .. | 19:36 |
rwp | bob123_, I use kvm with libvirt and if I use a standard PS2 mouse driver then I find that it just can't "keep up" with relative coordinate movement. It's annoying. The usual answer and I think the default is to have an X-Y tablet configured. Mine says EvTouch USB Tablet (it's all virtual) and it provides absolutely coordinate. The tablet input using absolute coordinates works so well that I find it impossible to tell that it is | 19:41 |
rwp | virtualized. | 19:41 |
bob123_ | Thank you for your answer . I'll look at the documentation on how to use qemu and the mouse. | 20:27 |
bob123_ | <rwp> | 20:28 |
rwp | Good luck! | 20:29 |
rwp | But yes with the relative coordinate mouse it is just too annoying to use. But with the virtualized tablet input device proving absolute X-Y coordinates things work perfectly. | 20:30 |
bob123_ | -device usb-mouse -device usb-kbd | 20:33 |
bob123_ | maybe this will work... | 20:33 |
rwp | My libvirt command line is ten miles long but includes this: -device usb-tablet,id=input0,bus=usb.0,port=1 | 20:34 |
rwp | So I think if you want to try the tablet input that you will need to use the usb-tablet device option. | 20:35 |
bob123_ | Got it, I'll try, thank you very much for your help | 20:39 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!