Comment by ~magdesign on ~mil/sxmo-tickets
thanks 😘
on ~mil/sxmo-tickets
On Wed Feb 5, 2025 at 9:12 PM CET, ~magdesign wrote:
i have the Tianma Panel. we can also remove the line completely and it still seems to work. when you compare with another sdm845 deviceprofile, like the OP6, the export SXMO_MONITOR="DSI-1" line works also there..
Yeah, I think you're right. I've prepared and submitted a patch with your fix.
Comment by ~magdesign on ~mil/sxmo-tickets
i have the Tianma Panel. we can also remove the line completely and it still seems to work. when you compare with another sdm845 deviceprofile, like the OP6, the export SXMO_MONITOR="DSI-1" line works also there..
on ~mil/sxmo-tickets
On Wed, Feb 05, 2025 at 07:48:01PM +0000, ~proycon wrote:
On Tue Feb 4, 2025 at 5:28 PM CET, ~magdesign wrote:
the /usr/bin/sxmo_deviceprofile_xiaomi,beryllium.sh is broken, to get it working on both panel variants we need to replace:
export SXMO_MONITOR="0:0:Novatek_NT36XXX_Touchscreen"
with:
export SXMO_MONITOR="DSI-1"
Thanks. Do we have users of both panel types to confirm this works? Which one are you on? I know @anjan has one too (I don't).
While I do not have these devices, it appears that magdesign is right here, since the variable is actually set to a touchscreen node, which is unlikely to be correct.
Looks like a simple typo.
on ~mil/sxmo-tickets
On Tue Feb 4, 2025 at 5:28 PM CET, ~magdesign wrote:
the /usr/bin/sxmo_deviceprofile_xiaomi,beryllium.sh is broken, to get it working on both panel variants we need to replace:
export SXMO_MONITOR="0:0:Novatek_NT36XXX_Touchscreen"
with:
export SXMO_MONITOR="DSI-1"
Thanks. Do we have users of both panel types to confirm this works? Which one are you on? I know @anjan has one too (I don't).
Ticket created by ~magdesign on ~mil/sxmo-tickets
the /usr/bin/sxmo_deviceprofile_xiaomi,beryllium.sh is broken, to get it working on both panel variants we need to replace:
export SXMO_MONITOR="0:0:Novatek_NT36XXX_Touchscreen"
with:
export SXMO_MONITOR="DSI-1"
Comment by ~magdesign on ~mil/sxmo-tickets
Lets just leave it open for the moment so people find the workaround if needed.
Not quite sure if the problem is on the wifi driver side and might be fixed one day from there...
PMF stands for 'Protected Management Frames'. Without PMF, management frames can be spoofed or tampered with, leading to attacks such as de-authentication attacks, where an attacker forces a client to disconnect from the network.
Which does not sound super crucial for a hotspot on the phone.
Comment by ~magdesign on ~mil/sxmo-tickets
@dataaja95 we support various window managers but yes, sxmo on sway works very well. i messed with numen and piper-tts the last few days and realized that we first need to have stable audio in/output...
Ticket created by ~magdesign on ~mil/sxmo-tickets
The current shipped sxmo_record.sh script to record audio files seems to be broken. The quirks and workarounds in this script are not valid anymore. Here is a proposal of a script which records audio as wav, and if ffmpeg is installed also in opus. The input selection is made via sxmo_audio.sh When callaudio finally is fixed, i might add the option to record calls with both parties. Get it here: https://codeberg.org/magdesign/sxmop6/src/branch/main/bin/sxmo_record.sh
proposals and feedback welcome!
on ~mil/sxmo-tickets
On Sun Nov 10, 2024 at 5:36 AM CET, ~magdesign wrote:
Thanks for your replay. there is one bug in this patch! when there exists a WEP secured wifi, it will not be able to connect. the correct and tested line to fix all the trouble is:
NAMES=$(echo "$SSID" | awk -F ' ' '{ $NF=""; print $0 }' | sed 's/[[:space:]]*$//' | sed 's/ WPA\w//g')
Thanks, I sent a v2 patch with this fix included: https://lists.sr.ht/~mil/sxmo-devel/patches/55964