Draft: main/postmarketos-base: turn off tm2-touchkey leds

The udev file "20-tm2-touchkey-leds.rules" disables the leds of tm2-touchkey by default because they are in an unconfigured state. This is a continuation of merge request !2280 (closed) that was closed due to diverging too much of the initial idea.

Strangely, when writing the udev rule like KERNEL=="tm2-touchkey", ATTR{brightness}="0", it causes a dmesg error:

udevd[...]: error opening ATTR{/sys/bus/i2c/drivers/tm2-touchkey/brightness} for writing: Permission denied

Actually the udev rule is executed as root. And the result of this mentioned rule is that the leds are off. So it does work, despite the error message. However, using the echo command does not print a dmesg error. This is a bit silly – but to avoid the dmesg error, I implemented the echo command.

The number in the file name is a bit random. I chose an early number but not right at the beginning.

The udev file was placed into the package postmarketos-base because more than one device is affected. There seems to be no good way of implementation for such cases at pmaports yet. As the udev rule is driver specific, other devices ignore it.

Affected devices are:

• samsung-a3lte
• samsung-a3ulte
• samsung-a5lte
• samsung-a5ulte
• samsung-serranovelte
• samsung-klte (tm2-touchkey implemeted differently in device tree)

---

Additional comment:

When I tested the package upgrade, some ntftable packages were purged. I don't think this is related... Probably it's because I re-installed the package locally from home directory or something. I mention this just for the case I'm overlooking something.

$ sudo apk add --allow-untrusted ~/postmarketos-base-13-r1.apk

...
(1/3) Purging postmarketos-base-nftables (12-r1)
(2/3) Purging postmarketos-config-nftables (0.3-r0)
(3/3) Upgrading postmarketos-base (12-r1 -> 13-r1)
Executing postmarketos-base-13-r1.pre-upgrade
Executing postmarketos-base-13-r1.post-upgrade
Executing busybox-1.33.1-r4.trigger
Executing postmarketos-base-13-r1.trigger
...

Oh, I should lower pkgrel to 0, right? I'll change that...

By Jakko on 2021-07-02T13:30:04

added 1 commit

• f079bcfc - main/postmarketos-base: turn off tm2-touchkey leds

Compare with previous version

By Jakko on 2021-07-02T13:26:37

resolved all threads

By Jakko on 2021-07-02T13:30:11

mentioned in merge request !2280 (closed)

By Jakko on 2021-07-02T13:31:40

changed the description

By Jakko on 2021-07-02T13:38:25

approved this merge request

By Alexey Min on 2021-07-02T18:56:50

added 12 commits

• f079bcfc...e8d0a36a - 11 commits from branch postmarketOS:master
• 494160e2 - main/postmarketos-base: turn off tm2-touchkey leds

Compare with previous version

By Jakko on 2021-07-02T21:54:05

resolved all threads

By Minecrell on 2021-07-03T11:44:18

approved this merge request

By Minecrell on 2021-07-03T11:44:38

mentioned in merge request !2303 (closed)

By Jakko on 2021-07-04T11:19:40

added type::feature label

Like I said here: !2303 (comment 619854224)

IMO we should have some postmarketos-quirks to leave it out of base, but make base depend on quirks.
This would also make it easy to understand why it's here - it's a quirk!

+1 for making it device-independent, -1 for postmarketos-base

By JuniorJPDJ on 2021-07-06T22:19:51

Without reading the previous conversation: this sounds like a sane proposal. I'd add a subpackage to postmarketos-quirks for each specific quirk and then let the devices/socs that need it depend on that.

By Oliver Smith on 2021-07-06T22:19:51

As a share on the discussion: Following this proposal, there would be a new package package postmarketos-quirks and currently two subpackages, e.g. postmarketos-quirks-tm2-touchkey-leds for this MR and postmarketos-quirks-rt5033-battery-refresh for MR !2303 (closed).

The main package postmarketos-quirks wouldn't be installed anywhere. For the subpackages, they would go into the affeced device APKBUILD's as "depend".

Does it work smoothly to install a subpackage without the main package?

This sounds good to me so far. For the two specific MRs, it's a bit too complicated because both udev rules could simply be installed centrally, device-independently. However, they might be a bit of a special case (both are driver-specific). From a strucutral point of view, on mid-term, the approach of connecting quirk-supackages to certain device packages would allow quite a lot of flexibility for "creative" cross-device solution.

On the long term, postmarketos-quirks could become a bit messy ;) But I think that's ok, it's quirks after all.

