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:
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.
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.
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.
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.
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.
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.
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 ?
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 dobindsym --input-device
, as we don't know actual input devices used.
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.
And when I say "device dedicated shit" I mean "device dedicated env variable shit"
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)
~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
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.
- 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
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