-- Leo's gemini proxy
-- Connecting to zaibatsu.circumlunar.space:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Infotech: the final effrontery. These are the voyages of the script-fogey Shufei. Her continuing mission: to explore new Linux run devices, to seek out new FLOSSforms and new implementations, to boldly go where no solarspinster has gone before.
I’ve spent two more internet days on Raspad improvements. I’ll see if I can review these helpfully, completely, but without belabouring *too* much. Day 1 was a good go indeed; day 2 I fell into the bog. But I’ve gotten much done toward making the Raspad a compleat solution for my infotech needs.
On the whole, I must say I’m pleasantly surprised how little of the service nuts and bolts need user attention. As far as system-on-chip microcomputers go, the Raspi 4B is a spiffing platform. I’ve learnt a bit more about what it can and can’t do, and pushed my own device to its comfort zone edges a bit. For hardware per se, Raspad is prime time.
My input method editor of choice, Ibus is working and seems relatively happy. I considered jumping the bandwagon to Fcitx. But the name of the game is stability; I more know what Ibus can do.
this means getting Rime going. Rime is sort of an IME within an IME; it works well in Ibus. Rime easily allows one to create novel input methods using fairly straightforward yaml configurations. For those who speak minority dialects, Rime is a gimme. It is working well on Raspad 3, seems happy with Onboard’s small layout in English mode. Between Onboard and Rime, a modestly infotech literate person ought to be able to forge a reasonably native interface for most any dialect… even half educated bumpkin dinner table Mandarin, ha.
Rime’s adorably named 朙月拼音 scheme here merits an honourable mention. The Ibus Intelligent Pinyin plug-in is fine, yet lacks many needful but obscure characters. This is what one gets for following PRC mandated trends in IME use. But 朙月拼音 is more compleat and in supposedly 守舊的 nomenclature too, bless the devs.
I also delight in two other schemes for Rime: the 唐音拼音和南京話之拼音輸入法。 The Tang sound input is standard, and readily helps ingrain proper literary pronunciations. Anyone who does CJKVZ poetry can use this. The Nankingese dialect input is a lovely help for those who would rather not shove er sounds er where they don’t er belong er.
I am working on handwriting input. A lack of decent handwriting recognition is one of the most glaring holes of CJK input for touchscreens in Linux.
There is a mouldy programme called inputpad which fires up quickly. Even the most simple characters were beyond it. (I clearly wrote 丁、白、我等等 and it fired back random folderol, poor thing.)
Tegaki with Zinnia inside is still a plum mystery to me. I *believe* I got it working under the Mozc plug-in for Ibus. At all rates, Mozc handwriting works lovely… for single character inputs copied to clipboard. Why, dear dev, why?
An absolute virtue of tablets is to write organically, to lessen the alienation between literacy and text which keyboards have engendered. This is a cultural imperative and a sine qua non of self cultivation; dash the boorish Zeitgeist. It is also a practical need. Sometimes I plum don’t know how to type a character in either standard Mandarin pinyin or by proper stroke order, but can handwrite it.
At all rates, Mozc works, even though it is emphatically geared to Japanese use. It is inadequate in not allowing phrase suggestion, refinement by 部首, only copying to clipboard, not playing well with dark mode, and for some weird reason disallowing resizing the input square. I suppose iPad spoilt me for handwriting. But it is clear this needs some further help. If I can get Mozc handwriting to print directly to tty I shall count it kludged.
Anyway, grepping all the Tegaki, Zinnia, and Mozc packages in Synaptic will allow this option.
There is another possibility I shall try later, a newish CJK handwriting IME using Google Translate’s handwriting recognition inside. From videos it looks perfect for UX. It is sadly inadequate for using Google, natch. Even if I suffered Google asuras to slurp up my handwriting, it is moot for the largely offline. Perhaps it could talk to Tegaki? It is a yak to shave another day.
stroke input is available in Ibus under a plug-in with key symbol substitutions for that. It does a Mandarin pinyin fallback, prompting with strokes per suggested characters. That is fine.
But again here is where iPad pampers us, with a pop up menu to prompt from pinyin by stroke and 部首。 I can’t see this would be difficult to include in Ibus-Rime or with Mozc as a model. But I grant it’s quite beyond me at the mome.
Eventually I hope to get a Bluetooth stylus working. It is not a priority. But I’d like to use a pressure sensitive stylus for calligraphic and painting purposes. I recall there was a proper brush stylus once developed for iPad. That would be ideal. But the reality is most programmes can only play with pressure sensitivity, so that must do. And that is also probably a big ask, but one I’m thinking about.
The medium is the message, supposedly. Contemporary infotech is aggressively propagandistic in its anti-humane UX. But between stylus and handwriting recognition, a kludge may be found.
Surfing the Duckster and (oh shame) occasionally Google, I did find that right click on long hold is possible under MATE.
However, this with the proviso it will further b0rk some menu interactions. This won’t do. Right click on hover likewise is obvious folly.
To the rescue I finally found the sweet relief of Touchégg under its config GUI Touché. The former is available via the MATE repo, the latter is not. For any touchscreen deployment this is a most needful doohickey. Touché allows the easy settling of multitouch gestures according to whim and by specific programme.
I quickly found that the two finger tap right click is about as handy as long touch. Once one is accustomed to a slight delay between fingers, one can specifically tap anywhere for a right click reliably. I can’t say this would likely help those with motor disabilities. But for me I found it copacetic and got used to it tout de suite.
Another gesture I implemented is three finger swipe for page up and down. Quite handy.
Touché is a powerful tool which should come standard on any Linux touchscreen distro.
I’ve not put much time aside for tooling the MATE theme. But I did find a very handy datum, that the user can override theme GTK settings by a preemptive config file in ~/.config/GTK*/ This, when setting the scrollbar to 12 pixels, did well to cure the overly slender scrollbar issue. Honestly, the scrollbar is too thin even for a mouse; how there is no ready accessibility setting for this is beyond me.
A questionable “feature” enabled in many GUI is the penchant to zoom font size upon pinch in or out. This gesture annoyingly conflicts with the two fingered scroll on both touchscreen and touchpad. Inevitably it will mistakenly trigger to comically bloat text in both Caja and Firefox.
For the former case, I filed a feature request.
For Firefox, one may happily avail of about:config to turn off this nuisance. Flip the relevant bit and it is quiet.
A fool rushing in, I descended the yak hole in pursuit of OpenGL issues. This tutored me a bit in the capabilities of the Raspberry Pi graphics chip, but provided no ready solution.
The Raspi OpenGL driver currently available only extends to version 2.1. This is included in Ubuntu MATE for Raspi. Anyone running Blender or playing Tuxcart will immediately see this is nowadays inadequate. The former balks at runtime; the latter works jakely …save that the lil carts are invisible. The Write note taking programme likewise will not run.
Apparently the Raspberry Pi 4B’s M3V graphics chip *can* handle OpenGL features up to version 3. A good soul has been working for a few years on a new Raspi driver for OpenGL 3.3, and by his blog he is still regularly at it. Let us give him our support.
Suffice to say, whether OpenGL 2.1 or 3.3, I am glad that my Raspi 4B has 8Gb of memory. When cranked up to 1500Mhz, the lil Broadcom chip handles most graphics programmes swimmingly for my needs. I spent some time tooling around with graphics programmes, from GIMP to Imagemagick. In all but the most intensive and dynamic of brushes, these are reasonably at speed.
I should like to run a Bluetooth stylus eventually. I’ve yet to look into this distant priority.
A mission critical need for me is some kind of way to run a few choice Android programmes. (Heresy, I know.) The at hand solution is usually Anbox, a very needful virtual machine which has sadly been becoming moribund. This will install from repo, but will not do as of dateline. Running…
anbox system-info
…shows that although the kernel does have ashmem support active, the Ubuntu MATE for Raspi repo packaged Anbox won’t see this. Likewise binder support, I would guess, though this is not active by default in UM4Pi. I discovered this after several hours of having descended into compilation hades.
One *can* get Anbox running reasonably on Raspi 4B, says The Internet. However, I encountered build bug upon bug, and could not get the errors ironed out to cmake’s satisfaction. This, although I did chase down and solve a few on mine own sleuthing for which I was proud. In the end it was futile. Any reasonably speedy Anbox instance requires both ashmem and binder available in kernel. As I was out of daylight and mine head was pounding, I shall have at this windmill another day.
The short of it is to run Anbox in Pi4, it appears one must reroll the kernel with ashmem and binder support (gulp), fine comb the dependency desert, then pray cmake is satisfied.
Then one must use an Android kernel fit for use on Arm64, of which few there be. Some good soul pointed out an Android 7 kernel image proven to work, courtesy of the Ubuntu Touch kids.
Suffice to say, this all implies that on any machine needing Anbox, one ought to install it first. Beyond playing with AX.25 support, the Linux kernel is daunting territory for this scriddie.
There is a snap which advertises itself as Anbox for Arm64. When attempting this prospect, snapd notifies that it doesn’t support Arm64, but only AMD64 and ArmHF. Whether the latter context might suffice through some tricksy sleight upon snapd, I know not. Snap shenanigans are currently beyond me; I shall prioritize rerolling the kernel.
A new option, which I also discovered too late, is the Waydroid project. As the name suggests, this requires Wayland, but is said on the forum to readily work on Raspi 4. However, I recall that I vetoed Wayland previously but not *why* I vetoed Wayland. Some other needful programme was said not to like Wayland.
Between recompiling kernel and jumping into Wayland on my largely working system, I’m more inclined to the former. I’ve no knowledge of Wayland yet, but shall look into it if forced. Yakitty Yak.
I posted several times on the Raspad forum, but got caught up in a spammer sweep. My account was reinstated, but the topics were not, nor any replies. A deuce nuisance.
I got Lynx going, natch. And finally I discovered why it is so UTF-8 averse. Why it should be so, when UTF-8 is no skin off any ASCII nose, is beyond me. But what it comes to is this:
1. Make sure all the display encoding variables are set to UTF-8 in Lynx.cfg.
2. Set UTF-8 for everything in the Options menu.
3. Make sure to run
lynx —display_charset=UTF-8
If this latter option is not run, Lynx will insist one is using an ANSI only terminal, no matter what you tell it in the config file. 🤦🏽♀️
I did find a new text browser which is quite a wondrous little toy, and may supplant Lynx for my preference. Browsh is a sort of true colour terminal front end for Firefox. The dev’s main idea is to use it for browsing via a low baud proxy or adhoc connexion, but with full bignet web bells and whistles. It works fine on a single machine, too. Apparently it can run any Firefox plug-in one pleases. Its display algorithm converts images into dual escape-coloured ascii half-box shapes as pixels. It is a canny trick, looks cute, and smolwraps the web.
… I need to see what people have been making lately. I still stick with the AV98-agena-VF1 suite and Lynx for finger. All run fine.
Now and then I switch out the MicroSD back to RaspiOS as a baseline check. Fiddling around, I did find that the CPU_Freq panel widget in that OS does indeed dynamically scale frequency. *But*, for this to work, one must manually set the /boot/config.txt ARM_FREQ value to the highest frequency one wishes to deploy. That is, ARM_FREQ is an upper bound, with 600mhz the hard set lower bound. The profile hard set by the rather perfunctory widget is Ondemand. A way to set the lower bound at, say, 200Mhz and use the Powersave profile would greatly help battery life, I reckon. When on power, one ought to be able to overclock the upper bound to the neighbourhood of 2Ghz to make graphics heavy programmes happy. Tweaking the upper and lower parameters for the scaling widgets is high on my shopping list.
One finger scrolling works much better in RaspiOS’s LXDE than in Ubuntu MATE. The latter often doesn’t work. This is fine, I shrug, as I am used to using the widened scrollbars. But it is an obvious improvement needing attention in MATE. I’ve no idea how to go about this. It seems that it must relate to drag and drop, which is an annoying and dangerous feature counterproductive in tablets. (I don’t use it in laptops either.) I’ll keep looking for a way to disable drag and drop at least in Caja.
It’s obvious someone in dev is trying to optimize RaspiOS GUI for touchscreen option, from a few gracenotes like this. Rythmbox has a more pushbutton layout, for instance. One thus hopes at least that the drop menu and frequency scaling issues may be worked out directly.
Under Ubuntu MATE, but *not* under RaspiOS, the Raspad built in audio will hiccup now and then with blank silence of about 0.5 to 1 seconds. This does not happen with Bluetooth audio. Since the audio in question is fed via HDMI to the daughter board, I at first thought it might be a disagreeable latency in the line. But since it works fine under RaspiOS, I suspect it must be some idiosyncratic system issue with our good friend Pulseaudio. When in doubt, it is often Pulseaudio.
Under MATE, when video in any window plays with the screen tilted away from default (the thin edge of the Raspad wedge facing downward), there is a slight artifact of some video interlacing issue. This only happens when the screen must refresh at some higher rate. (Dialog scenes are fine; space opera action scenes show the issue.) The artifact occurs about 40% of the screen from Raspad (thin wedge) bottom. It does not occur when the screen is at default. It’s not too annoying, but worth fixing.
This artifact does not occur in RaspiOS. When in fullscreen mode, video simply will not rotate from the accelerometer. Frankly, this is more annoying than the artifact itself, as the virtue of the Raspad form factor is being able to stand itself upright on the fat end.
Lest these gripes and petty travails dissuade anyone, I’m quite optimistic at this juncture that I can do Raspad 3 up brown as a daily driver device. Someone more code literate (and always on internet) might do far quicker and better. Once Ubuntu MATE, Touché, and a few other tweaks are installed, the thing works alright. The fundamentals are clearly solid.
In terms of basic UI issues, the prime remaining block is still with some drop down menus not liking tap for click. I’ve not found any answer for this yet. Aside from a few theming issues such as icon density, the rest of the MATE GUI feels solid enough with touch.
Clock management is yet an issue, in both senses. For most online users this is moot. I’ve yet to get Raspad to pair with my gps via Bluetooth. This obviously is a mission critical ask. Moreso, I’d like to have the system clock set from Bluetooth as well as NIST signal. Perhaps a lil battery driven system clock or time server can be made to work via GPIO. At all rates, I expect this will be a steep hill.
The odd cursor location difference on tap I shall look into. It feels discomfiting switching between iPad and Raspad. Something to just get used to, if a fix is not available. But a DE setting for this is entirely warranted, to move the cursor touch recognition spot. A tab for the mouse/touchscreen programmes would be fitting.
On the whole, and quite unawares, the Raspad has already largely replaced my lappy. It might do so entirely depending on if it can run SimCity 4 on Wine without too much mischief. With a keyboard-trackpad it is already a good lappy, the best way I’ve yet seen to run human interface for a Raspberry Pi. Hopefully at the end of this I will post a Raspad primer to help others speedily shortcut the yak queue.
I tried to find a panel applet to simply allow a tap on it to switch the cursor to right click mode. Search did not reveal any, though for such a thing there must be constant need. Something for which to try again.
-EOF-
-- Response ended
-- Page fetched on Thu May 2 17:22:33 2024