Cyber Space, sometime in France
Willow Barraco, a french trans lesbian lover.
I write code, freelance and hireable.
If you like what I an doing, please consider supporting it
https://liberapay.com/StacyHarper https://donate.missbanal.net
Comment by ~stacyharper on ~sircmpwn/hare
To work-around this, we have to
export LDFLAGS='-no-pie'
The source that pointed me to the correct direction is https://stackoverflow.com/a/59473090
It looks like the problem come from the Alpine Linux gcc, or the patchs applied to it. Its behavior changed for aarch64, and
-no-pie
which should be the default, isn't.
Comment by ~stacyharper on ~mil/sxmo-tickets
This should help:
Comment by ~stacyharper on ~mil/sxmo-tickets
I also relate proximity lock problems, sometime, randomly. Sometime it works, sometime it doesn't. The problems is that we don't receive the events from the kernel driver.
I also note that I always had and have a screen protector, so I don't think this is related.
Also, recently we change a bit of code about state switching, and how proximity lock interract with this. Now we should alway keep control over the state while screenoff (even with proximity lock on). So if the screen is off, we should just be able to power to unlock it. I hope this help us to mitigate the issue when it happen.
Comment by ~stacyharper on ~mil/sxmo-tickets
Hello,
I'm against this approach. One of Wayland goal is to offer alternatives to avoid this. Openning /dev/uinput permission to the users is basically openning a breach to the user security, cause it make easy to keylog inputs.
Most distro still have to do this, for some programs (aka Steam, aka dotool, etc), but we should all work to close this breach.
In that specific situation, wvkbd is a Wayland program that have a limited scopes as a virtual keyboard, and the protocol fits nicely.
I would prefer to work, and implement zwp-virtual-keyboard-manager-v1 in KWin, than to fallback to uinput :)
Willow
Comment by ~stacyharper on ~mil/sxmo-tickets
"~proycon" outgoing@sr.ht wrote:
On Mon Jul 3, 2023 at 3:41 PM CEST, ~magdesign wrote:
we could add a variable in deviceprofile, telling how many characters are hidden by the notch. e.g. NOTCH="9" would add 9 characters between battery and wifi symbol like this: sxmobar -a notch 35 ooooooooo
That sounds like the easiest solution to me too. I do worry if sufficient space remains for all our icons then.
I'm pretty much sure we can configure a blank space in Sway. This avoid the problem, without being satisfying. Only the composer could handle this.
Comment by ~stacyharper on ~mil/sxmo-tickets
Pipewire 0.3.78 solve this: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3414
Wait for this to land: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50389
Then you can upgrade Pipewire using the tip from ~noneofyourbusiness
doas apk add pipewire>0.3.70-r1
, or removing thepipewire=
line from/etc/apk/world
.I also applied a patch on sxmo-utils master to fix the speaker mode being disabled after a call (I hope).
I mark this as resolved, let's keep an eye on call audio issue and re-open if something still looks wrong.
REPORTED
RESOLVED FIXEDComment by ~stacyharper on ~mil/sxmo-tickets
I'm in favor of moving the .sh files into a /usr/share/sxmo/deviceprofile or similar folder. If anyone would send a patch in this regard, it would be very much appreciated.
Comment by ~stacyharper on ~mil/sxmo-tickets
I reproduced and reported this here: https://gitlab.com/mobian1/callaudiod/-/issues/30
Comment by ~stacyharper on ~stacyharper/fossbill
REPORTED
RESOLVED CLOSEDComment by ~stacyharper on ~stacyharper/fossbill
REPORTED
RESOLVED CLOSED