#573 menu redesign 1 year, 14 days ago

Comment by ~tetrakist on ~mil/sxmo-tickets

Apologies for being late to the party, but I wanted to make the participants aware of three patches to bemenu that may be useful in a rework of the menu system, available at https://git.sr.ht/~tetrakist/bemenu

a2785d86: adds the --dual option
This enables a dual-line mode in which each entry consists of two lines, the first being the displayed menu item, and the second being the returned value. I believe this has value because first, it allows us to encode more state in the menu item, rather than the menu (which should simplify the menu code somewhat) and second, it permits multiple lines in the menu to display the same text, but which performing different tasks. A trivial example being volume up/down items for multiple audio outputs (assuming a header menu item above each set of device actions).

d6144605: adds the --exec [yes|no] option
This indicates whether the selected menu item (or its "value" in the case of --dual) should be executed. This offers the possibility of avoiding looping back through the menu shell code to execute a command, should that be useful.

2a139647: adds the --selected-index option
This returns the numerical index of the selected menu item, rather than its text or value. This option is currently ignored if --exec=yes is set.

The intent of these patches is to permit further simplification of the menu shell code and improve the overall flexibility of the menuing system. The patches are all quite minimal and would hopefully be easy to upstream if the maintainer is amenable.

NB: it has been a while since I wrote these, so rebasing against the official tree may be necessary. I haven't checked yet.


#226 dmenu in landscape 3 years ago

Comment by ~tetrakist on ~mil/sxmo-tickets

Ideally, this should be calculated as a function of menu-item height, so as to leave enough room below/above the edge of the menu for the page up/down and home/end regions.

#224 Unable to swipe up for keyboard when screen is rotated 3 years ago

Ticket created by ~tetrakist on ~mil/sxmo-tickets

When the screen is rotated, you can't swipe "up" to bring up the keyboard if you start from the right hand side of the "bottom" of the rotated screen (i.e. from below the midpoint of the left-hand side of the screen if holding the phone vertically)

#204 Screen off on its own (new feature or a bug?) 3 years ago

Comment by ~tetrakist on ~mil/sxmo-tickets

I can confirm that the call to xset dpms force [on|off] in sxmo_screenlock is the culprit here, as it re-enables DPMS.

$ xset s off -dpms
$ xset q | grep DPMS -1
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Disabled

After sxmo_screenlock calls xset dpms force off in blankscreen():

$ xset dpms force off
$ xset q | grep DPMS -1
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is Off

After sxmo_screenlock calls xset dpms force on in unblankscreen():

$ xset dpms force on
$ xset q | grep DPMS -1
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On

I suspect that if we to honor a user preference for DPMS enablement, we may need to add a postunblank hook similar to the existing postwake hook.

#205 Planned v1.4.0 release 3 years ago

Comment by ~tetrakist on ~mil/sxmo-tickets

Potentially major issue: #214 -- failure of mkinitfs. If the initramfs gets out-of-sync with the rest of the system due to a failed mkinitfs, users may get non-bootable devices. This should be fixed by simply making the boot partition larger, as done in this patch for sxmo-image-builder.

#214 sxmo-image-builder: MAY PREVENT BOOTING - apk upgrade fails - boot partition too small 3 years ago

Ticket created by ~tetrakist on ~mil/sxmo-tickets

When running "apk upgrade" on a fresh sxmo 1.3.0 image, the following error is seen when trying to rebuild the initramfs:

