How crazy can I get? part 1

27.7.2018 05:52 | Přečteno: 3570× | | poslední úprava: 27.7.2018 05:52

Well I won't lie: quite a lot. This is a blogpost about an ANSI escape text user interface for a mobile phone ... made in the shell enhanced with elements from the object programming paradigm.

WTF? (or how did it start?)

It all started with a PXA272 SoC based mobile phone (Let's teach penguin how to become magician 1 2 3). The SoC is really buggy. Usually I've had only one way of the control: an USB device network. The problem is the PXA272 USB device controller is really buggy so the USB network crashed a lot. How can you reset the controller if the only access to the system is over the crashed controller? One way is to use the phone keyboard itself, unless it has only 10 buttons (most of them are unusable for "typing") and a touch screen? You need to make a menu then!

Usable alternatives

There isn't much and X windows server mostly keeps failing, so only a terminal application based menus are available. The most obvious use is a ncurses based dialog and it has been used as the first implementation. The problem with ncurses+dialog is the size of hundreds of kB and they require gpm for the pointing device support. The dialog has a big graphical overhead for 30x40 character display (for 8x8 font, we could use 4x6 fonts, but dialogs with them are an ugly thing).

The gpm had another problem with a correct support for the touchscreen's absolute position reports. This itself disqualifies the full use of the dialog and there is a problem with the switching between two focusable groups. There is not enough buttons. Problem with gpm disqualified the scriptable menu drawing utility gpm-root too.

Some "history" first

By using a dialog based menu I've realised an interesting fact. You can redirect output of any ncurses application (for example midnight commander) to any (even regular) file and later dump it back to terminal. So why should I use dialog and ncurses to draw an almost static UI when I can use a ansi escape dumpfile with highly compression ratio? Why do I even need to store a dumpfile when I can draw it dynamically? Why would I use this awesome interface to only reset an USB controller when I can build whole GUI with it?

The answer is here:

Almost everything in this version was hardcoded. Still, it already supported a reset of some controllers and a battery charging checks (first thing which dies with the undercharged battery is the USB device controller).

How to make a simple colored button

We gonna need a reference for ansi escape codes and some frame drawing characters. The wikipedia uses UTF-16, but the terminal uses UTF-8, we need to convert the values. The laziest way is to copypaste them from the wikipedia into your hexdump . You can store the following 3 bytes as a string for a symbolic naming. Using the native character should be possible (and the string will have only one quart length), but you may have problems with editing or parsing the source code and with debugging the shells without a valid unicode support. There shouldn't be problems with printing the string, so it should be safe, but still you really want to debug the string parsing functions in the shell source code?

c_form_h="\xe2\x94\x80"
c_form_v="\xe2\x94\x82"
c_form_tl="\xe2\x94\x8c"
c_form_tr="\xe2\x94\x90"
c_form_br="\xe2\x94\x98"
c_form_bl="\xe2\x94\x94"

Now we have the constant frame drawing symbols defined. Let's make more constant strings (readonly mode is enforced by the mind of a programmer, obviously):

c_form_h_arr="${c_form_h}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"

lazy to copypaste the constant string 2^n times. Some 10 lines of that should be enough for everybody (unless you want to fill 4k monitor with 4x6 font).

c_spaces=" "
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"

same with spaces. Yeah and don't forget to use "{" and "}" or you gonna have the hell with a renaming. And now we can print a simple frame:

c_sizex=10
c_sizey=10
c_color="32;1"

echo -e "\x1b[${c_color}m${c_form_tl}${c_form_h_arr:0:$(((${c_sizex} - 2)*12))}${c_form_tr}"

i=1
while [ ${i} -lt $((${c_sizey}-1)) ] ; do
  echo -e "\x1b[${c_color}m${c_form_v}\x1b[0m${c_spaces:0:$((${c_sizey} - 2))}\x1b[${c_color}m${c_form_v}"
  i=$((${i}+1))
done

echo -e "\x1b[${c_color}m${c_form_bl}${c_form_h_arr:0:$(((${c_sizey} - 2)*12))}${c_form_br}"

I don't use printf as I've found inconsistencies between different shell implementations. Some may have problems with escaping the predefined strings. A raw unicode character could help, but the copying from the array is the place where an unicode unaware shell may differ from an unicode aware shell.

# xxx="╬"
# echo -n ${xxx} | xxd
00000000: e295 ac                                  ...
# echo ${#xxx}
1

And mine configuration of the busybox shell would count bytes, but I don't remember if I configured all parts of the system with the unicode support.

If we want to print the frame somewhere in the middle of the screen we need to add "cursor position set" ansi escape code for every line. We can use the code "CSI n ; m H" (there are multiple ways):

while [ ${i} -lt $((${c_sizey}-1)) ] ; do
  echo -e "\x1b[${c_row};${c_column}H\x1b[${c_color}m${c_form_v}\x1b[0m${c_spaces:0:$((${c_sizey} - 2))}\x1b[${c_color}m${c_form_v}"
  i=$((${i}+1))
done

BTW the values of c_row and c_column are counted from 1 (yum), but you can incerment them in the string with an embedded $(()) expression.

The CSI for the color settings can set different attributes, which may or may not work on your terminal emulator. For example: the one for the framebuffer in the kernel cannot blink, you would have to write some scheduled rewriting in the kernel driver, but most of framebuffer drivers can increase the intensity and X server terminal emulators can do anything.

Following versions

During the bugfixing I've started naming the versions by the letters of the greek alphabet. Let's see the β version:

Now the engine supported a directory based menu (and a "nice" hardcoded selection frame):

BTW I was able to chroot the whole system from an SD card into the RAM (because of my second crazy project).

By abusing the loadkey database I was able to type a simple command and run it in the terminal (with only arrows, enter and 2 more keys).

echo -e "keycode 169 = F70\nstring F70 = \"${KEYSTRING}\"" | /usr/bin/loadkeys - > /dev/null

In the Delta version I've manually colored all icons with the ansi escape codes:

and in the Epsilon I've started to rewrite the engine (for the first time) for more flexibility. Here is what happens when you make movable "window" in a shell:

BTW the engine should be called "ever rewrite engine" as we will see but I called it "Failsafe" (the irony was intended, but it was more stable than Xorg by that time).

In the next part we will take a look on the basic data manipulation in a shell.

If you have found this idea funny or you want me to rewrite the engine in a more sane language, consider a donate to my BTC adress: 1CqzWKDLdcbjbzvzkrcP5bHsScjm5CwcjH or to my ETH adress: 0x1440d31eD70fc6b084c71f03590F6e1d121C919E

       

Komentáře

[pc2005]

Aneb jak si Bedňa přál ...

[Bedňa]

Kurňa kuknem na to a hovorím si je to ono, si pán, dík kámo.

[debian]

Can you give on and article/blog your full example code? I wanna try that.

Thx.

[pc2005]

Not yet, I don't wanna spoil blogposts, maybe in 4-5 part, definitely on the end of the series. These version are not even able to run on PC and they would randomly wrote to a random memory locations.

[debian]

Ok. Then u give on too on github or here. ... I like what i studying, can testing.

[xkucf03]

s/github/gitlab/g

nebo jinam…

• Git != GitLab
• verzovací systém != Git

[vlastikroot]

Proboha proc? Na grafiku nejsou potreba Xka, staci framebuffer (ktery musi fungovat, kdyz funguje konzole na displayi).

[pc2005]

Právě pro takovéhle komentáře . A to tohle je ještě nuda >. BTW tohle není grafika, to jsou znaky v terminálu.

[vlastikroot]

Je to grafika, to vidim Me jde prave o to, proc to delat takhle oklikou (bash -> fbcon -> framebuffer) a ne rovnou (c/c++ -> framebuffer).

Protože to jde? Nebuď takovej suchar

[pc2005]

No primárně protože ten daný den mě nešel zkompilovat ncurses a binárka byla moc velká do initramdisku, pak jsem se ho nechtěl učit a nakonec to bylo because we can . V céčku bych to samozřejmě napsat mohl a možná to přepíšu. Z bashe to bude triviální .

[Bedňa]

Tak a teraz k EN. Fakt sranda, že roky som bol len na písanej angličtine "pls fix my bug" a teraz som sa na dlhšiu dobu ocitol za hranicami a emajly robím v pohode. Potom mi volá fakt pekná Alexia a bla, bla bla, pretože je moc ukecaná a nejde k veci, takže to nechytám a poviem jej prepáč, dáme kávu ja si idem prečítať email na ktorý som sa vysral :)

