I'm trying to use something like x2x or synergy to control my laptop from my desktop machine. My desktop machine has a fancy mouse attached to it, with about ten buttons. I would like to use the high-numbered buttons across x2x. On the laptop's side, events get injected via XTest. In Xext/xtest.c, ProcXTestFakeInput calls PickPointer, which willy-nilly picks a pointer, which in my case happens to be an evdev IBM Trackpoint with five buttons. ProcXTestFakeInput then decides to throw a BadValue because the button number requested is higher than the number of buttons on the device, and there goes my dream of using my fancy mouse across x2x. There are a number of possible solutions: 1) Check and see if there are devices with a suitable number of buttons. This would require a mildly different version of PickPointer(). 2) Kill the plausibility check, and e.g. have a five-button emit button presses for button seven. Doesn't sound good, but might cover the case where there is no device that could potentially have emitted that event, and I'm strongly suspecting that most downstream code plainly doesn't care. ? Thanks, Andreas
Another possibility: Be able to specify the minimum number of buttons that an evdev device exports.
In part addressed in 1.7 already where XTest devices are specific devices separate from the actual physical devices. they're currently limited to a default of 7 buttons though (see NUM_BUTTONS define in dix/devices.c), increasing this default or auto-scaling it to the highest number of buttons available seems to be the best solution.
The highest-numbered button on this thing is... nine, as far as I can tell. It seems to be mapped to "forward in browser" (honest, I didn't have to even tell Firefox that). Is there any disadvantage to making the default "more buttons than anyone can comfortably fit onto an object the size of your palm"?
(In reply to comment #3) > The highest-numbered button on this thing is... nine, as far as I can tell. > > It seems to be mapped to "forward in browser" (honest, I didn't have to even > tell Firefox that). it's by convention, same way as buttons 4-7 are the four scrollwheel directions. of course, it doesn't work in every app but FF is the prime target for back/forward anyway. > Is there any disadvantage to making the default "more buttons than anyone can > comfortably fit onto an object the size of your palm"? I think the currently highest number of buttons we can easily support is 32, everything above needs extra checking. Though with the master/slave device hierarchy, a master always has as many buttons as the highest-button'd slave device. so in your case, the master device always has at least 9 buttons. the issue with this though is that as the master changes to adjust to the new slave, it can only replace those buttons known to the slave device. in your case, if you hit a button on the trackstick, only the first 5 are copied into the master device and labeled accordingly. The others are still there but essentially unknown. This is one reason why I set the number of buttons to 7 (it really is just a 'randomly' picked number). I'd rather avoid having 32 buttons all the time for the above reason but I'm not adverse to upping it to 10 or so. Though the automatic adjustment for XTest devices would be best - the masters already do that anyway.
(In reply to comment #4) > This is one reason why I set the number of buttons to 7 > (it really is just a 'randomly' picked number). I'd rather avoid having 32 > buttons all the time for the above reason but I'm not adverse to upping it to > 10 or so. 10 or 12 sounds good to me as an interim solution--thanks for your help!
New button limit of 10 was pushed as 982f6648fd29d085265bf6035c1bf4d1b2499316. As said above, not the ideal solution but papers over the issue for now. Leaving bug open until real fix is there.
This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it. Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.