The KDE Goals initiative is working to improve support for input devices such as game controllers, fancy mice, handhelds — anything for your gaming needs.
This Sunday, Oct 20th at 18:00 (UTC), the KDE Goals champions will be answering your questions live. Post your questions here and I’ll make sure they’ll answer them.
We’ll be streaming here: https://tube.kockatoo.org/w/2tAyknEQc8EhL2AyoAUE8M
You can get in touch with the community at the Matrix room.
You must log in or register to comment.
Most important feature whoch Gnome has for Years.
2 or more Mices at the same time with its own focus. Something that KDE can’t handle at all, because those two mice positions are figthing for the cursor
I’m curious. What’s the use case for two (or more) mice?
Co-op web browsing and also pvp
A lot of new game ideas.
It was a wish when I started to develop my own 3D Engine with OpenGL.
But after finishing it to a point where I am happy, I would try going to Godot and Bevy.
Maybe I will try to create something first in Gnome, but I dislike Gnome a bit after 3 Years of usage and a switch to KDE for 2 Years.
This would be an awesome lil feature
How does this work? Can you share some screenshots or record your screen?
Puuh, I can redo it. But I had a Video 2-3 Years ago where I used a Feet and a Hand at the same time on the table (because one Hand needs to hold the Phone/Cam)
I loved it because its goofy flexing.
Its only possible on X11 Yet afaik because in X11 you can Manipulate XInput and create new Focus Groups to assign your devices there (move them to another group).
This already is used in Both KDE and Gnome Wayland, but only for Tablets (they get theie own Focus group like I can do it with X11 and XInput command tool, its the same but a feature that actually is default). You can also see a difference how Gnome can actually handle both inputs well at the same time, while KDE is a glitching nightmare
I’m not understanding, you are saying this works in Gnome Wayland but not on KDE atm?
Jup.
What do you mean by “I’ll make sure they’ll answer them”? Are you a reporter? But if this is a bug report thread now, here I go:
I have and one of my friends had the Logitech G502 LIGHTSPEED mouse. It has a problem with it’s mouse wheel.
I’ve done the debugging a while back, but maybe I can get the logs again. Basically when using it wired it only uses the regular mouse wheel events, but when using it wireless (most of the time) it uses both highres mwheel events and regular ones. Confusing all apps. To add to this, the regular events seems to be simulated by software, based alongside every 5th (? maybe it was a long time ago) highres event. While at seemingly random times a full “click” of the mouse wheel just doesn’t register the required number of highres events, making the “normal” one also absent. I tough this was a hardware issue, as when it happens you can go back and forth and it won’t register it at all, however it doesn’t happen when pugged in.
This is probably some kernel issue if I’m being honest, all I know is that on Windows it works perfectly. But I am using KDE and I have not debugged this mouse on any other window manager.
I truly don’t know if this was the type of reply you were looking for, if not: Sorry for wasting your time. (There’s also a KDE bug when editing widgets or when turning the screen off and on, but that’s not input device so)
This is not my experience on an Arch system. KDE has never crashed on me
Might be hit or miss. On Kubuntu it wigged out on me often enough that I needed to make a shortcut to restart Plasma, but so far it’s been stable on OpenSUSE Tumbleweed.
If your distro is packaging older versions then you shouldn’t be surprised that things break. Tumbleweed is a rolling release distro