Kurwa si borec vo veciach ktorým som kedysi venoval kopec času, tak tebe fandím, ako to háčkuješ.

"more stable than Xorg*" alebo tak niečo tam píšeš, nechce sa mi k tomu vracať :) Sorry ja som zástanca Xorgov a nemám rád kecy bez riešenia čo je na nich zlé :)

[pc2005]

"more stable than Xorg*" alebo tak niečo tam píšeš, nechce sa mi k tomu vracať :) Sorry ja som zástanca Xorgov a nemám rád kecy bez riešenia čo je na nich zlé :)

To se přímo netýka bashe, ale spíš intel Xscale SoC architektury. V té době nefungoval pořádně touchscreen, Xka sežerou značnou část RAM a nevejdou se do 30MB ramdisku (takže je nelze spouštět bez SD karty), fluxbox má dost neefektivní stavový automat na obsluhu klikání, takže se špatně fungujícím touchscreen driverem to bylo nepoužitelné. Když umře nějakej driver, tak potřebuju vidět dmesg puštěnej ve smyčce, v tty konzoli to je přece jen robustnější. GTK se nedá použít na rozlišení menší než 640x480 (mám dojem, že to mají dokonce ve specifikaci UI layoutu, minimálně jsem musel ty layouty ručně upravovat, protože jsem jinak viděl jen výpis adresářů). Současně používaný matchbox ještě v té době pořádně nefungoval (je málo vyvíjenej) a občas segfaultoval. Stejně tak nefungovala virtuální klikací klávesnice (jsem musel najít až minulej rok, že se před x lety změnil server repa).