Every times a quirk changes, all quirk subpackges will get updated – because they are connected together via the postmarketos-quirks package. Again I think it's ok, it's better than updating postmarketos-base each time an udev file get's in or out.

By Jakko on 2021-07-06T23:27:14

When it's going to be messy - we can split it to be separate packages, not subpackages.
I was thinking about just one package for quirks like those, but subpackages seem to be better idea in most cases ;D

By JuniorJPDJ on 2021-07-07T04:33:30

Without reading the previous conversation: this sounds like a sane proposal. I'd add a subpackage to postmarketos-quirks for each specific quirk and then let the devices/socs that need it depend on that.

IMO the overhead for the subpackage(s) will be much higher than just installing the two lines of udev rules for all devices. I'm not saying postmarketos-quirks is a bad idea but I would still just install the two udev lines for all devices. That's kind of what's nice about udev, you can make these rules generic but only let them apply to devices that need it. That's why many packages (e.g. ModemManager) come with generic udev rules that will only apply to some devices.

By Minecrell on 2021-07-07T08:25:40

Agree with @Minecrell, 2 lines of udev rules are not even worth separate (sub)package

By Alexey Min on 2021-07-07T08:46:15

Updating:

• For general quirks, the package postmarketos-quirks could be used. Adding it as "depend" to postmarketos-base, it would be installed on all devices.
• For device-specific quirks, subpackages of postmarketos-quirks could be created, adding them as "depend" to the affected device packages.

The udev rules of this MR and MR !2303 (closed) could go into the gerenral package postmarketos-quirks, being installed on all devices.

For the second case (subpackages), we don't have an specific use case right now but it could be used in the proposed manner for possible future situations.

By Jakko on 2021-07-07T10:26:37

And this is good idea!
Two udev rules are two udev rules, but I suspect we can have 30 udev rules in a month, so..

By JuniorJPDJ on 2021-07-07T17:14:52

Two udev rules are two udev rules, but I suspect we can have 30 udev rules in a month, so..

You probably have many more udev rules already installed through various packages. :D

I checked for fun, bq-paella with phosh:

