Saint Petersburg, Russia


Just hacking around

#294 switch to doas instead of sudo 12 days ago

Comment by ~begs on ~mil/sxmo-tickets

OpenDoas with doas.d is already in Alpine repos.

I'm for migrating to doas (at least by default, but I see no reasons to keep sudo support in Sxmo, it's anyway not seen by user directly), because it fits our (and every real human's) needs better.

#351 Handling phone-specific sway configuration 16 days ago

Comment by ~begs on ~mil/sxmo-tickets

We Will Duplicate Those For Other Devices

Thanks for clarifying, that's what I wanted to hear.

Not sure it's the best way, but it seems OK for now.

my proposal of creating sxmo-devices repo with "device dedicated shit" is still valid

#351 Handling phone-specific sway configuration 17 days ago

Comment by ~begs on ~mil/sxmo-tickets

This basic default configuration works only for pinephone.

  • It uses pinephone-specific output name, so only DSI-1 gets proper scaling and wallpaper.
  • It uses pinephone-specific input names when setting up delays.
  • It uses pinephone-specific input names for inputhandler bindings, so they don't work for other devices.

It's defunct by default on any device that isn't pinephone, and there is no other way to fix that than editing it directly, so just including it in user config won't do anything useful if user's device isn't pinephone.

I'm sorry that I couldn't explain my point.

#351 Handling phone-specific sway configuration 17 days ago

Comment by ~begs on ~mil/sxmo-tickets

If we handle only pinephone, then at least hardware keys and proper scaling won't work on any other device without manual configuration. I think it's unoptimal to left people writing same configuration from scratch each time. And to my knowledge there is no way to do it in device-independent way (there could be one if we had input type:key).

So I see two ways:

  • device-specific configs packaged in distribution's device package
  • device-specific configs in a separate git repo (I'm willing to maintain it if needed)

#351 Handling phone-specific sway configuration 18 days ago

Comment by ~begs on ~mil/sxmo-tickets

Oh, now I got it. But while having a one single config for all input devices of all phones seems nice, it won't work with output - DSI-1 is a common name and therefore overriding i.e. scaling factor would be impossible. And also that way it's impossible to do bindsym --input-device, as we don't know actual input devices used.

#339 SWMO - Wayland Version of SXMO 18 days ago

Comment by ~begs on ~mil/sxmo-tickets

Sway/wlroots have recently dropped logind in favor of much simplier seatd, so seatd is prefered.

#351 Handling phone-specific sway configuration 19 days ago

Comment by ~begs on ~mil/sxmo-tickets

This way Sxmo would be unusable out of box on any device other than PinePhone, so I disagree. I think it'd make sense to split any (even pinephone) phone-specific configuration (button timeouts, scaling, etc) to device-specific configs and ship them with sxmo-utils along with a fallback config that will try to autodetect hardware just to make Sxmo at least usable.

I'll be implementing it soon.

#351 Handling phone-specific sway configuration 19 days ago

Comment by ~begs on ~mil/sxmo-tickets

Just understood that we can get a shell variable in sway by doing backticks command execution like

`echo $SHELL`

And we also may get output of arbitrary shell command in our sway config this way.

So we actually can either

  • just extend existing deviceprofiles with needed vars


  • write a script to autodetect everything and trigger it from sway config, therefore not introducing device-specific configs.

#351 Handling phone-specific sway configuration 19 days ago

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

Probably a high-priority issue. Currently we have sway config relying on pinephone-specific input devices, like 0:0:axp20x-pek. Obviously, on other devices names of output/input devices are different.

We can handle it in few ways:

Make all configuration input/output device agnostic

E.g. replace

output "DSI-1"


output "*"

and <...> with "*" in

input <...> {
        repeat_delay 200
        repeat_rate 15

And so on. But there is a big con: we can't handle external keyboards or screens that way, and also it will make setting device-specific parameters like output scale more difficult.

Sway also can source external configuration files, so we also can:

  • Add device-specific sway configs to sxmo tree in addition to deviceprofiles
  • Add device-specific sway configs to device packages in distributions (mainly pmOS)

Above can also be done in different ways, i.e. we may export varlables like SXMO_SWAY_POWERBUTTON for use in Sxmo's main Sway config or do everything in device-specific config itself.

Which way Sxmo will follow? I'm voting for device-specific configs, but I'm unsure about implementation details.

#3 Release 4 months ago

Ticket created by ~begs on ~scoopta/glpaper

I made a glpaper package for Void Linux, but there is no versioned tags, and package with unversioned distfiles won't be accepted into void-packages, as well as into most other distribution repos too. Making a release would help packaging.