4 ms·

Every time I pick up my pinephone I feel immense disappointment in what forms of interaction most devices are stuck with today, despite how easily alternatives

by mgdlbp 3y ago

Every time I pick up my pinephone I feel immense disappointment in what forms of interaction most devices are stuck with today, despite how easily alternatives can be implemented in an open platform as the pinephone has shown. But for just editing text, I find vim and emacs surprisingly usable with a touch keyboard, as long as numbers and needed symbols and modifiers are on the base layer. Precise pointing / fat fingering is solvable for text editing and in general by using the touchscreen for relative input - like a touchpad. That's possible on the pinephone with a userland program that directly interfaces with evdev and uinput in a really simple way[1], taking the ability to run desktop software well beyond being a party trick. All it's missing is a scheme where single, double, or two-finger taps and drags are either relative or absolute to avoid having to switch modes. Or, because the touchscreen, like most, reports touch area, one might have a go at cloning force touch. [1] https://gitlab.com/CalcProgrammer1/TouchpadEmulator https://gitlab.com/CalcProgrammer1/TouchpadEmulator For swipe input, wvkbd[2] has experimental support that works amusingly well for how sucklessly it's implemented (see the readme), albeit only for long words or reduced dictionaries - so many possibilities, like having zsh write completions to a file. It does need a patch to not interfere with normal typing. Spacebar swiping would also be straightforward to patch (or on sxmo into lisgd instead*). Alternatively, a small key could receive a 4-way swipe gesture like the trackpoint that Windows 10 Mobile had. (btw, hey, the MessageEase patent expired...) [2] https://git.sr.ht/~proycon/wvkbd https://git.sr.ht/~proycon/wvkbd * <rant>I don't know how the devs tolerate the latency that sxmo_inputhandler.sh brings - handling basic OS shell gestures in a long shell script on a platform where every expansion piped to grep causes a noticeable increase in latency is very unsuckless!

MayeulC 3y ago
Ah, I've tried to make my Steam Deck+sway setup usable when undocked, but there are bugs everywhere, from wvkbd mishandling seats or straight up drawing an invisible user interface, to sway not detecting gestures (lisgd seems to work well, though). There are plenty of physical buttons on that platform, but it seems the default kernel driver does not handle them (need to have Steam running, which then sends input through... X11). It doesn't help that the interfaces for emulating and intercepting input are very rough or experimental (well, there's libei but wlroots doesn't support it). Maybe I should work on a libinput wrapper or my own "parent" compositor? Anyway, all touchscreens should be able to sense 3D coordinates, which could be used to move a cursor around the screen while hovering. This could be very usable, especially the cursor is shown above the finger position so it isn't hidden. This alone would help a lot with the issues pointed out in the article.
jchw 3y ago
I really wish I could bring myself to get into sxmo more. It seems like something I'd like, but I mostly find myself confused when I try to use it. Even if it's not perfectly suckless, maybe it's a bit more in the "suckless" dimension than I can bear--I did like dwm for a while, but I switched to i3wm and later Sway and never really looked back. There's obviously a lot of small little projects that implement cool ideas, but one thing that is a little bit of a bummer is that there's really no obvious solution that you can flash onto a Pinephone and call it daily-driver ready. It would really be nice if standard-ish Linux desktop environments could be adapted to work well on phones; I mean, at this point, the proof-of-concepts are enticing enough for me to believe that it'd be worth the effort. That having been said, I've been wondering if maybe to get the Pinephone to a working state, if it'd be better to actually go for a very minimal base system and try to build a more or less non-standard usermode. Something like, musl, pipewire, eg25-manager, a custom wlroots compositor that implements most of the actual phone features directly, and some simple system software to go under it (file browser, terminal, etc.) The main thing I really want is to get the absolute best possible battery efficiency, something that can manage rtcwake to occasionally check for notifications and handle some basic alarm clock functionality, and intelligent enough system software to e.g. restart the EG25 when it seems to be stuck. (Usually on Phosh + Debian, restarting the eg25-manager systemd unit is enough, so apparently it'd be good enough to just find a way to detect when it's stuck and restart eg25-manager.) It's a lot of work, and I admit that it feels like you'd be going a tad in the direction of Android by ditching most of the standard userland. But on the other hand, there's so many damn projects involved with most functionality in the device that it is a bit difficult to even know where to start when it comes to troubleshooting, and in my opinion it'd still be nicer than Android if the userland was "standard" enough to still run typical desktop apps and run more-or-less stock kernels. Then again, for now, I feel my frustration would be better spent trying to debug what's already there. I'm wondering if maybe it would be possible to improve the wake times, for example... I have a sneaking suspicion that most of the resume time is taken before the Linux kernel gains control, but maybe it'd be worth trying to get something like pmgraph running to see if there's any room for improvement.

by mgdlbp 3y ago

MayeulC 3y ago

Ah, I've tried to make my Steam Deck+sway setup usable when undocked, but there are bugs everywhere, from wvkbd mishandling seats or straight up drawing an invisible user interface, to sway not detecting gestures (lisgd seems to work well, though). There are plenty of physical buttons on that platform, but it seems the default kernel driver does not handle them (need to have Steam running, which then sends input through... X11). It doesn't help that the interfaces for emulating and intercepting input are very rough or experimental (well, there's libei but wlroots doesn't support it). Maybe I should work on a libinput wrapper or my own "parent" compositor? Anyway, all touchscreens should be able to sense 3D coordinates, which could be used to move a cursor around the screen while hovering. This could be very usable, especially the cursor is shown above the finger position so it isn't hidden. This alone would help a lot with the issues pointed out in the article.

jchw 3y ago

I really wish I could bring myself to get into sxmo more. It seems like something I'd like, but I mostly find myself confused when I try to use it. Even if it's not perfectly suckless, maybe it's a bit more in the "suckless" dimension than I can bear--I did like dwm for a while, but I switched to i3wm and later Sway and never really looked back. There's obviously a lot of small little projects that implement cool ideas, but one thing that is a little bit of a bummer is that there's really no obvious solution that you can flash onto a Pinephone and call it daily-driver ready. It would really be nice if standard-ish Linux desktop environments could be adapted to work well on phones; I mean, at this point, the proof-of-concepts are enticing enough for me to believe that it'd be worth the effort. That having been said, I've been wondering if maybe to get the Pinephone to a working state, if it'd be better to actually go for a very minimal base system and try to build a more or less non-standard usermode. Something like, musl, pipewire, eg25-manager, a custom wlroots compositor that implements most of the actual phone features directly, and some simple system software to go under it (file browser, terminal, etc.) The main thing I really want is to get the absolute best possible battery efficiency, something that can manage rtcwake to occasionally check for notifications and handle some basic alarm clock functionality, and intelligent enough system software to e.g. restart the EG25 when it seems to be stuck. (Usually on Phosh + Debian, restarting the eg25-manager systemd unit is enough, so apparently it'd be good enough to just find a way to detect when it's stuck and restart eg25-manager.) It's a lot of work, and I admit that it feels like you'd be going a tad in the direction of Android by ditching most of the standard userland. But on the other hand, there's so many damn projects involved with most functionality in the device that it is a bit difficult to even know where to start when it comes to troubleshooting, and in my opinion it'd still be nicer than Android if the userland was "standard" enough to still run typical desktop apps and run more-or-less stock kernels. Then again, for now, I feel my frustration would be better spent trying to debug what's already there. I'm wondering if maybe it would be possible to improve the wake times, for example... I have a sneaking suspicion that most of the resume time is taken before the Linux kernel gains control, but maybe it'd be worth trying to get something like pmgraph running to see if there's any room for improvement.