Keys M1 and M2 not working anymore

[fodiator]

Hi,
I just bought a brand new Shuttle Pro V2
Unfortunately the M1 and M2 key is not detectet by shuttle-go anymore. Maybe Contour has changed the keycodes because with the recent windows-driver all is working well.
If necessary I'm willing to assist in finding the new codes.

Kind regards
Harald

[CD3]

I have the same issue. I don't think the X server gets them at all. If run xev, nothing is sent when pressing M1 or M2.

[robert-redshield]

when you say anymore, did this work previously ?

[abourget]

oh darn,.. not sure what to do about that.. if someone wants to send me a device, I could try to debug.. right now I guess I have only the old one?!

[chrishollinworth]

@abourget I'm trying to understand which event to use for the new device.

I added device debug info and got this from evdev:

Device Name Contour Design ShuttlePro
Device Product 48
Device Version 273
Device Vendor 2867
Device Capabilities map[{0 EV_SYN}:[{0 SYN_REPORT} {1 SYN_CONFIG} {2 SYN_MT_REPORT} {4 }] {1 EV_KEY}:[{256 } {257 } {258 } {259 } {260 } {261 } {262 } {263 } {264 } {265 } {266 } {267 } {268 }] {2 EV_REL}:[{7 REL_DIAL} {8 REL_WHEEL} {11 } {256 } {257 } {258 } {259 } {260 } {261 } {262 } {263 } {264 } {265 } {266 } {267 } {268 }] {4 EV_MSC}:[{4 MSC_SCAN} {256 } {257 } {258 } {259 } {260 } {261 } {262 } {263 } {264 } {265 } {266 } {267 } {268 }]]

for M1/M2 I just get in debug mode:

---
TYPE: 2	CODE: 7	VALUE: 228
TYPE: 0	CODE: 0	VALUE: 0
---
TYPE: 2	CODE: 7	VALUE: 228
TYPE: 0	CODE: 0	VALUE: 0

guess I need to look in evdev

The new keycodes are captured by the kernel

sudo cat /sys/kernel/debug/usb/usbmon/3u > /tmp/1.mon.out

cat /tmp/1.mon.out 
ffff8a90771c8600 4041614258 C Ii:3:003:1 0:8 5 = 00f80000 20
ffff8a90771c8600 4041614318 S Ii:3:003:1 -115:8 5 <
ffff8a90771c8600 4041782256 C Ii:3:003:1 0:8 5 = 00f80000 00
ffff8a90771c8600 4041782294 S Ii:3:003:1 -115:8 5 <
ffff8a90771c8600 4043286337 C Ii:3:003:1 0:8 5 = 00f80000 40
ffff8a90771c8600 4043286381 S Ii:3:003:1 -115:8 5 <
ffff8a90771c8600 4043462338 C Ii:3:003:1 0:8 5 = 00f80000 00
ffff8a90771c8600 4043462378 S Ii:3:003:1 -115:8 5 <

00f80000 20 = M1
00f80000 40 = M2

[tuffnerdstuff]

Hi guys,

over the christmas holidays I ordered a Contour Multimedia Controller a.k.a Shuttle Pro v2 because I wanted to use it for

• audio editing (Ardour)
• video editing (Blender)
• Browsing stuff (web-browser, code, etc.)

I knew Linux is not a supported OS, but I also knew that cool people like @abourget will put in lots of effort and provide open source software. Don't ask me why, but when I discovered interception-tools I felt the urge to implement a button mapper for it (yet another tool, well, everybody needs a hobby :D). To cut the story short: While I was playing around with my software I realized that the Shuttle behaves in a strange way:

• The dial would not emit a 0 value, which causes the it to "miss" 1 out of 256 steps
• The jog-wheel also does not emit a 0 value, which makes it hard to tell when the jog-wheel is back in its "neutral" position
• The left and right button (black bars) do not emit an event at all

I did some digging around and found an old eMail thread going nowhere. But this made me curious about how this whole HID stuff works in linux. With the help of hid-tools (all cool project are on GitLab these days, huh?) I realized that the Shuttle sends (in my opinion) a wrong HID report:

• It says its dial and jog-wheel emit relative values, but actually they emit absolute values (like the guy in the eMail thread said)
• It says it has got 13 buttons, but it has 15

I also learned that the "default" HID driver (hid-generic) in Linux these days takes these reports and tries to do sensible stuff with it. For example it discards 0 values for relative dials/wheels, which makes sense as moving 0 relatively means you are standing still.

So I learned how Linux deals with "faulty" HID devices and wrote a minimal driver "fixing" the points I mentioned above and it worked:

• 0 values will be emitted
• buttons 14 and 15 are working

This, of course, has some implications:

• Dial: EV_REL:REL_DIAL events are now emitted as EV_ABS:ABS_RUDDER
• Jog-Wheel: EV_REL:REL_WHEEL events are now emitted as EV_ABS:ABS_WHEEL
• 0 values will be emitted (duh!)

So given I would file pull request and the changes would be accepted (I don't know if this is realistic, anyway) into the Linux kernel, then this would break awesome software like yours. I mean it could be changed, but I don't know if it is worth the effort. Therefore I thought I'll just get in touch with some folks developing stuff for the Shuttle and ask what they think.

So, what do you think? Do you think this is a good "fix"? Do you think it is worth the effort? Did you experience the same problems with your hardware? (maybe it's just a problem of certain revisions). If you want to try out the fix yourself I can send you a patch (but don't make fun of my code :)).

Cheers,
tuffnerdstuff

P.S.: Sorry for the long wall of text