spec.json: fix leds "triggers" system name.

[barnex]

Looks like there was a typo in the systemName for LEDs Triggers. This caused a clash in bindings I'm trying to generate.

[WasabiFan]

Are you sure that the property is called triggers? Looking at online LED docs, I think we had it right in not including an s. The property in our API is called Triggers because it returns an array (not just a single string), but the property in the file system is just trigger.

[ddemidov]

The property is definitely called trigger:

[robot@ev3dev ~]$ ls -l /sys/class/leds/ev3\:left\:green\:ev3dev/
total 0
drwxr-xr-x 2 root root      0 Jan  1  2000 power
-rw-rw-r-- 1 root ev3dev 4096 Jan  3 10:03 brightness
lrwxrwxrwx 1 root root      0 Jan  1  2000 device -> ../../../leds_pwm
-r--r--r-- 1 root ev3dev 4096 Jan  1  2000 max_brightness
lrwxrwxrwx 1 root root      0 Jan  1  2000 subsystem -> ../../../../../class/leds
-rw-rw-r-- 1 root ev3dev 4096 Jan  3 10:03 trigger
-rw-rw-r-- 1 root ev3dev 4096 Jan  1  2000 uevent

[WasabiFan]

So @barnex, maybe the question to ask here instead is about our choice of naming: Do you believe that the attribute in our API should be called just "trigger" to match the underlying LED class?

[barnex]

Looks like I didn't understand the intent behind Trigger/Triggers. Thanks for the clarification!

As far as I'm concerned, the friendlyName should stay "Triggers", so that it does not conflict with Trigger.

Context: I'm generating Go bindings for ev3dev-lang (https://godoc.org/github.com/barnex/ev3dev-lang-go/ev3). Go does not have overloading, so I need unique method names. Looks like I'll just have to generate them from the friendlyName, not the systemName.

Anyway, sorry for the noise and thanks for your awesome work!

[ddemidov]

Looks like I'll just have to generate them from the friendlyName, not the systemName.

That is the intended path. systemName is the name of the actual sysfs attribute, and friendlyName is the name of the property in the API.