Okay, thats official : SXMO will run over Wayland !
The idea is to have main sxmo features over Sway.
We should abstract some WM talking code to make it compatible over multiple environment. We already got a sxmo_dmenu.sh by example. We should use more of those scripts.
The things to do :
It actually only relly on X11 to fetch screen width and height. It should be very easy to detect environment variable and fetch the Wayland output width / height also.
For my tests, I removed completly w/h probing and give those information with arguments
Done, still not merged yet
WIP
Add the features and layouts from svkbd we love.
If you guys want to try it : https://git.sr.ht/~mil/sxmo-utils/log/swmo
We could also start by packaging wvkbd for alpine linux:
The sway config bindsym will disallow double/triple button inputs:
As we got lisgd with control over lock state, keyboard, menu open/close, killing windows. As our menus got touch screen support. As you can use your finger to re-organise the layout as you want As we got a idle handler that could put the phone back to lock/off/crust.
In my opinion, this is not an issue and we should just take this opportunity to simplify the button inputs behaviors.
Would using djpohly's dwl (on github) be more in spirit with SXMO?
Granted, some things aren't quite there yet, screenlocking and such but perhaps as it develops further?
Would using djpohly's dwl (on github) be more in spirit with SXMO?
Yes, when it is ready. Definitely not yet.
Here my progress :
My current choice for buttons inputs is :
- Vol up : appmenu
- Vol down : toggle sway layout (splitv, splith, tabbed)
- Power : Manage lock state (futher details later)
When the menu is running :
- Vol up : Page prev
- Vol down : Page next
I use those bind for bemenu cause of my progress on bemenu :
- I patched bemenu to have a -c (center) argument. It is now upstream.
- I added pointer and touch support on Wayland (mouse and touch screen). BUT I couldn't find a way to switch page with touches. I hope to find a way soon or later :( (details here :https://github.com/Cloudef/bemenu/pull/200)
About the lock state:
I tried to manage it with only one button (-> mean power button)
- Unlocked -> lock and crust
- Not unlocked -> Unlock
I fixed the postwake script and adapted the inputhandler to make uncrusting easy
- crusted -> locked and blinking for 5 seconds. going back to crust after those 5 seconds
- locked and blinking -> unlock
We also got swayidle that is configurable with a new configuration entry. You can configure after how much idle time you lock, off and crust. 0 mean never. I really recommend 30s off. I'm not fan of auto-crust.
I also changed the bottom left gesture to either lock or off the screen. It depends on the presence or not of a focused window. This mean that if you are looking at a video, then this gesture will just lock the screen. If you kill your window and use this gesture, then it will off the screen.
I also adapted most of the inputhandler entries. I used a new sxmo_type.sh.
Sounds like nice progress.
Having never used Wayland on my own successfully and having some other projects running currently, unfortunately I can't be much help here. But I support this effort and would like to help perhaps in some minor ways. Ideally we'd make sxmo-utils done in a X/Wayland both compatible way which it sounds like there's already work ongoing on. I'd say switching to bemenu in Sxmo (X) could also help things (since bemenu is cross-compatible).
I do wonder if there's something like xbindkeys or sxhkd for Wayland? I'd be happy to take a stab at building multikey (double/triple tap) functionality out in a Wayland compatible keybinding daemon. I'd have some learning to do but happy to take this on. In a keybinding daemon is probably the right place to do it as that parallels with lisgd (e.g. in having separate daemons rather then building into WM). I kind of doubt sway would take an upstream multikey patch.
I don't think we should just cut multikey functionality. That's my favorite feature of Sxmo, or if we do I don't think itd be Sxmo as I thought of it. I know there are other people that rely on this functionality too.
Having never used Wayland on my own successfully and having some other projects running currently, unfortunately I can't be much help here. But I support this effort and would like to help perhaps in some minor ways. Ideally we'd make sxmo- utils done in a X/Wayland both compatible way which it sounds like there's already work ongoing on. I'd say switching to bemenu in Sxmo (X) could also help things (since bemenu is cross-compatible).
+1 to dropping dmenu for bemenu. Having fewer branches specific to wayland and X is ideal. This is as long as bemenu has all the features our fork of dmenu has.
Additionally, dmenu hasnt had a new release but if it did, merging all of our patches atop the new release would be a pain. As such, we should try to upstream as much as possible when using wayland utilities.
I do wonder if there's something like xbindkeys or sxhkd for Wayland? I'd be happy to take a stab at building multikey (double/triple tap) functionality out in a Wayland compatible keybinding daemon. I'd have some learning to do but happy to take this on. In a keybinding daemon is probably the right place to do it as that parallels with lisgd (e.g. in having separate daemons rather then building into WM). I kind of doubt sway would take an upstream multikey patch.
Ya we should look into turning the multikey logic into a seperate program rather than building it into the wm. This would follow the unix philosophy and allow other wms to use our method of binding volume keys to stuff other than volume control.
Moreover, it's easier for users to modify a small program to fit their needs than a large program.
Additionally, this program would resolve issue #340.
Having never used Wayland on my own successfully and having some other projects running currently, unfortunately I can't be much help here. But I support this effort and would like to help perhaps in some minor ways. Ideally we'd make sxmo- utils done in a X/Wayland both compatible way which it sounds like there's already work ongoing on. I'd say switching to bemenu in Sxmo (X) could also help things (since bemenu is cross-compatible).
Yes that the goal. We will still offer the sxmo_xinit.sh. We just add sxmo_winit.sh and will make this as default in out postmarketos ui package.
Bemenu is a greatter alternative for both X and W. It is also ncurse compatible. We now use it in SSH mode :D Using this on Wayland solve some of our issues :
- Already openned menu
- Tring to open it when the screen is off
- Performance issues !
I do wonder if there's something like xbindkeys or sxhkd for Wayland? I'd be happy to take a stab at building multikey (double/triple tap) functionality out in a Wayland compatible keybinding daemon. I'd have some learning to do but happy to take this on. In a keybinding daemon is probably the right place to do it as that parallels with lisgd (e.g. in having separate daemons rather then building into WM). I kind of doubt sway would take an upstream multikey patch.
I don't think we should just cut multikey functionality. That's my favorite feature of Sxmo, or if we do I don't think itd be Sxmo as I thought of it. I know there are other people that rely on this functionality too.
I handled the multikey in a dedicated script late this night. I would be happy to have your review on this. I am very proud, it works very well ! It also support holding presses :D
The script
https://git.sr.ht/~mil/sxmo-utils/tree/swmo/item/scripts/core/sxmo_multikey.sh
It is used here
https://git.sr.ht/~mil/sxmo-utils/tree/swmo/item/configs/appcfg/sway_template#L85
I also mention a thing about the multikey script :
I configured vol and power button repeat config here : https://git.sr.ht/~mil/sxmo-utils/tree/swmo/item/configs/appcfg/sway_template#L54
This config prevent the multikey script to be overspamed. We dont need super high repeat values for those buttons anyway.
So to be clear, at this time, with the swmo branch of sxmo-utils (and dependencies) :
Using sxmo over Sway feels exactly the same as using the 1.5.0 version.
The only things that miss atm is a way to switch pages of bemenu with touch. That is my next goal !
Hello, do you plan to replace the X11 completely and if so, in the 1.6 release?
On 21-08-22 04:41, heidi wrote:
do you plan to replace the X11 completely and if so, in the 1.6
The default for 1.6 will probably be Wayland, the way things are developing currently. But we are definitely NOT dropping X11 support. You can still run SXMO with X11+dwm+dmenu+st+svkbd , also in the future.
--
Maarten van Gompel (proycon) https://proycon.anaproy.nl
What is the benefit of using Wayland over X11?
What is the benefit of using Wayland over X11?
Everything is more smooth and more easy to develop.
I handled the multikey in a dedicated script late this night. I would be happy to have your review on this. I am very proud, it works very well ! It also support holding presses :D The script https://git.sr.ht/~mil/sxmo-utils/tree/swmo/item/scripts/core/sxmo_multikey.sh
Cool - yeah I tend to reach for C possibly too quickly - if it works in sh why not. I tested out a bit the powerbutton single/double tap for terminal/keyboard, and that works well. Vol down hold for kill I was having a bit of problems with but maybe my hardware buttons not sure.
Hello, do you plan to replace the X11 completely and if so, in the 1.6 release?
The default for 1.6 will probably be Wayland, the way things are developing currently. But we are definitely NOT dropping X11 support. You can still run SXMO with X11+dwm+dmenu+st+svkbd , also in the future.
I think it was mentioned somewhere the idea of maintaining compatibility with X too, and having two pmbootstrap options / UIs which sounds like a reasonable way to approach this. So you'll be able to install on pmbootstrap either:
- postmarketos-ui-sxmo-dwm
- postmarketos-ui-sxmo-sway
Cool - yeah I tend to reach for C possibly too quickly - if it works in sh why not. I tested out a bit the powerbutton single/double tap for terminal/keyboard, and that works well. Vol down hold for kill I was having a bit of problems with but maybe my hardware buttons not sure.
I made a little patch over it to make is more pleasant to use. I had too much chained action with holded buttons. We might prefer a more generic and robust solution on Wayland but for the moment, it is good enough.
I too like this idea. I think it was mentioned somewhere the idea of having two pmbootstrap options / UIs which sounds like a reasonable way to approach this. So you'll be able to install on pmbootstrap either:
- postmarketos-ui-sxmo-dwm
- postmarketos-ui-sxmo- sway
Yeah both could co-exists. But we might advertise more the Wayland solution cause it will have less issues and be more pleasant to use than the Xorg alternative.
Plus, if we offer a lock solution in the future on Wayland, it will not be backward compatible with the Dwm version.
To keep this updated :
The dedicated refactorisation has been merged in all Sxmo repos (except sxmo-build). So right now, sxmo is compatible dwm and sway.
To install the Sway version, you still have to use the swmo branch on sxmo-build. Drop completly the builddir and start the script. It will build new dependencies that are not upstream nor released yet and also install new tools that we use.
Things still not upstreamed :
bemenu (patches for touch support, mouse support, center mode) https://github.com/Cloudef/bemenu/pull/200
sway (implement seatop_touch, needed to have correct touch position while leaving the initial surface) https://github.com/swaywm/sway/pull/6455
Things to do :
- Move light from community to main (we now rely on this to change brightness. It is simplest and more robust and compatible X11 and Wayland)
- Rocketboost wvkbd (our new virtual keyboard. We already are working on it with ~proycon. It should not be hard to have a layout as complete than our svkbd ones)
Won't Wayland use more battery? I've heard it constantly redraws the screen every frame, instead of only drawing changes.
Won't Wayland use more battery?
No
I've heard it constantly redraws the screen every frame, instead of only drawing changes.
You missunderstood. It redraw when the client say it is ready to redraw. And it got damage tracking which allow it to redraw only some parts. Wayland rely on a protocol that allow frame perfect drawing. Which mean less drawing issues.
It definitely not redraw the screen every frame.
Okay well that's all fine then!
Also, why not postmarketos-ui-sxmo and postmarketos-ui-swmo?
Also, why not postmarketos-ui-sxmo and postmarketos-ui-swmo?
I guess we could hypothetically use other Wm in the future. I dont want to handle 50 of them actually. Having boths could be enough yes :)
Are there even any other than X and Wayland?
I do like that sway is i3 compatible. That's what I use on all my systems.
Will I be able to customise the layout of wvkbd like I have with svkbd?
Are there even any other than X and Wayland?
Probably !
I do like that sway is i3 compatible. That's what I use on all my systems.
Will I be able to customise the layout of wvkbd like I have with svkbd?
Yes of course ! We can even do more cause we will have dynamic keymaps. It mean we can bind which or which key on Shift, Algr combinations.
I see! One thing I miss from Android is being able to hold down a key for a little longer, and it makes a different symbol when I let go.
I see! One thing I miss from Android is being able to hold down a key for a little longer, and it makes a different symbol when I let go.
We already got that in svkbd. For wvkbd we will use another approach. We will add a compose key. Pressing compose + e will open all e derivates. This way we could still hold e to spam this key as with any keyboard.
Oh! I see. Is there a timeframe for when this will be available in pmbootstrap?
Also is there a way to get the holding down buttons behavior back? I have an overlay with F-keys and stuff on it that I get when I hold down on the number keys.
To keep things updated !
We works a lot on wvkbd with ~proycon. We now have a fully functionnal keyboard with layouts as complexe than svkbd ones.
We also bringed some additional features from svkbd
- Signals to hide/show the keyboard (not used yet)
- Automatic detection of landscape mode and switch to another set of layers and height
~proycon created a MR in github :
https://github.com/jjsullivan5196/wvkbd/pull/2
From the last update:
- Light is now in community. But we still need edge to access it
- We may have fixed the bemenu installation from sxmo-build (we had issues with lib linking)
Things to do:
Not that much now ! :D
- Create a visual feedback in bemenu for gesture like we got with sxmo-dmenu (to notice we will scroll, page down, last page, etc)
- Find a way to add keybinds to bemenu to bind VolUp/Down and Power buttons. This will probably require us to bring a configuration file to bemenu which it doesnt have already.
- Merge things upstream and wait a release ! (bemenu, sway, wvkbd)
Oh ! And if someone wanna work on Conky, that will be something I'll not have to do !
I recently I did :
- Create a visual feedback in bemenu for gesture like we got with sxmo-dmenu (to notice we will scroll, page down, last page, etc)
- Add a no spacing mode to bemenu
Both are in my repo and are builded with sxmo-build. I'll add the missing argument to sxmo_dmenu.sh. Rebuild to make your installation compatible
What are the steps to get swmo up and running from an existing installation?
I cloned the sxmo-build repo and switched to the swmo branch. I had to install eudev-dev to get the libudev.h headers and I added the testing repo to /etc/apk/repositories to be able to download the light package. After doing that the sxmo_build_all.sh script ran successfully.
After restarting my pinephone I'm stuck at a log in prompt on the tty. Before restarting I did see the option to switch window managers.
I second that request. The sooner someone writes a nice guide the less often you'll have to answer the same questions :]
I cloned the sxmo-build repo and switched to the swmo branch. I had to install eudev-dev to get the libudev.h headers and I added the testing repo to /etc/apk/repositories to be able to download the light package. After doing that the sxmo_build_all.sh script ran successfully.
Thats should be enough.
If your stuck on tty then there is an issue with tinydm somewhere. Does it worked before Sway ? Was you booting directly to Sxmo without the xdm menu ?
Everything was working fine before I rebooted.
Was you booting directly to Sxmo without the xdm menu ?
No, I was booting into the graphical login prompt.
Using jumpdrive I tried to find some relevant logs.
cat .local/state/tinydm.log --- tinydm --- Date: Sun Aug 29 08:03:07 PDT 2021 Session: /usr/share/wayland-sessions/swmo.desktop Exec: sxmo_winit.sh --- /usr/bin/vis /bin/ash
cat .init.log Found hardware: "PinePhone" "" "" "" "" Hardware is initialized using a generic method alsa-lib main.c:1402:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -2 No state is present for card sun50ia64hdmi alsa-lib main.c:1402:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -2 Found hardware: "sun50i-a64-hdmi" "" "" "" "" Hardware is initialized using a generic method No state is present for card sun50ia64hdmi
cat .cache/sxmo/sway.log 00:00:00.005 [ERROR] [wlr] [backend/session/logind.c:537] User has no sessions 00:00:00.005 [ERROR] [wlr] [backend/session/logind.c:598] Couldn't find an active session or a greeter session 00:00:00.007 [ERROR] [wlr] [backend/session/direct.c:171] Cannot open /dev/tty: No such device or address 00:00:00.008 [ERROR] [wlr] [backend/session/session.c:147] Failed to load session backend 00:00:00.008 [ERROR] [wlr] [backend/backend.c:294] Failed to start a DRM session 00:00:00.008 [ERROR] [sway/server.c:55] Unable to create backendThanks for your help.
I think you lack the seatd daemon. It should be installed and configured by sxmo-build but you should try to see if it works correctly.
Or maybe you dont use Alpine. We dont configure other distros atm
Someone on IRC suggested installing elogind. I did that and now it is booting into sway.
Sway/wlroots have recently dropped logind in favor of much simplier seatd, so seatd is prefered.
I had swmo working earlier this week, then it stopped and would not boot. I do not have elogind. The culprit in my case was the change in swmo_winit.sh from #!/bin/bash to #!/usr/bin/env sh. Reverting it back to #!/bin/bash allows sway to launch.
FWIW, in my debugging, it would 'hang' at this line in sxmo_winit.sh.
- "$(dirname "$0")/sxmo_common.sh"
I added some debug echoes and it would completely load sxmo_common.sh but then would not continue the sxmo_winit.sh script ot the next line.
I had swmo working earlier this week, then it stopped and would not boot. I do not have elogind. The culprit in my case was the change in swmo_winit.sh from #!/bin/bash to #!/usr/bin/env sh. Reverting it back to #!/bin/bash allows sway to launch.
I dont understand. This script just never had /bin/bash
FWIW, in my debugging, it would 'hang' at this line in sxmo_winit.sh.
- "$(dirname "$0")/sxmo_common.sh"
I added some debug echoes and it would completely load sxmo_common.sh but then would not continue the sxmo_winit.sh script ot the next line.
I still dont know what your issue is o_O I looks like the script just stop itself
~saba mentionned that rollback busybox make this script to works again.
I openned an issue to track this in aport :
Hello, sorry if this is a dumb question or the wrong place to ask. I am just wondering if there will be a performance hit to switch from dwm to sway. Sway seems like a bigger program compared to dwm.
Either way I am excited for wayland sxmo!
I am just wondering if there will be a performance hit to switch from dwm to sway.
I did not noticed anything in this regard. Both looks very light and fast.
Sway seems like a bigger program compared to dwm.
Dwm got a lighter code base than Sway yes. But you actually have to compare Dwm + Xorg versus Sway. And with this regard, I dont think Sway is bigger or bloated.
Very cool, I assumed as much but wasn't sure about that. Thanks!
I'd like to try SWMO but I can't find any instructions to install it. Is there any documentation?
yes, me too. There’s even a menu to switch WM but sxmo will say ‚your device looks not ready yet‘. buhuhuh ;(
Copy the files to your Pinephone from
https://git.sr.ht/~mil/sxmo-build/tree
Make chmod +x to the sh file and start the script. It's really easy.
Hey all! Thanks for all the excitement to try out swmo. The instructions to try out swmo are here: https://git.sr.ht/~mil/sxmo-build
~proycon has done alot of work to improve the script, flags, and documentation in the readme. If you still have trouble with the instructions in the readme, please feel free to ask in the irc. Please send patches to improve the documentation if it's still difficult to install.
Take care and good luck!
Great job on SWMO so far, I think I'll keep it over SXMO. Here is a random assortment of issues I found with it:
- Rotation seems to totally break gestures.
- Keyboard is covered by menu under some circumstances. I'll try to reproduce it reliably, not sure yet when this happens.
- Sometimes the phone can not be woken from crust. Not yet sure how to reproduce, but it seems to happen more when I'm out and about, so it may be caused by some unexpected button presses.
- Compose + o lacks the letter ö
On 21-09-18 05:27, ~murks wrote:
- Compose + o lacks the letter ö
Well caught, fixed this one in my wvkbd master branch now.
--
Maarten van Gompel (proycon) https://proycon.anaproy.nl
Thanks :]
Some more issues regarding the keyboard.
- Some keys print > instead of ?. It looks like whenever you press shift+/ it ends up as >, when you press shift+. it ends up as ?. This is with default st in foot.
- Caps Lock seems to only affect letters, for example with caps lock enabled - ends up as - instead of _. The use case for this is to conveniently type env vars.
- I think it would be nice if caps lock enabled would cause the keyboard to show the shift-modified letters instead of the default letters.
On 21-09-19 10:17, ~murks wrote:
Thanks :]
Some more issues regarding the keyboard.
- Some keys print > instead of ?. It looks like whenever you press shift+/ it ends up as >, when you press shift+. it ends up as ?. This is with default st in foot.
Right! The keymap is a bit altered, I'll update the key label.
Btw, I'm going to do a force-push to the wvkbd master branch because I squashed a number of commits (to make things a bit less messy for upstream merging), this may affect local branches.
- Caps Lock seems to only affect letters, for example with caps lock enabled - ends up as - instead of _. The use case for this is to conveniently type env vars.
I wonder if this is is an internal thing in wayland's virtual keyboard protocol. We do seem to pass the code for CapsLock to zwp_virtual_keyboard_v1_modifiers() and don't really do any special handling for CapsLock ourselves.
- I think it would be nice if caps lock enabled would cause the keyboard to show the shift-modified letters instead of the default letters.
Yes, but only if the previous issue is also solved.
--
Maarten van Gompel (proycon) https://proycon.anaproy.nl
I would like to request an optional mode where you can long-press a key to get a different symbol, which it types when you let go. I would rarely need other layouts if I could do that. Optional of course as I'm sure not everyone would want that since it would prevent key repeating. Are the layouts editable like with svkbd?
I would like to request an optional mode where you can long-press a key to get a different symbol, which it types when you let go. I would rarely need other layouts if I could do that. Optional of course as I'm sure not everyone would want that since it would prevent key repeating. Are the layouts editable like with svkbd?
Yes you can do that using the cmp for compose key
Today rotation works fine for me again. I can only assume that it was some issue with lisgd.
End of list touch scrolling in long menus is a bit broken but there is supposedly a fix in the works. The alternative two-finger touch scrolling is next to unusable for me. Most of the time two fingers get detected as a single touch and on top of that the "natural scrolling" is unintuitive to me. I wonder whether that is something that can be improved, I guess it's a general libinput multitouch thing?
Another thing that bothers me a bit is the width of bemenu. I assume there are large gaps left and right for aesthetic reasons but in many menus we could really use all the space we can get. One example is the contacts. The numbers already take up so much width that there is only about 7-10 letters left for the name.
Hi! I have to say I am impressed with swmo and the performance compared to sxmo. I am not using my pinephone on daily bases, so I don't have many observations, but here are some things that I have noticed about surf:
- Surf does not work when switching from x11 to wayland. It has to be started with GDK_BACKEND=x11 and the it works again.
- Surf context menu does not work. Reason: in sxmo_wm.sh app_id is read from app_id json parameter, which is null in this case. Solution: read app_id from window_properties.instance.
I support the decisions to switch to wayland in 1.6. Great work, thank you all.
Btw, I'd suggest sircmpwn's visurf as a Wayland-native lightweight browser alternative. We may try to integrate it into Sxmo when it is released.
Btw, I'd suggest sircmpwn's visurf as a Wayland-native lightweight browser alternative. We may try to integrate it into Sxmo when it is released.
Yes I already got an eye on it :P
A small bug I noticed is that I somehow managed to get the bemenu pop up twice. They were stacked atop each other with an offset of a few pixels. No idea how I did that.
A small bug I noticed is that I somehow managed to get the bemenu pop up twice. They were stacked atop each other with an offset of a few pixels. No idea how I did that.
Thats not really a bug. It is completly possible to have multiple bemenus
Why would you want that?
I did so far not find a way to type F1-F12. There were one or two situations where it would have been handy, htop, Firefox dev console.
Swmo is working well at the present, very much enjoying daily use.
One observation: attempting to use the
Dialerwhile having the modem hardware disabled will cause the swipe gestures to stop working.Textsand otherConfig>Modem*settings do not appear to affect gesture input.
Why would you want that?
You are playing with menu and you receive a call by example
@murks, I'm able to trigger F1 ~ F12 via the Alternate Greater (shown as AGr) key which is lurking on the number and symbol layout of wvkbd. It is a toggle based key, so make sure to unlatch it before moving on to type anything else.
Thanks Craig, that leaves some things to be desired though. It is not indicated what to press to get F*. Apparently number keys 1-0 work for F1-F10 on some layouts, no clue for F11 and F12 and having to guess these things is not great anyway. Still, it helps with htop at least, thanks.
Hi guys, I had sxmo 1.5 installed and wanted to try swmo.
As Stacyharper suggested, I've done this on device: $ git clone https://git.sr.ht/~mil/sxmo-build $ cd sxmo-build $ ./sxmo_build_all.sh --wayland
Then rebooted and it stuck on the postmarketOS logo. I can access the device from PC via ssh but no GUI started. Is there anything else I need to do to get the GUI? What logs, should I check and where? Thanks.
Then rebooted and it stuck on the postmarketOS logo. I can access the device from PC via ssh but no GUI started. Is there anything else I need to do to get the GUI? What logs, should I check and where? Thanks.
Double check tinydm is working and correctly setted up if you was not using it before
Thanks, that was the issue. Now I have swmo running on my pinephone. :)
Is there a reason why the keyboard layouts are different on sxmo and swmo?
It would be nice if that Alternate Greater (shown as AGr) key is displayed on the first keyboard screen. In place of the Cmp key. (I am not sure what is that for.) This way the AGr would be visible immediately on the screen where the letters and numbers are both there. (It would be useful for using Midnight Commander (mc)).
On 21-09-29 01:46, ~edp17 wrote:
Is there a reason why the keyboard layouts are different on sxmo and swmo?
It would be nice if that Alternate Greater (shown as AGr) key is displayed on the first keyboard screen. In place of the Cmp key. (I am not sure what is that for.) This way the AGr would be visible immediately on the screen where the letters and numbers are both there. (It would be useful for using Midnight Commander (mc)).
The Cmp is a Compose key, and is what we are using on wvkbd to access overlays to type diacritics. Try "Cmp + a" for example and you get an overlay with á à â ä etc... It's a pretty essential key that performs functions you might on normal keyboards do with AltGr. In svkbd, we were using overlays that were triggered by a long press on a key, in wvkbd we opted to try something different (some people prefer their keys to react fast and want to be able to 'hold them down').
The other reason for the difference is just that we wanted to try to improve upon certain things.
The lack of space always leads to inevitable concessions. Fortunately, it's fairly easy for anybody to make their own layout in either wvkbd or svkbd.
--
Maarten van Gompel (proycon) https://proycon.anaproy.nl
Thanks for explaining a little bit about the keyboard. Now, I understand the purpose of Cmp key and in this case, I definitely don't want to lose it. :) You said fairly easy to make my own layout. Just like with the LED setting, I think this is the best option for me. Especially that I don't use the majority of the current layouts. (e.g. I don't need the emoji, Cyrillic and all the rest "keyboard screens" except the first two.) Could you please suggest a good site where that layout creation is described? Or I should do my own research? :) The svkbd screens were a better fit for my usage. The other thing I spotted is how the 'Sym' key is functioning. It takes me to the "second keyboard screen" where if I press the 'Abc' key I expected to get back to the "first keyboard screen" (similarly to svkbd) but instead, it takes me to the "emoji keyboard screen". (I call them "keyboard screens" because I don't know the proper term. :))
On 21-09-29 02:49, ~edp17 wrote:
Thanks for explaining a little bit about the keyboard. Now, I understand the purpose of Cmp key and in this case, I definitely don't want to lose it. :)
You said fairly easy to make my own layout. Just like with the LED setting, I think this is the best option for me. Especially that I don't use the majority of the current layouts. (e.g. I don't need the emoji, Cyrillic and all the rest "keyboard screens" except the first two.)
(I call them "keyboard screens" because I don't know the proper term. :))
We call them layers :)
But there already is an option for selecting specific layers on startup (the -l option) so you can easily omit the emoji, cyrillic and arabic layers. svkbd also has a similar feature. This is documented in the README already: https://git.sr.ht/~proycon/wvkbd/tree/master/item/README.md No need to edit the code or recompile for this. In sxmo/swmo arguments to the keyboard can be passed by setting your $KEYBOARD_ARGS environment variable.
Could you please suggest a good site where that layout creation is described? Or I should do my own research? :)
The actual layout editing isn't really documented yet, but should't hopefully be fairly easy to grasp when looking at https://git.sr.ht/~proycon/wvkbd/tree/master/item/layout.mobintl.h
The svkbd screens were a better fit for my usage. The other thing I spotted is how the 'Sym' key is functioning. It takes me to the "second keyboard screen" where if I press the 'Abc' key I expected to get back to the "first keyboard screen" (similarly to svkbd) but instead, it takes me to the "emoji keyboard screen".
The sym/abc key cycles you through all the layers in the order specified (either on the command line with -l or as defined in the code). Same as for svkbd actually.
--
Maarten van Gompel (proycon) https://proycon.anaproy.nl
I was trying to set up wvkbd to use only the "full" and "specific" layers, but somehow managed to break the system. Tinydm stopped and couldn't be started again. I needed to restore a backup to the phone but I only had a backup of sxmo rather than wxmo. So, I'll play with this keyboard setup later, because first trying to work on what I mentioned in #375. :)
Right now I seem to be unable to store new contacts using the menus. I added a contact and it just didn't get stored. Even called the contact at the end of entering it but it just wasn't in there afterwards. Not sure what broke, this used to work in SXMO. EDIT: looking at the contacts.tsv I can guess what happened. For whatever reason contacts are added but without line breaks, essentially breaking the format. There is a suspiciously long number in that line (16 digits, including the + prefix) and I wonder whether it was the cause.
This is completly unrelated to Sway but I can reproduce an error myself:
$ sxmo_validnumber.sh "+33623435461" Error relocating /usr/bin/pn: _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE: symbol not found
But I still can use it as it and it add the contact.
Could you open an issue with additional informations ?
Moved from phosh to swmo, and pretty happy so far. issues:
audio controls (volume and source changing) don't work. (even after installing alsa-utils) sxmo-audiocurrentdevice.sh outputs 'amixer: Unable to find simple control' for 'Earpiece',0 'Headphone',0 'Line Out',0
Bluetooth menu shows previously configged devices, but connecting doesn't work; sxmo_bluetoothmenu.sh gives Failed to set power on: org.bluez.Error.Busy (maybe this is hw related, since sometimes in phosh the bluetooth wouldn't work after wakeup)
~mil asked about sxhkd for wayland. I tried hacking on it tonight but it turns out it might not be possible:
https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html
Hi, thanks for bringing us SWMO, having sway driving my phone was a goal for me when buying the pp but I had sticked with phosh (running sway ocasionally inside ...)
I decided to try it with a SIM through the weekend and have since sticked with it ;). So far I have not encountered too many hassles, it is even better (for me) in many points.
One issue I have though is that by default, when I miss a call, the phone stays unlocked. The workaround I found was to modify the missed_call hook to lock the phone through "sxmo_screenlock.sh lock". Now it unconditionally locks the phone after a missed call, but I find it more convenient than letting it unconditionally unlocked (and draining the battery).
Hi, thanks for bringing us SWMO,
Hello !
having sway driving my phone was a goal for me when buying the pp but I had sticked with phosh (running sway ocasionally inside ...)
Yeah me to :D
I decided to try it with a SIM through the weekend and have since sticked with it ;). So far I have not encountered too many hassles, it is even better (for me) in many points.
Thats nice to read !
One issue I have though is that by default, when I miss a call, the phone stays unlocked.
That is not the expected behavior :( As the phone stop to ring and the incoming call menu shut down (missed call), the proximity lock should bring back sxmo to the initial state when stopped (very probably off). Then the sxmo_lock_idle should bring the phone back to crust after ~ 8 seconds.
Is it the workflow you experienced ?
Atm I dont really see what can go wrong but I'll keep this report in mind.
The workaround I found was to modify the missed_call hook to lock the phone through "sxmo_screenlock.sh lock". Now it unconditionally locks the phone after a missed call, but I find it more convenient than letting it unconditionally unlocked (and draining the battery).
That should not cause issues but that not the smoother way to handle it ya
Thanks for such quick reply ;)
Is it the workflow you experienced ?
No, I've reverted the missed call handler and try calling my phone whiled locked (and screen down this time for the proximity sensor). After 10s the phone screen was on.
Atm I dont really see what can go wrong but I'll keep this report in mind.
Agreed, I can't assure you everything is right on my phone (this was my first install and my mind was more on toying with it than using it for real ;) ). If others report the same issue it might be interesting to dig more into this. If I happen to make a "clean" install I'll report on the problem. For now I'm happy with what I have ;)
Hi, seems the issue is solved. My installation of swmo was probably outdated (I think I did it last week with sxmo_build ...)
Received an update through pmos edge channel today that changed some things (mostly on the behaviour of the keys). It happens that I do not have issues with missed calls anymore ...
We choosed to release our own sxmo-bemenu and sxmo-sway packages until our works is upstreamed.
We also have an issue with wayout with the master version of sway we use (should maybe have a dedicated ticket)
I'd like to continue futher discussion in dedicated tickets cause this one is way to huge to follow and to use.