13 replies to this topic

[pmprog]

From the libpnd source I got from git, it opens the device and writes to a device called /sys/class/backlight/gpio-backlight/brightness; however, my Pandora does not have that device. Instead I have /sys/class/backlight/pandora-backlight/brightness.

When I try and "echo 22 >/sys/class/backlight/pandora-backlight/brightness" I get permission denied, even if I try to "sudo" the command.

How can I control the backlight from my application?

Cheers

[notaz]

Libpnd hardware routines are broken and unmaintained, I asked skeezix to remove them but he seemed to be against it.

As for echo, all it does is printing to stdout, so sudo won't change anything. You should become root (sudo su) and do it or make sure the whole command is run under sudo (sudo bash -c 'echo ...').

How can I control the backlight from my application?

use the helper script

system("sudo -n /usr/pandora/scripts/op_bright.sh <N>");

it will not require a password.

[pmprog]

Great, thanks for the reply.

Also, I thought if I sudo'd the echo with my redirect, it'd do the whole thing, but you learn something new everyday.

[_wb_]

You can copy the stuff I do in the flashlight app: it uses gksudo to chmod that file so everyone can write to it (yes, that would be a security bug if you're using your pandora as a server, because now suddenly all your users can modify your backlight setting, but I'm not too worried about that problem). Then the program can just write values to that file without needing root permissions itself. (you could also run the entire program as root, but to me that seems not such a good idea).

[pmprog]

Thanks _wb_, but Notaz's reply does the job, and doesn't require me to mess around with any permissions or anything.

[notaz]

You can copy the stuff I do in the flashlight app: it uses gksudo to chmod that file so everyone can write to it (yes, that would be a security bug if you're using your pandora as a server, because now suddenly all your users can modify your backlight setting, but I'm not too worried about that problem).

Hmh, could you change it to just call the above script instead, so that users never have to enter password?

[_wb_]

You can copy the stuff I do in the flashlight app: it uses gksudo to chmod that file so everyone can write to it (yes, that would be a security bug if you're using your pandora as a server, because now suddenly all your users can modify your backlight setting, but I'm not too worried about that problem).

Hmh, could you change it to just call the above script instead, so that users never have to enter password?

Sure, I didn't realize that it was possible without password. I'll change it in the next version.

[pmprog]

Hmh, could you change it to just call the above script instead, so that users never have to enter password?

On a related note, how do you set a script so you can run it sudo'd without requiring password? When I was making the USB Mass Storage plugin, sleashjag was the one who indicated to me there was a list or something of files allowed to sudo, but I don't know where this is.

I don't think I'll need it for my clock project, but it'd be nice to know

[_wb_]

You can copy the stuff I do in the flashlight app: it uses gksudo to chmod that file so everyone can write to it (yes, that would be a security bug if you're using your pandora as a server, because now suddenly all your users can modify your backlight setting, but I'm not too worried about that problem).

Hmh, could you change it to just call the above script instead, so that users never have to enter password?

Sure, I didn't realize that it was possible without password. I'll change it in the next version.

I haven't tried it yet, but I'm worried that the overhead of calling the script could be too much (a system call, sudo, bash, ...) since the flashlight needs to change the backlight setting very often: e.g. the strobe is implemented by switching it off and on rapidly, e.g. for a 20Hz strobe that is 40 calls to the script per second. Even without the strobe it may have to change the backlight setting in every frame, i.e. 25 times per second (e.g. when dimming a color or in color cycling mode). So I'd rather not do it by calling an external script.

Is there any reason why the backlight setting is read-only while others (e.g. the nub settings) can be written to? I wouldn't mind if the default permissions for the backlight setting would be 666 instead of 644...

[notaz]

On a related note, how do you set a script so you can run it sudo'd without requiring password? When I was making the USB Mass Storage plugin, sleashjag was the one who indicated to me there was a list or something of files allowed to sudo, but I don't know where this is.

I don't think I'll need it for my clock project, but it'd be nice to know

It's done by using /etc/sudoers /etc/sudoers.d/* files, which instructs sudo not to ask for password.

I haven't tried it yet, but I'm worried that the overhead of calling the script could be too much (a system call, sudo, bash, ...) since the flashlight needs to change the backlight setting very often: e.g. the strobe is implemented by switching it off and on rapidly, e.g. for a 20Hz strobe that is 40 calls to the script per second. Even without the strobe it may have to change the backlight setting in every frame, i.e. 25 times per second (e.g. when dimming a color or in color cycling mode). So I'd rather not do it by calling an external script.

This is a good point, this method wasn't really intended for strobe effects and stuff..

Is there any reason why the backlight setting is read-only while others (e.g. the nub settings) can be written to? I wouldn't mind if the default permissions for the backlight setting would be 666 instead of 644...

Main reason is to prevent programs from using it because /sys/ contents tend to change between kernel versions and hardware revisions. If everyone uses script we can update it accordingly in firmware along with kernel to use the right /sys/ files..

[_wb_]

Is there any reason why the backlight setting is read-only while others (e.g. the nub settings) can be written to? I wouldn't mind if the default permissions for the backlight setting would be 666 instead of 644...

Main reason is to prevent programs from using it because /sys/ contents tend to change between kernel versions and hardware revisions. If everyone uses script we can update it accordingly in firmware along with kernel to use the right /sys/ files..

OK, but I'm calling /usr/pandora/scripts/op_paths.sh once to get the environment variable SYSFS_BACKLIGHT_BRIGHTNESS, and I use that filename. I'm not hardcoding the filename. I hope that is also a future-proof way to do things.

Having to ask a password is a bit annoying, but it is not that bad because it will only ask the password once per boot (rebooting will make the file read-only again, so it needs the password again to chmod it back to 666).

[pmprog]

It's done by using /etc/sudoers /etc/sudoers.d/* files, which instructs sudo not to ask for password.

Thanks

[skeezix]

Libpnd hardware routines are broken and unmaintained, I asked skeezix to remove them but he seemed to be against it.

As for echo, all it does is printing to stdout, so sudo won't change anything. You should become root (sudo su) and do it or make sure the whole command is run under sudo (sudo bash -c 'echo ...').

How can I control the backlight from my application?

use the helper script

system("sudo -n /usr/pandora/scripts/op_bright.sh <N>");

it will not require a password.

Not against; I dont' remember the exchange though

Certainly I keep meaning to (but never get around ot) splitting off 'pandora specifric' stuff from libpnd (pnd file) stuff.

But for sure the /proc (and so on) type references are bad, for two main ways..
i) out of date
ii) they generalyl assume sudo/root-ness, and instead should just go to the sh-scripts which are the officially maintained methods

ie: that part of libpnd was done very quick, before the devices were released.

So ..

Thoughts --

Shoudl that stuff be removed wholesale (I figured it might be useful documentation for someone, but if its mostly wrong, thats no good either), or shoudl be corrected to ue the shj-script interfaces? (They're provided for _convenience_, to make repetitve stuff easy, after all.)

jeff

[notaz]

Shoudl that stuff be removed wholesale (I figured it might be useful documentation for someone, but if its mostly wrong, thats no good either), or shoudl be corrected to ue the shj-script interfaces? (They're provided for _convenience_, to make repetitve stuff easy, after all.)

I suggest dropping them for .next, if anything is found to need them, then bring the used portions back and fix them. Fixing them up all now does not solve the problem because they will become broken after a while again.