#723 compilation error when linking to libc on arm 8 hours ago

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.

#576 Proximity lock doesn’t work with screen protector 10 days ago

Comment by ~stacyharper on ~mil/sxmo-tickets

This should help:

https://lists.sr.ht/~mil/sxmo-devel/patches/44825

#576 Proximity lock doesn’t work with screen protector 10 days ago

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.

#588 wvkbd: falling back to uinput device when zwp-virtual-keyboard-manager-v1 is unavailable 13 days ago

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

#494 Notch support a month ago

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.

#583 placing call with pipewire 3.77? a month ago

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 the pipewire= 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 FIXED

#582 deviceprofile should be manifested in INI files a month ago

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

#583 placing call with pipewire 3.77? a month ago

Comment by ~stacyharper on ~mil/sxmo-tickets

I reproduced and reported this here: https://gitlab.com/mobian1/callaudiod/-/issues/30

#28 Editable bill style a month ago

Comment by ~stacyharper on ~stacyharper/fossbill

REPORTED RESOLVED CLOSED

#29 brand logos a month ago

Comment by ~stacyharper on ~stacyharper/fossbill

REPORTED RESOLVED CLOSED