AJFaraday / ruby-buzz

A linux-only ruby library for controlling the lights in the controllers for Buzz
MIT License
2 stars 0 forks source link

Project may be more complicated than it needs to be! #1

Open SlySven opened 8 years ago

SlySven commented 8 years ago

You wrote a question on Unix & Linux stack exchange and noted that:

So I turned to a more base linux method of sending messages, and failed to do it by piping data to /dev/hidraw0, too.

Both of us have tried that - but I finally :bulb: worked out how to do it (it took me a couple of years on and off prodding the issue in several different ways)! :fireworks:

I have edited your question there, hopefully a moderator will reopen it to allow me to post a full reply, but as a taster, assuming your buzz controllers appear as /dev/hidraw0 try the following as a shell script (using sudo to run it):

#!/bin/bash

delay=0.1
while [ true ]; do
    echo -e "\x00\x00\x00\x00\x00\x00\x00" > /dev/hidraw0
    sleep ${delay}
    echo -e "\x00\x00\x00\x00\x00\xff\x00" > /dev/hidraw0
    sleep ${delay}
    echo -e "\x00\x00\x00\x00\xff\x00\x00" > /dev/hidraw0
    sleep ${delay}
    echo -e "\x00\x00\x00\xff\x00\x00\x00" > /dev/hidraw0
    sleep ${delay}
    echo -e "\x00\x00\xff\x00\x00\x00\x00" > /dev/hidraw0
    sleep ${delay}
    echo -e "\x00\x00\x00\x00\x00\x00\x00" > /dev/hidraw0
    sleep ${delay}
done

I must confess taking some guidance from figure 3 from this article which suggested that six bytes (plus a seventh terminating null byte) was needed.

AJFaraday commented 8 years ago

Hi Stephen

Thanks for this information, it's nice to know that this approach would, eventually, have resulted in a usable control system. Knowing about that extra null value may well prove useful for other projects with raw his output.

However, I think it may be best to keep this library as it is. I later discovered that the LEDs on the buzz controllers are implemented in the Linux drivers under /sys/class/leds, followed by an identifier including the word "buzz" and an index from 0 to 3.

This avoids any confusion with other hidraw files for other hid devices (such as a USB mouse or keyboard) which may have hidraw0 assigned to them.

Thanks again for taking an interest, I'll bear that in mind for future projects.

SlySven commented 8 years ago

I managed to get the U&LSE question reopened so I could answer it - you may want to edit it to prune the unproductive C stuff - my stuff there is a bit more extensive than here - I have multiple Buzz units (I went on a Car Boot sale spree) but haven't found a way to link to the hidraw# devices - I've got multiple /dev/buzz# symlinks so far but they don't point to those but to /dev/bus/usb/xxx/yyy things instead.

AJFaraday commented 8 years ago

I'm actually working in Ruby here, but you my may find part of this code useful in dealing with multiple devices.

The C code I was looking at was part of the Linux drivers, which interpret the messages to and from specific devices. This means you can work a little step above the hidraw files

For input

In /lib/ruby-buzz/device.rb you'll see this constant:

'''ruby DEFAULT_FILE_NAME = "/dev/input/by-id/usb-Logitech_Logitech_Buzz_tm__Controller_V1-event-if00" '''

You'll see that the Buzz controllers are listed by name in /dev/input/by-id, and also end with an index (based on the order they were plugged in).

I'm not entirely sure, but I think the input from this is the same as you would get in hidraw#, the code below reads 24 bit blocks from this file and interprets them with the format method.

There's a constant called MAPPINGS in /lib/ruby-buzz/pad.rb which gives you the values of each button.

For output (lights)

The Linux driver exposes these with its standard LED API, in /sys/class/led. Meaning you can pipe commands to the brightness file.

'''bash echo 1 > /sys/class/led/buzz1/brightness echo 0 > /sys/class/led/buzz1/brightness '''

I can't remember the exact name of each LED folder (it's a while since I wrote this and I don't have the controllers handy), but it'll either be:


This was the simplest way I found to interact with the buzz controllers via the Linux command line API. It seems to solve the issues of identifying that it is a buzz controlled, and multiple controllers pretty well.

I hope this helps you with your multi-buzz project.

(you still have to use sudo to interact with these files. Setting rights to them doesn't help as the files are recreated next time the device is plugged in. If you find a way around this, I'd be glad to hear it.)