~mil/sxmo-tickets#339: 
SWMO - Wayland Version of SXMO

Okay, thats official : SXMO will run over Wayland !

The idea is to have main sxmo features over Sway.

  • dwm config -> sway config
  • dmenu -> bemenu
  • svkb -> wvkbd
  • lisgd -> lisgd (ya)
  • conky -> conky (conky are working to have Wayland support)

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 :

  • Make lisgd wayland compatible

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

  • Add a bemenu centered mode

Done, still not merged yet

  • Add bemenu touch support

WIP

  • Upgrade wvkbd

Add the features and layouts from svkbd we love.

  • Probably so much things I'll add later
Status
REPORTED
Submitter
~stacyharper
Assigned to
No-one
Submitted
2 months ago
Updated
10 days ago
Labels
feature high-priority

~stacyharper 2 months ago

If you guys want to try it : https://git.sr.ht/~mil/sxmo-utils/log/swmo

~anjan 2 months ago

We could also start by packaging wvkbd for alpine linux:

https://github.com/jjsullivan5196/wvkbd

~stacyharper 2 months ago

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.

Craig Lynch 2 months ago · edit

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?

~stacyharper 2 months ago

Would using djpohly's dwl (on github) be more in spirit with SXMO?

Yes, when it is ready. Definitely not yet.

~stacyharper 2 months ago*

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.

~mil 2 months ago

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.

~anjan 2 months ago

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.

~stacyharper 2 months ago*

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

~stacyharper 2 months ago*

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.

~stacyharper 2 months ago*

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 !

heidi a month ago · edit

Hello, do you plan to replace the X11 completely and if so, in the 1.6 release?

~proycon a month ago

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

~kavuskazian a month ago

What is the benefit of using Wayland over X11?

~stacyharper a month ago

What is the benefit of using Wayland over X11?

Everything is more smooth and more easy to develop.

~mil a month ago*

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

~stacyharper a month ago

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.

~stacyharper a month ago

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 :

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)

~kavuskazian a month ago

Won't Wayland use more battery? I've heard it constantly redraws the screen every frame, instead of only drawing changes.

~stacyharper a month ago

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.

~kavuskazian a month ago

Okay well that's all fine then!

Also, why not postmarketos-ui-sxmo and postmarketos-ui-swmo?

~stacyharper a month ago

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 :)

~kavuskazian a month ago

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?

~stacyharper a month ago

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.

~kavuskazian a month ago

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.

~stacyharper a month ago

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.

~kavuskazian a month ago

Oh! I see. Is there a timeframe for when this will be available in pmbootstrap?

~kavuskazian a month ago

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.

~stacyharper a month ago

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)

~stacyharper a month ago

Oh ! And if someone wanna work on Conky, that will be something I'll not have to do !

https://github.com/brndnmtthws/conky/issues/56

~stacyharper a month ago

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

~ptrckd a month ago

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.

~murks a month ago

I second that request. The sooner someone writes a nice guide the less often you'll have to answer the same questions :]

~stacyharper a month ago

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 ?

~ptrckd a month ago

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 backend

Thanks for your help.

~stacyharper a month ago

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

~ptrckd a month ago

Someone on IRC suggested installing elogind. I did that and now it is booting into sway.

~begs a month ago

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

~peterjohnhartman a month ago

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.

~stacyharper a month ago

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

~stacyharper a month ago

~saba mentionned that rollback busybox make this script to works again.

I openned an issue to track this in aport :

https://gitlab.alpinelinux.org/alpine/aports/-/issues/12960

~the01player a month ago

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!

~stacyharper a month ago

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.

~the01player a month ago

Very cool, I assumed as much but wasn't sure about that. Thanks!

~kavuskazian a month ago

I'd like to try SWMO but I can't find any instructions to install it. Is there any documentation?

Daniel Finsler a month ago · edit

yes, me too. There’s even a menu to switch WM but sxmo will say ‚your device looks not ready yet‘. buhuhuh ;(

~petersen77 a month ago

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.

~anjan a month ago

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!

~murks a month ago

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:

  1. Rotation seems to totally break gestures.
  2. Keyboard is covered by menu under some circumstances. I'll try to reproduce it reliably, not sure yet when this happens.
  3. 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.
  4. Compose + o lacks the letter ö

~proycon a month ago

On 21-09-18 05:27, ~murks wrote:

4. Compose + o lacks the letter ö

Well caught, fixed this one in my wvkbd master branch now.

--

Maarten van Gompel (proycon) https://proycon.anaproy.nl

~murks a month ago

Thanks :]

Some more issues regarding the keyboard.

  1. 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.
  2. 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.
  3. 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.

~proycon a month ago

On 21-09-19 10:17, ~murks wrote:

Thanks :]

Some more issues regarding the keyboard.

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

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

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

~kavuskazian a month ago

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?

~stacyharper a month ago

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

~murks a month ago

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.

~dinkocar 30 days ago

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:

  1. Surf does not work when switching from x11 to wayland. It has to be started with GDK_BACKEND=x11 and the it works again.
  2. 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.

~begs 30 days ago

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.

~stacyharper 30 days ago

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

~murks 28 days ago

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.

~stacyharper 28 days ago

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

~murks 28 days ago

Why would you want that?

~murks 27 days ago

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.

~xgem 27 days ago

Swmo is working well at the present, very much enjoying daily use.

One observation: attempting to use the Dialer while having the modem hardware disabled will cause the swipe gestures to stop working. Texts and other Config>Modem* settings do not appear to affect gesture input.

~stacyharper 27 days ago

Why would you want that?

You are playing with menu and you receive a call by example

Craig Lynch 26 days ago · edit

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

~murks 25 days ago

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.

~edp17 23 days ago

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.

~stacyharper 23 days ago

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

~edp17 22 days ago

Thanks, that was the issue. Now I have swmo running on my pinephone. :)

~edp17 22 days ago

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

~proycon 22 days ago

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

~edp17 21 days ago

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. :))

~proycon 21 days ago

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

~edp17 20 days ago

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. :)

~murks 11 days ago*

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.

~stacyharper 11 days ago

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 ?

~earboxer 10 days ago

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)

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