Dále zapnutí Xek začne víc žrát baterku, takže je vyšší šance, že systém selže nadproudem (ani bych neměl v xkách aplikaci na sledování odběru z baterky). Intenzivní používání "grafického" "řadiče" ho může zablokovat.

A finálně největší problém. GCC pro xscale negenerovalo validní instrukce a tak občas dostal ARM buď random kód a nebo instrukci z novější generace architektury (protože ARMv5TE nemá pořádnou podporu debuggingu, tak to vypadalo tak, že kód skáče náhodně po paměti a on nejspíš i občas skákal). Taky to znemožňovalo používat 16bpp xkový aplikace (ty instrukce se používají pro zoomování pixmap).

[vlastikroot]

Xka se na embedded vubec nehodi. Nejlepsi je kreslit primo na framebuffer. Qt ma moduly linuxfb (legacy FB) a eglfs (openGL KMS), takze jde pouzivat i bez X. Ale to PXA270 je asi moc slaby i na Qt, ja delam s Freescale iMX 5 a 6 a ani tam to neni zadna slava.

[vlastikroot]

BTW, ja pouzivam Qt/QML i na miniaturnim monochromatickem displayi 128x64 OLED s radicem SSD1305. Mam tam dost podobne GUI, jako jsou screenshoty v zapisku (program slouzi k flashovani a otestovani zarizeni ve vyrobe, takova ozivovaci SD karta).

Vyhoda je, ze mam tim padem stejne vyvojove prostredi, at uz jsem na PC, dotykovem embedded zarizeni, i na tech nejjednodusich tlacitkovych zarizenich.

[pc2005]

