I have recently bought a new mouse. It is a fairly basic USB Wireless three-button scroll mouse, branded “Trust” Trust.com - Yvi Wireless Mouse - black Their website says that no driver is need for MSWin, so I guess it can use the bog-standard MS driver in a MS environment.
It also has a dpi switch, which is supposed to change between 800/1600 dpi.
It works but it is not ‘nice’ or ‘entirely satisfactory’ note the use of technical terms!
Finding the exact spot to click on is not easy for instance. (Closing a FF tab using the little X, or selecting text from a precise point, for example).
I have adjusted various settings in KDE configure-desktop, setting some to MAXIMUM but AFAICS no difference results.
Switching the dpi button seems not to change anything either.
/var/log/Xorg.0.log reports that:
a) It is detected as a keyboard as well as a mouse; and:
b) That it has 9 buttons.
I realise that the scroll wheel counts as 2 buttons (up/down) But that still is only 5, or six including the “dpi button” It seems to detect and try to install buttons for left/right.
Is there any other way to change how this mouse behaves?
This mouse is still very annoying. I have noticed recently that the BIOS also detects it as a keyboard, ie on boot-up it ‘recognises’ 1 mouse and 2 keyboards. It seems a lot better in LXDE.
It is also better in other distros I have been using lately as rescue systems, Partition Magic and Puppy.
Is there a way I could force it to use a generic bog-standard driver, the old ps2/usb 3 btn scroll mouse? I have tried commenting out some files in xorg.conf.d/xx-foo.conf files, but nothing seems to change.
Hmm where, then should I ask? KDE forum? Is there a forum/irc/mailing list for evdev?
Is the keyboard/9 buttons thing worth a bug report? If so where is the bug? opensuse? KDE evdev?
On 2013-11-13 17:46, wakou wrote:
>
> Hmm where, then should I ask? KDE forum? Is there a forum/irc/mailing
> list for evdev?
> Is the keyboard/9 buttons thing worth a bug report? If so where is the
> bug? opensuse? KDE evdev?
I answer so that you know that people read your post; but I don’t know
much about this subject, and this is probably the same for other readers.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
I have noticed some odd effects selecting text from time to time. It might suddenly decide to move it rather than just select it for instance. There are some settings in KDE time wise for several things. Drag start time sounds like a bad idea to me.
Pointer threshold may have some bearing on your other problem.
There may be more settings available via config file mods. Best place to ask is probably on the KDE mailing list. The forum possibly.
However given that the cursor is in the right place shift plus end etc or the cursor keys work perfectly.
Looking at my X log the reason for 2 keyboards on your set up is that it uses it as a class. In other words the software that looks after keyboards can also look after mice. Same with power buttons.
The reason for the change to evdev seems to be hot plug - udev. There is a comment on that in /etc/x11/xorg.conf.d/10-evdev.conf.
There are some doc’s on evdev on the Xorg site. Don’t quote me, very quick visit, but no syntax is given only it will do this and that. Syntax is linked too and is as it was just to add to the confusion. This sort of suggests that the sections in evdev.conf can be much the same as they were. Looking at the x log file it does seem to make use of them eventually. The log file also come up with the mouse settings that it decides to use.
To confuse things even further there are mouse config files in xorg.conf.d. It’s not clear if X makes any use of them or can be forced to use them even with hot plug devices. As the mouse one states the driver as being evdev followed by options it may make use of them and the options are the bit you need to look at. You should be able to see which one is used via the mouse ID in the log file. There are several mice types to choose from even 2 Novell bugs. The bug numbers could be used to see why they are there.
Looks like Xorg have junked all of the old complete documentation on options and replaced them with several books. I haven’t found it yet and haven’t looked in the books.
I would guess at the moment that X looks in the xorg.conf.d directory 1st for the device and then evdev.conf it told too but that leaves a problem if a new device is hot plugged unless it creates a device conf file. :’(
The way this all seems to work is that evdev catchall is used unless there is a conf file in conf.d directory. The files in that directory give the general idea. For the driver in these it’s still possible to set it to evdev catchall but there would be no point in having the file. More usually the driver would be a specific one or set to just evdev with the options in the following lines.
Where is can go wrong is with actual device detection at the kernel level. What it has found is shown in /proc/bus/devices , devices is a file and it can be opened as a normal user with kate to view it, Click on it, select no and then select kate from the list utilities-editors-kate. I personally would never check mark always use this application when using that facility on anything as it seems to mess KDE up. You should see an entry for a Trust USB receiver given that they generally produce excellent goods at a fair price. Maybe Linux doesn’t know about Trust. If not this may be where it went wrong. There may be several entries for it. The important things are the names as far as x conf is concerned. That is what is used in the identifier field in the conf files. A list of names can also be obtained by typing xinput list in the consol. This may not tie up with what is shown in the devices file - looks like this happens when a specific driver is used as it knows about other “things” in the device. The capabilities of each item can be found by type ximput list-props “name” name copy pasted from the xinput list output and quotes added. If there are several entries with the same name use the ID number and no quotes instead.
If button numbers are needed take no notice of the ones from above. Run xev, put the cursor over the back box that comes up and work the buttons taking care not to move it, you will soon see why, and note the button numbers that come up. Then things like this can be added to the conf file.
Option “Button??” “1”
Not really sorted this out yet and doubt if you need it anyway.
Gets confusing as a single keyboard may have several keyboard entries. I have one for my logitech usb receiver keyboard which isn’t plugged in. I also have one for an AT translated Set 2 keyboard and also HP WMI hotkeys even though I use a small cherry keyboard that doesn’t have any. They do this to cover unusual keys like vol controls and windoze buttons etc.
It looks like your problems relate to DKTEK 2.4G RX and it looks like there should be a conf file for it mentioning a specific driver. I would wonder if the problem relates to the usb plugin unit siting and where the mouse is. Curiously I use one on a lap top running windows. One thing that I have noticed is that there is only a short period of time available to remove it from the mouse and plug it into a laptop running windows - my wife’s. It also goes awol and erratic when the batteries have had it. All do. My receiver is on wires and sits on top of the PC which is under a wooden desk about 1m from the mouse. If the receiver isn’t in the right place it behaves oddly so initially I had to move it around from time to time.
If bugs sounds like it should be directed at the driver but I suspect it may be an RF problem. My wife’s Trust mouse is used adjacent to the receiver as the usb ports are on the side of the laptop. On all of these types I think the distances quoted depend on what is in the way and probably the room environment as well.
Thank you John for your time and expertise, there is a good deal to look at there. I’m going to fresh-install 13.1, and then I will see if I can fiddle with this mouse driver. On the RF issue, I doubt it, I have tried in different USB ports, fresh batteries etc, my USB hub is no more than 1 metre from the mouse pad, and before you suggest that it might be TOO close, I actually usually have it plugged direct to the on board USB socket (would be the rear panel, if I was not running my PC lying as a bare mainboard on a piece of cardboard at the moment!)
Thanks again, and I will see you on the other side of the upgrade (I hope!).
rotfl! Knowledge? More a case of piecing together a few ours of web searching.
;)It does sound like RF problems to me. It might even be interference from your bare motherboard which would normally be in a steel case where they do take some trouble to prevent RF from getting out. Plastic - well the probably coat it or make it conductive in some way.
There is another way of handling hot plugging kicking about that I have ignored. It relates to HAL and uses policies. It appears some distro’s started talking about it in 2008. As far as I can see 12.3 doesn’t use it however when I installed my Samsung printer it appears to have used it.