~mil/sxmo-tickets#351: 
Handling phone-specific sway configuration

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"

with

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.

Status
REPORTED
Submitter
~begs
Assigned to
No-one
Submitted
a month ago
Updated
a month ago
Labels
No labels applied.

~saba a month ago

I think device-specific config files are the way to go unless there's some way to auto-detect everything. I was thinking about this with my pinetab, but turned out they are the same for buttons on the pinephone. I did need to add a section for the pinetab keyboard's touchpad (to configure tap-to-click and natural scrolling).

The default_alsa_sound.conf is for Pinephone's soundcard and I had to replace it on my pinetab. I think this could be automated, because I was able to copy the config from /var/lib/alsa/asound.state which had the right sound-card name and inputs/outputs.

It might also be possible to use

swaymsg -t get_inputs

to get the input device id unless there's another simpler way to do it with libinput.

~begs a month ago*

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

or

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

~stacyharper a month ago

My opinion on this is way simplest. We dont care if we load additional configuration. We should just have one input/output sxmo global sway config file. And we should load it in the user sway file. I dont think loading one or a hundred input/output config will change that much the loading time. And if it does, we'll handle it later.

~stacyharper a month ago

And no, we will definitely not use * as output name or <...> as input name. Those scaling value or input config are very specific to some screen size or phone buttons.

~begs a month ago

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.

~stacyharper a month ago*

This way Sxmo would be unusable out of box on any device other than PinePhone, so I disagree.

Why that ? I can have this sway config without any issue.

input superfoobar {
→   repeat_delay 200 
→   repeat_rate 15 
→   xkb_file /usr/share/sxmo/sway/xkb_mobile_normal_buttons 
}

If superfoobar keyboard is not detected by Sway, then it is just ignored. The same thing occurs for outputs. Why trying to detect material if Sway just already do it ?

~begs a month ago

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.

~stacyharper a month ago

No we just can use identifier everywhere and config will not conflict never. Atm the pinephone output name is bugged but we should focus more on fixing that.

I want to remove device dedicated shit, not add more of them.

~stacyharper a month ago

And when I say "device dedicated shit" I mean "device dedicated env variable shit"

~begs a month ago

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)

~stacyharper a month ago

~begs I already tried to explain to you why there is no issue and why we will not "handle only pinephone".

So I'll try one last time and then I'm sorry but I'll just ignore this issue :(

Here in sxmo, we just have to setup basic default configs for outputs and inputs. Which mean:

  • a default scaling
  • default inputs delay values
  • bind buttons to our inputhandler

And to handle this, we dont need some complexe findout or probing. We dont need some lazy loading things.

Sway offer a simple way to configure all those output and inputs. We only need a sxmo scoped file that we will include in the user sway config.

Why do you want more ? Why does it looks not enough to you ? Which usecase does it forget ?

I'm sorry, I really dont see the point

~begs a month ago

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.

~stacyharper a month ago

  • 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.

We Will Duplicate Those For Other Devices

~begs a month ago

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

Register here or Log in to comment, or comment via email.