Čistý xka s vlastním layoutem by jely, akorát teda by bylo málo paměti. Matchbox docela sedí i když je dost natvrdo naprogramovanej (divná nabídka a občas něco segfaultuje).

[xkucf03]

Přijde mi to dost nečitelné. Nepřemýšlel jsi o rozdělení na vrstvy bitmap (resp. spíš znakových map)?

text = "
 ╭──────╮
 │ Ahoj │ 
 │ 123  │
 │ ...  │
 ╰──────╯
";

barvaPisma = "
 xxxxxxxx
 x      x 
 x aaaa x
 x bbbb x
 xxxxxxxx
";

barvaPozadi = "
 dddddddd
 d cccc d 
 d      d
 d      d
 dddddddd
";

akce = "
 dddddddd
 daaaaaad 
 daaaaaad
 daaaaaad
 dddddddd
";

A pak mít funkci, která ti to poskládá dohromady a vygeneruje ANSI sekvence. Ve zdrojáku by bylo na první pohled vidět, co bude na obrazovce. Dynamické hodnoty by se daly doplňovat prostým nahrazením textu (+x kontrola délky), např. bys tam měl {ppp} a za to bys doplňoval hodnotu nabití baterie v procentech.

Další funkce by pak podle souřadnic zjistila akci a vrátila např. akci "a".

[debian]

A naprogramoval by a la ncurses ....

[pc2005]

Co vlastně všechno ncurses umí, můžu si definovat kompletní okenní paradigma, nebo jsou závislosti mezi oknama součástí knihovny?

[Josef Kufner]

Okna v ncurses jsou dost low-level záležitost a do oken jak je známe z grafických desktopů to má hodně daleko.

[pc2005]

Jako rozdělit to na planární grafiku? To nejde ash neumí pole a jinak nemáš jak bys dostal atribut třeba pozadí ke specifickému znaku. A bajtový copypaste by bylo ultrapomalý. Jedině že bys generoval ty ansi escape kódy z nějakého vlastního jazyka, ale to by bylo furt pomalý. Nicméně aktuální verze to má jinak (nebo spíš může mít, zatím jsem byl línej to implementovat) .

[pc2005]

Jo a pak by se to taky blbě generovalo kdyby se měly generovat jednotlivý atributový roviny.

[Josef Kufner]

Rychlost je nepodstatná. Předkompiluješ si to při překladu či před prvním použitím.

[pc2005]

před prvním použitím

Jo to je ten problém, co popíšu v dalších částech.

[RM]

Regarding printf inconsistency over diverse shells, what`s a problem?

[pc2005]

Hmm I wrote it illegibly, because I partly don't remember why I didn't switch to printf and I don't remember older configurations of my busybox. I can only try to retrace my thinking.

It's more like inconsistencies between shell implementations not directly printf, altought there are some.

The busybox implementation of ash is slow (it even calls the kernel after every keyword). But the strings in busybox ash are __very__ slow, so I always assume a string parsing will slow the graphical engine to an unusable speed. The main goal is use the strings as little as possible. The echo -e -n command should be fast enough as it contains only switches, but the printf you cannot directly use a general graphical data string in the formating part (it can contain "%"). You need to use them as a parameter. The formating string can only be "%b".

You could use stuff like this:

# printf "AAA %.5s BBB\n" "${var2}"

but it does not copy five UTF-8 characters (with 3 bytes). It copies only 5 bytes (1 and 2/3 of an three bytes UTF-8 char).

In this situation "printf" doesn't have any benefits over "echo", but it has a disadvantage with the formatting string, which has to be complexly parsed. In the bash it doesn't really matter as the implementation overhead of a program with more features is bigger than the speed differences between echo and printf (= there are equally slow). In busybox there may be speed differences.

And you can opt to disable one of the busybox ash functions to gain a space for the binary so using only a dumb echo output could be seen as a benefit.

The rest of the "echo over printf" choice was most likely in my unwillingness to deal with the printf documentation as a _much_ more difficult stuff required my attention.