Comment by ~kgp445 on ~mil/sxmo-tickets
I see this as part of a larger problem. Having a comprehensive list of programs seems difficult to maintain and not at all minimalist. I suggest parsing XDG desktop files and installing some SXMO-specific defaults. Entries for new programs should be sane, and they would be easy to persistently add / delete / modify as the user sees fit. (I feel like I saw this in another ticket, but if I did I can't find it)
Comment by ~kgp445 on ~mil/sxmo-tickets
FWIW I already made a layout to solve this problem for myself here:
https://codeberg.org/BenWestcott/sxmo-tweaks/raw/branch/master/svkbd/layout.en-us.h
It's a non-orthogonal layout similar to hacker's keyboard on Android.
I made it a while ago so though so I don't know if it still works with the new upstream SVKBD.
Comment by ~kgp445 on ~mil/sxmo-tickets
LCD pixels consume a small amount of power to stay in a non-resting state. I was not able to find a datasheet for the PinePhone display to check whether it is normally white or normally black, or how much power is consumed.
A white overlay may well be better for power, only we would need to ensure the X server has closed the window and redrawn the screen before raising the baclkight to avoid flashbangs.
Ticket created by ~kgp445 on ~mil/sxmo-tickets
The problem seems to be that the first WiFi scan after wake-up always fails, and with a default scan time of 16 seconds the reconnection time is very long. This is configurable through sysfs though, at:
/sys/module/8723cs/parameters/rtw_scan_interval_thr
Brief testing by cutting the scan time 10x dramatically increased reconnection speed after deep sleep. The most obvious solution would be to add a CRUST wakeup hook that sets a very short scan time, waits some seconds, then sets it back to something much longer to preserve battery. It is of course not user-writable by default though, so a OpenRC startup script to chmod a+w the file would also be necessary. I have not had time to produce a MWE though.
Comment by ~kgp445 on ~mil/sxmo-tickets
This appears to be an issue with ST. It seems to have a number of issues with special keys. Another example, backspace, can be seen to not function correctly in the sudo password field. Another, ctrl+shift+c/v don't work to copy and paste, you must use dmenu...
Personally I have switched to lxterminal, as it offers better compatibility, more settings (including a real light theme), and persistent storage of settings.
Comment by ~kgp445 on ~mil/sxmo-tickets
Hm, it seems that some of these sysfs paths (all copied from the related C files) actually do not exist on my system.
Comment by ~kgp445 on ~mil/sxmo-tickets
Ah, I see that I should not post patches through the website...
Comment by ~kgp445 on ~mil/sxmo-tickets
I have made a patch, but it will require tweaks to the upstream ABUILD as well and I'm not sure how to build a test package instead of pulling a remote release archive.
diff --git a/configs/openrc/sxmo-sysfs-perms b/configs/openrc/sxmo-sysfs-perms new file mode 100644 index 0000000..621c67b --- /dev/null +++ b/configs/openrc/sxmo-sysfs-perms @@ -0,0 +1,29 @@ +#!/sbin/openrc-run + +description="Makes some sysfs files writable for unprivileged software" +command="/bin/chmod" +command_args="a+w
- /sys/power/mem_sleep
- /sys/power/state
- /sys/bus/usb/drivers/usb/unbind
- /sys/bus/usb/drivers/usb/bind" +extra_commands="pp pbp"
- +echmod() {
- [ -e "$1" ] && chmod a+w "$1" +}
- +pbp() {
- echmod /sys/class/backlight/edp-backlight/brightness
- echmod "/sys/class/wakeup/*/device/power/wakeup" +}
- +pp() {
- echmod /sys/devices/platform/backlight/backlight/backlight/brightness
- echmod /sys/devices/platform/gpio-keys/power/wakeup
- echmod /sys/devices/platform/soc/1c28c00.serial/serial1/serial1-0/power/wakeup
- echmod /sys/devices/platform/soc/1f00000.rtc/power/wakeup
- echmod /sys/devices/platform/soc/1f03400.rsb/sunxi-rsb-3a3/axp221-pek/power/wakeup
- echmod "/sys/class/leds/*/brightness"
- echmod "/sys/class/wakeup/*/device/power/wakeup" +} diff --git a/programs/sxmo_screenlock.c b/programs/sxmo_screenlock.c index dc46a89..fb9530b 100644 --- a/programs/sxmo_screenlock.c +++ b/programs/sxmo_screenlock.c @@ -472,8 +472,6 @@ main(int argc, char **argv) { } }
- if (setuid(0))
if (!(dpy = XOpenDisplay(NULL))) die("Cannot open display\n");die("setuid(0) failed\n");
diff --git a/programs/sxmo_setpinebacklight.c b/programs/sxmo_setpinebacklight.c index 0352c82..ea5a7a9 100644 --- a/programs/sxmo_setpinebacklight.c +++ b/programs/sxmo_setpinebacklight.c @@ -28,11 +28,6 @@ int main(int argc, char *argv[]) { argc--; brightness = atoi(argv[argc--]);
- if (setuid(0)) {
fprintf(stderr, "setuid(0) failed\n");
return 1;
- }
- if (access(pbpScreen, F_OK) != -1) { writeFile(pbpScreen, brightness); fprintf(stderr, "Set PBP brightness to %d\n", brightness); diff --git a/programs/sxmo_setpineled.c b/programs/sxmo_setpineled.c index 97a05a9..b86bd54 100644 --- a/programs/sxmo_setpineled.c +++ b/programs/sxmo_setpineled.c @@ -48,9 +48,5 @@ int main(int argc, char *argv[]) { "sh -c 'echo %d > /sys/class/leds/%s:%s/brightness'", brightness, color, type );
- if (setuid(0)) {
fprintf(stderr, "setuid(0) failed\n");
- } else {
return system(command);
- }
- return system(command); }
Ticket created by ~kgp445 on ~mil/sxmo-tickets
setpineled, setpinebacklight, and screenlock currently bypass system permissions by always running as root. This is a serious security concern as compromising one of these programs grants privilege escalation.
These currently need root because they write to protected files in sysfs. A better solution would be to make an openrc boot script that makes these files writable by everyone.
Comment by ~kgp445 on ~mil/sxmo-tickets
I would like to help but the relevant X mechanics are beyond me. I agree, a real keyboard would be better, but my concern is that it could still be some months out. I think an unoptimal solution is better than nothing, even if we tear it out later. A stop-gap measure, if you will.