[Kindle Touch] xterm & matchbox-keyboard

[geekmaster]

Originally Posted by knc1

RANT
Perhaps you've noticed during the evolution of the NetBook products - - -
Our "space bar" is disappearing, if the trends continue, it will soon be no larger than any other key.
/RANT

Which might not be such a bad idea in the confined real estate of an on-screen keyboard.

I won't need ANY "space key" when I finally get my "direct neural interface" that I have been waiting for most of my life. Of course, I hope the "connector" is a bit smaller and more portable than the ones used in the Matrix movies.

[baf]

Originally Posted by MaPePeR

But i wonder, why both have their own keyboard.
What is the problem with using the standard-touch-keyboard?

It would be much more difficult, at least for me
First of all adding function keys and special characters might be tricky. It would also probably require changing system files, while using separate virtual keyboard does not.

[geekmaster]

Originally Posted by MaPePeR

Thats a point.
...
(Also: if we invert the standard 16"color" gray dithering: will we get more b/w pixels? for (even) more quality? if you say "blit to the screen" is that after or before the standard-dithering? simply ignore if this is to OT)

My newest code blits in "layers", with the bottom layer dithered and animated (like the "goodbye" function in the "newtrix" demo. Upper layers can be full (undithered) grayscale. I create the keys in grayscale, but to keep the background animation fast I dither the keys. The character images are not dithered, but are only black and white. If I have ANY gray pixels on the screen, it all slows down on 5.1.0, because although I found a workaround for the broken 5.1.0 eink drivers for FULLSCREEN updates, I was never able to get area updates working (still broken). So I am sticking with black and white pixels only, for update speed.

How can inverting the dithering give more "b/w pixels"?

EDIT: The newtrix demo also shows how to blit full grayscale, so you can have 256 shades of gray. Even on the K4 and K5 that use 8-bit pixels, the bottom 4 bits must be a copy of the top 4 bits (according to comments in the device driver source code). You can get unpredictable results (depending on eink controller hardware) if the bottom 4 bits are not the same as the top 4 bits in a pixel. So to get more than 16 shades of gray, dithering is required (as shown in newtrix, which supports 256 shades of gray as can be seen in the shaded circular background image behind the "hoses").

[MaPePeR]

Originally Posted by geekmaster

How can inverting the dithering give more "b/w pixels"?

Maybe i misunderstood something but i thought i have read somewhere, that the kindle itself does gray-scale with dithering. For my stupid understanding of dithering that means: they use 4 pixels(example) for one to display some shades of grey. So if i can predict how my 16 gray-scale colors will be dithered to the screen i have access to more pixels, so i can make my font/image/whatever even more clear(in black and white pixels)

I bet this thought is just bullshit - right?

(Nevertheless i found some results to "Invert ordered dithering" on Google, so maybe only my assumption, that the e-ink display uses dithering, is wrong)

[geekmaster]

The kindle PROGRAMS (such as eips) do the dithering. If you put a 256-grayscale PNG image on the kindle, then display it with "eips -g file.png", then save the image in the framebuffer with "dd if=/dev/fb0 of=file.raw", then load the raw image into a paint program and do a histogram analysis on it, you will see spikes for only 16 evenly-spaced shades of gray. The raw image in the framebuffer was dithered from 256 colors to 16 colors by eips. Similar dithering is done for screensaver images and for ads. I do software dithering for 256-color support in the newtrix demo program -- you can look at my published C source code to see how I did it.

"Invert/inverse dithering/halftoning" is the process of converting a dithered image back to grayscale. It averages pixels in "continuous tone" areas to get 8-bit color values, but original dithered pixels are retained near discontinuities (high-gradient edges in the image). This is similar to "super-resolution" upscaling, where pixel-smoothing is done in the direction of least-gradient.

When we OUTPUT to the eink display we do dithering because the hardware only supports 16 shades of gray for STATIC images (like anti-aliased text), or only 2 shades of gray (pure black and white) for ANIMATION (such as the videos in the "geekmaster kindle video player" thread).

EDIT: For text fonts used on older laser printers, individual pixels were placed BY HAND around the edges of characters, to dither the edges in a way that was pleasing to the eye. This dithering was designed into the character bitmaps by "font artists", rather than being done by software or hardware. Because the kindles behave more like ink on paper than like light-emitting displays, these old time-tested ways of doing this give much better results when speed is important (such as on animated displays).

[MaPePeR]

Originally Posted by geekmaster

the hardware only supports 16 shades of gray

Ok, than i misunderstood that. i thought the 16-shades of grey where already achieved by dithering.
Thanks for making that clear for me.

have a nice weekend.

[geekmaster]

Originally Posted by MaPePeR

Ok, than i misunderstood that. i thought the 16-shades of grey where already achieved by dithering.
Thanks for making that clear for me.

have a nice weekend.

In my eink animation demos, I only use pure black and white (which is MUCH faster than if there is ANY gray on the screen in the update area). I dither 65 shades of gray down to black and white (an 8x8 dither matrix has 65 dither patterns, including empty -- not 64).

In the newtrix demo, I also dither 256 shades of gray down to 16, as required by the eink hardware. On the K3 and earlier, each framebuffer byte holds two 4-bit pixels. On the K4 and newer, each framebuffer byte holds two COPIES of a 4-bit pixel. You can see how I handle this in the newtrix demo.

[wl.]

Thanks for realizing my wishes!
works like a charm.

is it possible to change fonts, Midnight Commander looks ugly enough?

now we can use many console tools, like console instant messengers, and so on.

edit&compile with tcc...

Nice!

[baf]

Originally Posted by wl.

now we can use many console tools, like console instant messengers, and so

Oh yes, I built mcabber and freetalk to use with jabber account. Although a gui client would be more comfortable… I have to look for candidates to port.

[wl.]

look at these, which uses GTK+ (already inside kindle), wxWidgets (easy to compile and install). Maybe . NET Mono (easy to compile, hard to install, and waste space).
qutIM - should be the best choose, but Qt4 itself has no access for Kindle Touch (i mean, there is no "./configure && make" sources, which will work on KT without glitches)

[baf]

I put new version of xterm package on my server with slightly improved keyboard layout.

[wl.]

Originally Posted by baf

I have to look for candidates to port.

pidgin can be compiled and run at kt, but show nothing by default.

[eureka]

KT on-screen keyboard isn't a Java application. It's a native compiled application. It sends X events to currently active window.

So potentially it could be used with XTerm (and any other X application).

Keyboard layouts are simple JSON files (gzipped in 5.1.0). X keysyms could be used in a keyboard layout (i.e. cursor keys, control keys etc). A little more information could be found in another thread.

Keyboard could be shown with:

lipc-set-prop -s com.lab126.keyboard open com.example.xterm:abc:1

and then closed with

lipc-set-prop -s com.lab126.keyboard close com.example.xterm

com.example.xterm is an unique identificator of application requesting to show keyboard. abc is a keyboard sub-layout (it could be abc, web or 123). 1 is a flag for whatever I don't know precisely.

Unfortunately, KT keyboard doesn't working with XTerm from this thread. Keyboard send X events of key presses to XTerm window, XTerm receives them (I see it in debug level logs of keyboard application and xev output for XTerm window). But XTerm doesn't display sent characters. I didn't dig any further.

UPD Full list of keyboards sub-layouts (as for 5.1.0): abc, Abc, 123, web, pad

Flags are:

• 0 - DEFAULT
• 1 - COMPOSITION_ENABLED
• 2 - AUTOCAPITALIZE
• 4 - CLIENT_DISABLED

They coud be unioned through binary OR (for example, flag 3 will enable both COMPOSITION_ENABLED and AUTOCAPITALIZE, as 3 = 1|2). Unfortunately, I don't know meaning of these flags except their's naming from decompiled code.

[aditya3098]

This is amazing!

[aditya3098]

Weird bug detected! If my command starts with "ipkg" then it freezes before I finish the command.