$ find etc/udev/rules.d/ lib/udev/rules.d usr/lib/udev/rules.d -type f | xargs wc -l    
     2 etc/udev/rules.d/50-firmware.rules
    38 lib/udev/rules.d/77-mm-nokia-port-types.rules
    14 lib/udev/rules.d/60-persistent-alsa.rules
    26 lib/udev/rules.d/77-mm-foxconn-port-types.rules
    26 lib/udev/rules.d/60-persistent-storage-tape.rules
    15 lib/udev/rules.d/77-mm-broadmobi-port-types.rules
    54 lib/udev/rules.d/77-mm-simtech-port-types.rules
    34 lib/udev/rules.d/85-nm-unmanaged.rules
    80 lib/udev/rules.d/70-uaccess.rules
    35 lib/udev/rules.d/77-mm-qcom-soc.rules
   174 lib/udev/rules.d/77-mm-ericsson-mbm.rules
     9 lib/udev/rules.d/77-mm-pcmcia-device-blacklist.rules
    42 lib/udev/rules.d/60-persistent-input.rules
    26 lib/udev/rules.d/60-serial.rules
     7 lib/udev/rules.d/75-probe_mtd.rules
   173 lib/udev/rules.d/77-mm-longcheer-port-types.rules
    12 lib/udev/rules.d/70-joystick.rules
    68 lib/udev/rules.d/77-mm-x22x-port-types.rules
   141 lib/udev/rules.d/95-upower-hid.rules
   101 lib/udev/rules.d/77-mm-telit-port-types.rules
   189 lib/udev/rules.d/90-pipewire-alsa.rules
     8 lib/udev/rules.d/60-input-id.rules
    21 lib/udev/rules.d/95-upower-csr.rules
     5 lib/udev/rules.d/95-upower-wup.rules
    16 lib/udev/rules.d/77-mm-dlink-port-types.rules
    61 lib/udev/rules.d/77-mm-cinterion-port-types.rules
    31 lib/udev/rules.d/77-mm-huawei-net-port-types.rules
    14 lib/udev/rules.d/80-drivers.rules
    87 lib/udev/rules.d/50-udev-default.rules
    11 lib/udev/rules.d/61-gnome-bluetooth-rfkill.rules
    78 lib/udev/rules.d/77-mm-ublox-port-types.rules
     1 lib/udev/rules.d/99-fuse.rules
     8 lib/udev/rules.d/61-gnome-settings-daemon-rfkill.rules
    23 lib/udev/rules.d/60-evdev.rules
    16 lib/udev/rules.d/64-btrfs.rules
    70 lib/udev/rules.d/77-mm-quectel-port-types.rules
    11 lib/udev/rules.d/60-block.rules
    20 lib/udev/rules.d/60-persistent-v4l.rules
    82 lib/udev/rules.d/71-seat.rules
    15 lib/udev/rules.d/77-mm-tplink-port-types.rules
    12 lib/udev/rules.d/84-nm-drivers.rules
   204 lib/udev/rules.d/77-mm-zte-port-types.rules
    18 lib/udev/rules.d/70-mouse.rules
     9 lib/udev/rules.d/95-upower-hidpp.rules
    26 lib/udev/rules.d/77-mm-fibocom-port-types.rules
    21 lib/udev/rules.d/95-cd-devices.rules
    50 lib/udev/rules.d/77-mm-usb-serial-adapters-greylist.rules
     4 lib/udev/rules.d/61-mutter.rules
    29 lib/udev/rules.d/60-cdrom_id.rules
    14 lib/udev/rules.d/75-net-description.rules
    91 lib/udev/rules.d/78-sound-card.rules
   104 lib/udev/rules.d/69-cd-sensors.rules
   104 lib/udev/rules.d/60-persistent-storage.rules
    32 lib/udev/rules.d/77-mm-dell-port-types.rules
    32 lib/udev/rules.d/80-mm-candidate.rules
   213 lib/udev/rules.d/77-mm-usb-device-blacklist.rules
    23 lib/udev/rules.d/80-iio-sensor-proxy.rules
    13 lib/udev/rules.d/70-touchpad.rules
    18 lib/udev/rules.d/60-sensor.rules
    13 lib/udev/rules.d/90-nm-thunderbolt.rules
     8 lib/udev/rules.d/60-drm.rules
    19 lib/udev/rules.d/73-seat-late.rules
    53 lib/udev/rules.d/77-mm-mtk-port-types.rules
    29 lib/udev/rules.d/77-mm-sierra.rules
    17 lib/udev/rules.d/77-mm-gosuncn-port-types.rules
    13 lib/udev/rules.d/77-mm-haier-port-types.rules
    22 lib/udev/rules.d/70-power-switch.rules
    91 usr/lib/udev/rules.d/56-multipath.rules
    27 usr/lib/udev/rules.d/90-libinput-fuzz-override.rules
     6 usr/lib/udev/rules.d/80-libinput-device-groups.rules
     1 usr/lib/udev/rules.d/65-rmtfs.rules
    41 usr/lib/udev/rules.d/66-kpartx.rules
    33 usr/lib/udev/rules.d/68-del-part-nodes.rules
    39 usr/lib/udev/rules.d/11-dm-parts.rules
    16 usr/lib/udev/rules.d/90-feedbackd.rules
   150 usr/lib/udev/rules.d/10-dm.rules
    42 usr/lib/udev/rules.d/13-dm-disk.rules
    25 usr/lib/udev/rules.d/65-libwacom.rules
    54 usr/lib/udev/rules.d/11-dm-lvm.rules
   170 usr/lib/udev/rules.d/90-pulseaudio.rules
   111 usr/lib/udev/rules.d/11-dm-mpath.rules
    12 usr/lib/udev/rules.d/95-dm-notify.rules
    14 usr/lib/udev/rules.d/55-msm-modem.rules
  3867 total

30 are not going to make much of a difference here. :D

By Minecrell on 2021-07-07T17:47:43

Okay you can add postmarketos-udev-rules, which will contain all udev rules, but splitting it into more subpackages is an overkill.

By Alexey Min on 2021-07-08T01:35:35

When I tested the package upgrade, some ntftable packages were purged. I don't think this is related... Probably it's because I re-installed the package locally from home directory or something. I mention this just for the case I'm overlooking something.

Yes, this happens if you change the version, rebuild the package and then only transfer the apk of postmarketos-base - without subpackages - to your phone and install that.

(to properly test how it would behave once pushed to the repository, zap, build the package, then host your local repo)

By Oliver Smith on 2021-07-06T23:27:58

Thanks for the link, that's helpful.

By Jakko on 2021-07-06T23:27:58

marked this merge request as draft

By clayton craft on 2021-07-08T17:36:29

mentioned in merge request !2330 (merged)

By Jakko on 2021-07-08T21:53:28

I put up a new MR !2330 (merged). Let's continue the discussion there. I'll close the current MR.

By Jakko on 2021-07-08T22:02:30

closed