(129/131) Upgrading sxmo-xdm-config-openrc (0.2.1-r1 -> 0.2.2-r0)
(130/131) Upgrading postmarketos-ui-sxmo (1.3.0-r1 -> 1.3.2-r0)
Executing postmarketos-ui-sxmo-1.3.2-r0.post-upgrade
 * rc-update: sxmo-pinephone already installed in runlevel `default'; skipping
 * rc-update: modemmanager already installed in runlevel `default'; skipping
 * rc-update: xdm already installed in runlevel `default'; skipping
(131/131) Purging llvm10-libs (10.0.1-r1)
Executing busybox-1.33.0-r4.trigger
Executing glib-2.66.7-r1.trigger
Executing eudev-3.2.10-r0.trigger
Executing dbus-1.12.20-r2.trigger
Executing ca-certificates-20191127-r5.trigger
Executing kmod-28-r0.trigger
depmod: WARNING: could not open modules.order at /lib/modules/5.10.12: No such file or directory
depmod: WARNING: could not open modules.builtin at /lib/modules/5.10.12: No such file or directory
Executing fontconfig-2.13.1-r3.trigger
Executing mkfontscale-1.2.1-r1.trigger
Executing postmarketos-mkinitfs-0.22-r0.trigger
==> initramfs: creating /boot/initramfs-postmarketos-allwinner
Scanning kernel module dependencies...
NOTE: ** modprobe warnings below can be ignored ** if your device does not run the
mainline kernel yet (most devices!) or if the related kernel options are enabled
with 'y' instead of 'm' (module).
 - deviceinfo: sun6i_mipi_dsi sun4i_drm pwm_sun4i sun8i_mixer anx7688 gpio_vibra
 - 00-default.modules: dm_crypt ext4 usb_f_rndis
==> kernel: device-tree blob operations
==> kernel: copying dtb allwinner/sun50i-a64-pinephone-1.1 allwinner/sun50i-a64-pinephone-1.2 to boot partition
==> initramfs: creating uInitrd
Image Name:   uInitrd
Created:      Wed Mar 17 23:04:31 2021
Image Type:   AArch64 Linux RAMDisk Image (uncompressed)
Data Size:    1442774 Bytes = 1408.96 KiB = 1.38 MiB
Load Address: 00000000
Entry Point:  00000000
==> kernel: creating uImage
Image Name:   postmarketos
Created:      Wed Mar 17 23:04:32 2021
Image Type:   AArch64 Linux Kernel Image (uncompressed)
Data Size:    19752968 Bytes = 19290.01 KiB = 18.84 MiB
Load Address: 80008000
Entry Point:  80008000
==> initramfs: creating /boot/initramfs-postmarketos-allwinner-extra
gzip: write error: No space left on device
cpio: write error: Broken pipe
Executing postmarketos-base-10-r0.trigger
Configuring a getty on port ttyS0 with baud rate 115200
Executing gtk-update-icon-cache-2.24.33-r0.trigger
OK: 792 MiB in 426 packages 

This is because:

  1. the initramfs-postmarketos-allwinner-extra file is being created on the /boot partition
  2. the new initramfs file is 46M in size, and there's only 33M free on /boot
  3. the new initramfs is 37% larger than the old initramfs(34M).
  4. libLLVM-10.so (62M) was replaced with libLLVM-11.so (89M).

Possible solutions:

  • Default boot_size be increased to at least 160M, with 200M preferable.
  • Create new initramfs files outside boot partition, then overwrite.
  • Trust users of pmbootstrap to predict and use safe value for boot_size option.
  • Have script remove existing initramfs from /boot before building new one

Additional information:

Comparison of libLLVM-##.so files sizes (output from du, in bytes):

62292864        old/usr/lib/libLLVM-10.so
88811280        new/usr/lib/libLLVM-11.so

df -h /boot output prior to upgrade:

Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p1  114M   75M   33M  81% /boot

df -h /boot output after (manual) upgrade:

Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p1  114M   87M   21M  81% /boot

#213 "sudo apk upgrade" fails on fresh 1.3.0 image 3 years ago

Ticket created by ~tetrakist on ~mil/sxmo-tickets

On a fresh copy of the sxmo 1.3.0 image, following the "Upgrading" instructions in the User Guide produces a dependency error.

~ $ sudo apk update
fetch http://postmarketos1.brixit.nl/postmarketos/master/aarch64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/testing/aarch64/APKINDEX.tar.gz
2021-03-17 20:45:56.611777 [http://postmarketos1.brixit.nl/postmarketos/master]
v20210212-1888-g8d13881363 [http://dl-cdn.alpinelinux.org/alpine/edge/main]
v20210212-1887-gdacf38ceed [http://dl-cdn.alpinelinux.org/alpine/edge/community]
v20210212-1891-ga4e5f5a972 [http://dl-cdn.alpinelinux.org/alpine/edge/testing]
OK: 19008 distinct packages available

~ $ sudo apk upgrade
ERROR: unable to select packages:
  uboot-tools (virtual):
    provided by: u-boot-tools
    required by: device-pine64-pinephone-0.21-r0[uboot-tools]

This is trivially dealt with by the following incantation:

~ $ sudo apk add u-boot-tools
OK: 767 MiB in 423 packages

After which the upgrade proceeds without problem:

~ $ sudo apk upgrade
(1/131) Upgrading musl (1.2.2-r1 -> 1.2.2-r2)
(2/131) Upgrading busybox (1.33.0-r2 -> 1.33.0-r4)
Executing busybox-1.33.0-r4.post-upgrade
(3/131) Upgrading alpine-baselayout (3.2.0-r9 -> 3.2.0-r11)
... etc. etc. ...

While most of our users are likely capable of figuring this out, it is an unnecessary barrier to entry, and should be dealt with.

#184 svkbd leaves a lingering "enter" after xdm login 3 years ago

Comment by ~tetrakist on ~mil/sxmo-tickets

This commit may fix the issue. Test reports welcome.

#86 sxmo-screenlock does not block multitouch events 3 years ago

Comment by ~tetrakist on ~mil/sxmo-tickets

This is confirmed not fixed as of 2021-03-16 in 1.3.0. Two-finger tap and scroll work when the screen is locked with display on or off.

#208 Surf: Cannot visit any pages other than Google and Duckduckgo 3 years ago

Comment by ~tetrakist on ~mil/sxmo-tickets

This is not entirely correct. I can get to my own page: https://tetrakist.srht.site but it is very bare bones. Testing with another simple site: https://news.ycombinator.com does not succeed.

After debugging a bit in the source code, it appears to be an issue within the WebKit Network Process. I was not able to debug this subprocess, and it looks like it may require a build of the webkit2gtk package with -DDEVELOPER_MODE=on, as I was not able to use NETWORK_PROCESS_CMD_PREFIX for debugging with the current webkit2gtk package. (see: https://trac.webkit.org/wiki/WebKitGTK/Debugging). Calling webkit_settings_set_enable_write_console_messages_to_stdout(s, TRUE); did not produce any additional output when running surf from the command line. The "load-committed" signal is being received, so it appears there is not a problem prior to beginning the download, though I'm not certain given my lack of familiarity with either webkit or webkit2gtk.