Eindhoven, the Netherlands
See my homepage at https://proycon.anaproy.nl for further details and contact info. Projects also at https://codeberg.org/proycon
Comment by ~proycon 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 ~proycon on ~mil/sxmo-tickets
Thanks for the write-up, I agree that this is an important area where we should really focus to optimize things a bit better, ideally without adding much extra complexity.
- Run a daemon that monitors the current window and precomputed as much as possible for the contextmenu / inputhandler. (I want there to be a better way, maybe we can optimize sway's ipc?).
I see what you mean. We shouldn't focus on just sway here though but find something that would also benefit dwm and the upcoming i3 and river integrations. An extra daemon that precomputes some things and holds some states might work. We have to be wary of things that continuously poll for state and perhaps take a more event-driven approach. As things grow I think the main challenge is keeping it as simple and clear as possible.
- Have lisgd execute actions before the touch up event. Proof of concept: https://lists.sr.ht/~mil/sxmo-devel/%3C20240508193041.334855-1-aren@peacevolution.org%3E.
Interesting experiment, I had missed that one. I wonder which of the existing gestures this would break adjustement (because they would fire prematurely).
- Update menus without closing and reopening them (#6)
Would be nice, but do any of the menu backends support such a thing?
- Evaluate conditional menu entries in parallel
Sounds good, I worry about the code complexity though... Also, if multiple cores start to fire up at once then some other background tasks may perhaps have a more noticable stutter? (I'm thinking about audio for one).
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.
Comment by ~proycon 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).
Comment by ~proycon on ~mil/sxmo-tickets
On Fri Dec 20, 2024 at 1:29 PM CET, ~baroque0 wrote:
When your pocket DDoSes peanutbutter! Device gets warm and battery drains while it doesnt go back to suspend.
Hmm... If it doesn't go back to suspend that means it very regularly receives keeps receiving touches right? Otherwise it should have suspended after a while again.
Steps to reproduce:
- Turn device on while on suspend.
- insert back in pocket and make sure it is pressed against your.
- resume a normal life.
-> a high number of inputs will be registered, thus triggering the red screen of no-input.
-> if -p option has been used, red time will increase over time
-> device doesnt go back to suspend.
suggested solution:
- when in "red" mode, time should be counted as idle, and after a while device goes back to sleep. (when resuming, the timer of the red mode is either resumed -better- or reset -easiest-)
I think it's the compositor itself from which tools like swayidle get their idle info. So if there's a touch in peanutbutter we can't discount it. One thing we might be able to do is disable touch entirely during the 'red phase' and re-enable it afterwards (and if it's long enough we have the suspend in between).
another suggested solution:
- one click on power is just "screen on"
- 2nd click on power activates input to unlock peanubutter
That's more or less the old behaviour, I don't really want to go back to that.
Of course you can also just ensure to press the power button so the screen is off before you put the device back in your pocket ;) (except if the power button gets pressed accidentally again whilst in your pocket)
Comment by ~proycon on ~mil/sxmo-tickets
REPORTED RESOLVED IMPLEMENTED
Comment by ~proycon on ~mil/sxmo-tickets
- sxmo-utils 1.17.0 has been git tagged
- svkbd release has been requested to suckless, will have to package it when done
- lswt dependency not yet needed because we reverted that patch
- colordiff dependency not required because we don't want the heavy perl/delta dependency and implemented a fallback solution that adds colour with plain sed.
- wvkbd has been released this week
- peanutbutter has been released earlier already
- dwm-6.5 still open
Comment by ~proycon on ~mil/sxmo-tickets
Another dependency to add:
- ensure colordiff is installed because doing migrations with plain diff without colours is not pleasant
Comment by ~proycon on ~mil/sxmo-tickets
REPORTED RESOLVED FIXED