[Kde-hardware-devel] Jog/Shuttle devices (was: "KDE's libsolid")

[Rick Stockton]

Sorry about the top-posting, but my comments are easier to follow 
(better organized) if written all together. Please note right away, that 
although I added support for "more mouse buttons" in Qt 5.0, I'm not 
very qualified or experienced. My opinions are very possibly wrong 
and/or irrelevant. I'm sorry, but I won't attempt to undertake support 
for your device.

*** Details:

All such USB devices, supported by Qt 5.x on Linux, should go through 
the evdev kernel module. (That's mandatory for Wayland, and avoids 
creating weirdness in other Qt Platform plugins.) Most current 
mouse+keyboard devices, such as my Logitech wireless receiver, present 
_separate_ mouse and keyboard devices at the USB receiver, even when no 
keyboard is present. If your shuttle presents multiple USB devices in 
the same way, then I'd have one kind of implementation problem. But if 
it presents a single USB device, with events re-dispatched by 
proprietary Windows or OSX Driver code, then I would have a different 
kind of implementation problem. (The latter is much worse.)

Within Qt5, there are two fundamental problems which this device would 
have: (1) conflicting input context;and (2) input from a "fake" 
keyboard. Qt has only one input context (focus) for the keyboard, and 
one for the pointer/mouse. You can't have two "pointer devices" in a 
single Qt application - If I add a joystick, and try to use it, the 
joystick becomes a replacement for my mouse (and the mouse goes dead.) 
The IMPORTANT result of this Qt characteristic is: your shuttle device 
can't work *with* a mouse, it can only work *instead* of a mouse.

A Qt Application currently supports only one keyboard. To make use of 
"keystroke/keyboard" input from your device, I would have to create 
keystroke events from your device - and inflict them to the current 
widget or surface which has GENUINE keyboard focus. I imagine that i10n 
problems, conflicting modifier key states, and large numbers of other 
"issues" would arise from this scheme. My Qt Approvers and Project 
big-shots would also kill this. Several months ago, I asked about 
implementing mouse shortcuts via emulation of QKeySequence occurences, 
and the inventor of QKeySequence saw huge problems from the occurrence 
"imaginary, extra" Keystroke Events from other devices -exactly as I 
just described, and ordered me to come up with a better way.

Anyway - from my point of view, a "gamer" mouse (which might have as 
many as 15 buttons, *plus* the four wheel scroll directions) gives a lot 
more buttons to use - without introducing fake, possibly conflicting, 
events. Mouse buttons should become shortcut-capable in the Qt 5.1 time 
frame. Since I intend to support use of of low-numbered buttons as 
"modifiers", a mouse like my own (Logitech G700) is capable of providing 
more than 20 easily-pressed shortcut combinations. THAT should provide 
for the need of shortcuts from non-keyboard devices, with far less new 
code and risk. KDE already provides for Application-specific shortcuts, 
and the mouse shortcuts enhancement would fit into the current scheme 
pretty smoothly, with far less coding and risk.

*** /Details

Pascal, do you accept my alternative recommendation (i.e., mouse button 
shortcuts instead)? Or am I missing some really important, unique 
capability of your Shuttle Device?

On 06/21/2012 06:47 AM, Alex Fiestas wrote:
> On Thursday, May 31, 2012 10:03:41 PM Pascal Fleury wrote:
>> Hello,
>>
>> As pointed out by Kevin, I ask for further information on this mailing list.
>>
>> I was wanting to add better support for Jog/Shuttle devices (input devices
>> like this one <http://retail.contourdesign.com/?/products/23> that I own)
>> and was considering adding this as a new type of device to KDE's Solid
>> library, to increase support across many programs that may use them. Here
>> is my proposal:
>>
>> 1. Add a new device type and Interface to the Solid frontend. This would
>> let Solid notify about such a device being plugged in, and give some
>> information about it (#buttons, jog resolution, shuttle min/max values,
>> product name and device name).
> We don't have any interface for input devices, in case we decide to go and add
> one for Job/Shuttle we should add interfaces for other kind such
> mouse/keyboard/touchpads/wacoms...
>
>> 2. Add a new udevdevice so that the USB device can be detected at least on
>> Linux. I know too little about other OSs that Solid runs on.
>> As pointed out by Kevin, actually listening to events and dealing with
>> input from the device's interaction would be done externally to Solid.
> This needs patching in Qt, some effort is going on to supoprt *any* kind of
> input for shortcuts as well of supporting any kind of input.
>
>> Is such a proposal something you would consider at all ? Also, I have no
>> creds in submitting code to KDE, I have submitted improvements on the
>> support of such devices to Kdenlive.
> The rule for adding new interfaces is as follows:
> We shall add a new interface if and only if more than one application is
> interested on it.
>
> So, that's the first question I'd like to ask you: Do you think that
> applications should be aware that a Jog/Shuttle is present? can you tell us
> some examples?
>
>> In case you think it's worth it, how/where would information be stored
>> about the devices themselves? As it turns out, one can only know that it is
>> a JogShuttle device from the USB VendorID and ProductID, and I guess there
>> is no means to get the device to tell us about its capabilities, so that it
>> would have to be stored in some kind of profile database that would have
>> the info about #buttons, ranges of jog and shuttle etc.
> This sounds like something that should go to either Kernel or X11.
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>