leds api defunct (for root)

[ensonic]

Previously I could do:

ev3dev.led.orange_on()

later this got changed to

ev3dev.Led.orange_on()

and now it is supposedly

ev3dev.Leds.orange_on()

but it does not exist. There seems to be no wait to set both leds in one call anymore? Instead I seem to have to do

ev3dev.Leds.set_color(ev3dev.Leds.LEFT, ev3dev.Leds.ORANGE)

but that is broken:

ev3dev.Leds.set_color(ev3dev.Leds.LEFT, ev3dev.Leds.ORANGE)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "ev3dev/ev3.py", line 76, in set_color
    l.brightness_pct = v * pct
  File "ev3dev/core.py", line 1688, in brightness_pct
    self.brightness = value * self.max_brightness
  File "ev3dev/core.py", line 1606, in max_brightness
    return self.get_attr_int('max_brightness')
  File "ev3dev/core.py", line 169, in get_attr_int
    return int(self._get_attribute(attribute))
  File "ev3dev/core.py", line 162, in _get_attribute
    return self._attribute_cache.read(abspath(self._path + '/' + attribute))
  File "ev3dev/core.py", line 82, in read
    f = self.file_handle(path)
  File "ev3dev/core.py", line 74, in file_handle
    f = open(path, mode, 0)
IOError: [Errno 13] Permission denied: '/sys/class/leds/ev3-left0:red:ev3dev/max_brightness'

[ensonic]

Apparently, the "Permission denied" only happens for root.

[ddemidov]

I guess we could revert #73, and check that IOError here is actually a 'wrong mode' error (and rethrow exception otherwise). The only problem is I could not come up with a way to do this reliably.

[ensonic]

Can we use os.stat() and check st_mode? I gave it a quick try, but I am missing something:

import os
from stat import *
mode=os.stat('/sys/class/leds/ev3-left0:red:ev3dev/max_brightness').st_mode
S_IWUSR(mode)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable

[ddemidov]

That actually could work, thanks!

import stat, os
st = os.stat('test.txt')
mode = stat.S_IMODE(st[stat.ST_MODE])
stat.S_IRGRP & mode # is file readable by group?
stat.S_IWGRP & mode # is file writable by group?

I'll do a PR in a couple of hours.

[rhempel]

I merged this PR, but it occurs to me that this is just checking for group privileges.

Don't we want to check if the file is read/writeable by user OR group OR world

[ddemidov]

Users only get access to sysfs attributes because they are in ev3dev group. I thought that checking for group access is only right.

[rhempel]

OK, as long as all the attributes we ever create have ev3dev group ownership then I'm OK with the change as is.

[rhempel]

Sorry, @ensonic should close - on Monday

[ensonic]

This sounds good to me. This is on develop, so this will become 0.5.1? Since it is a bugfix and not an API break, I think it should be in master for 0.5.0.