X apps run on native touch Xorg.

[geekmaster]

While looking for something else in "ps aux" (process status), I noticed that Xorg was running with parameters that explained why x apps were not working when I had previously tested them. Xorg is launced in the kindle touch startup scripts with a "-nolisten tcp" option.

I tried running Xorg again, but with no parameters, and it automatically assigned X display ":1". I had previously copied xeyes for arm from a kindle 3 debian install to my kindle touch /mnt/us. When I noticed that the second Xorg launched using X display :1, I decided to drop what I was doing and test xeyes again, but using display :1 this time. As you can see in the photo below, xeyes is overlaying the top inch of my touch display, with the menu bar (title and time) on top of it. Even though the menu button is covered, it still works.

I have an ebook open (below xeyes and beneath the menu). Whenever I generate an event that updates the display, the eyes move to where my finger is touching. I pressed the menu button, and selected the new Launch menu (from yifanlu) from there. Then I took a photo.

I can make xeyes look wherever I want by touching the screen, then pressing the button switch below the screen (the square patch with four horizontal black lines).

Unfortunately, after the kindle goes into screensaver mode, waking it from screensaver mode makes it kill both Xorg's and restart its own Xorg. When that happened, I just started "Xorg :1 &", then "xeyes -display :1", then touched the button to trigger a redraw. First the display goes all black with only xeyes, then a few seconds later the bottom 85% of the screen displays black on white text like normal. What I did manually could easily be automated, to happen when the GUI framework restarts Xorg.

This discovery means that we can run x apps from the new app launcher menu (like xcalc, for instance). Some x programs might need static linking if their libraries are missing.

Here is a (crappy) photo taken with a cellphone, but it shows xeyes at the top of the display, and you can (sort of) see yifanlu's new App Launcher menu down in the center of the display.

How can I take a screen snapshot without messing up the display? For now, I just used dd to copy the framebuffer to a file (to be processed later). Then due to it being very late into the night here, I used my cellphone to take the crappy photo you see here. Time to get some sleep now.

Well, I think it is cool, anyway... The kindle touch runs X-Windows!

This x program is running native with no other custom code or libraries. It just needs the jailbreak installed so you can start another Xorg and run the x app.

WARNING: due to resource limitations in the kindle touch, there could be problems with running two copies of Xorg at the same time. It may be possible to coax the system into starting only one copy without disabling tcp (needed by x apps), instead of running two copies of Xorg. This exercise was done mostly as a proof of concept (and just for fun too).

More development for this will follow soon from myself and others in the Kindle Developer's Corner here on mobileread.com.

[NiLuJe]

Why would local apps need TCP support? I'm pretty much always running X with nolisten tcp on my box, unless I know I'm gonna need to do X forwarding over SSH (ie. never).

Can't remember how it's supposed to work right now, but local apps should use the local unix socket AFAIK, not a TCP socket :?.

[geekmaster]

Network communications typically use the "7 Layer Model". All X11 data between to processes (whether local or remote) flows through these 7 layers.

At one layer, a socket is an IP <address>:<port> pair. TCP is a protocol used to send data packets through socket.

At another layer, Xorg communicates with X11 protocol, which is sent inside TCP packets via its specified TCP socket.

If you do not tell Xorg with IP address to use it defaults to localhost 127.0.0.1. If you leave off the display number it uses display :0 (port 6000). The default local TCP socket used by Xorg on Unix and other Operating Systems is 127.0.0.1:6000. The commonly recognized host name for 127.0.0.1 is "localhost" (defined in your HOSTS file).

By disabling TCP with the Xorg "-nolisten tcp", it refuses TCP connections to any port, including "the local unix socket".

Of course, the way to know for sure is to just try it. I did, and I posted the results of my tests. It is possible to use other protocols such as UDP, but the version of Xorg installed on the Kindle Touch does lave an option for that listed in its "usage" information, nor do the simple X apps that I tried.

You can read more about it here (and many other places):
http://www.hackinglinuxexposed.com/a.../20040513.html

If you are aware of *different* "local unix socket" communications method used by Xorg for communicating with local apps, which is not disabled by the Xorg "-nolisten tcp" command line parameter, please enlighten me. Thanks.

EDIT: The reason that I thought this was interesting was that the Kindle Touch is running Xorg natively, and the framework is built on top of Xorg, unlike previous Kindle models which used GTK over DirectFB. There was an X11 hack for the Kindle 2, but I was unable to get that to work on my Kindle 3. In the case of the Kindle Touch, X apps run natively on it using the built-in Xorg (except where disabled by command-line parameters).

[hawhill]

Errm, as far as Xorg is concerned, it only communicates via sockets, not depending on a certain type of them. While there is a convention/standard for transmission via TCP, communicating via Unix Domain Sockets instead is equally common (and *might* slightly reduce overhead). Unix Domain Sockets do not built on the IP layer (as TCP sockets do), thus are not IP addressed. They use filesystem namespace addressing instead (or non at all and do file descriptor sharing among processes). There's a convention to prefix the sockets with the "/tmp/X11-unix/" path. See socket(7), unix(7). Note that these sockets are not the same as FIFOs aka named pipes.

Without further configuration, Xorg handles both TCP and Unix Domain Sockets.

[PoP]

Originally Posted by geekmaster

...
How can I take a screen snapshot without messing up the display? For now, I just used dd to copy the framebuffer to a file (to be processed later).
...

I have used programs from the post below, to do just that on my Kindle 3. You might need to modify them for the different Kindle Touch frame buffer:

Originally Posted by dpavlin

[geekmaster]

Originally Posted by hawhill

Errm, as far as Xorg is concerned, it only communicates via sockets, not depending on a certain type of them. While there is a convention/standard for transmission via TCP, communicating via Unix Domain Sockets instead is equally common (and *might* slightly reduce overhead). Unix Domain Sockets do not built on the IP layer (as TCP sockets do), thus are not IP addressed. They use filesystem namespace addressing instead (or non at all and do file descriptor sharing among processes). There's a convention to prefix the sockets with the "/tmp/X11-unix/" path. See socket(7), unix(7). Note that these sockets are not the same as FIFOs aka named pipes.

Without further configuration, Xorg handles both TCP and Unix Domain Sockets.

I recall reading that Unix Domain Sockets map onto TCP/IP sockets, and just added another layer of overhead to the stack. Because unix variants like to treat everything as a file (while Windows likes to treat everything as a window), linux adds a file interface onto a TCP/IP socket to provide simple file I/O access.

Unless I completely misunderstand how this works, a standard TCP/IP socket is created when a "/tmp/.X11-unix" file is opened. Or... is there a version without the "." in front of "X11" that acts differently?

Of course, newer kernels may have optimized the file interface better than the sockets interface. The only way to know for sure is to read the GPL source code provided by amazon.

Anyway, the *real* problem is that the Kindle framework appears to lock Xorg localhost port 0 exclusively so other apps cannot use it. Starting another Xorg listening on another port allows apps to use it.

It is a moot point anyway, because even without launching another Xorg instance, there is not much free memory left for native apps, especially if you use a loop mount so you can install packages that need symlinks.

Personally, my experience in all this was a long time ago when things were done differently. I do not know what X11 does down inside. I do know that what you would commonly think of as a client or server is reversed in X11, where the thing that shares the desktop is the client, and the thing you use to connect to it is a server. Did I get that right? It can be rather confusing.

The main point of this thread is that you CAN run native X apps without needing to install your own Xorg, which is what I found interesting. Regardless of what underlying interprocess communication method is used, another Xorg server instance appears to be needed to support native X apps (other than the framework) on the kindle, unless the startup scripts can be modified to allow apps to share display :0 (port 6000).

I wish I had more time to investigate this, but I have other demands on my time, and other things that interest me more than X apps right now, especially after discovering the excessive framework memory overhead inside the Kindle Touch.

I hope somebody can make use of this information. This is just thrown out there to show that it might be easy to port X apps to the Touch, because some small ones already work right out of the box.

[geekmaster]

Originally Posted by PoP

I have used programs from the post below, to do just that on my Kindle 3. You might need to modify them for the different Kindle Touch frame buffer:

That thread is were I first learned how to use the framebuffer. The conversion programs provided at that link would need to be modified to support the different display bits-per-pixel, and the extra margin to the right and below the framebuffer image.

What I need is to figure out what "hot keys" (or Touchscreen variant of that) saves a screen snapshot. Google does not help much here due to "Touch" being such a generic word. And don't get me started about mostly-useless mobileread search function (unless I have not learned how to use it effectively yet).

I remember yifanlu saying somewhere something about touching the screen and holding the button for awhile, but I could not locate that post, and my experiments to rediscover the method did not succeed.

For now, I am going to go back to writing "hacky" code that uses the eips command to provide display capability, until I discover a way that will let me trigger a framebuffer display update after modifying its contents. At least that way, if I need more memory, I can kill the framework and cvm after it launches my native app, giving me more of what I need. My app can restart the framework when it exits.

[PoP]

Originally Posted by geekmaster

...
What I need is to figure out what "hot keys" (or Touchscreen variant of that) saves a screen snapshot.
...

From Does the Kindle Touch support screen capture?:
Hold down the Home button, tap the screen, continue holding Home for an additional second or two. The screenshot files are saved to the root of USB storage as seen when tethered to a computer.

[geekmaster]

I understand what is going on a little better now. Running an X app with no display selection makes it use X display 0, but it stays hidden under the kindle framework display. Doing a "killall cvm" causes the framework to restart, during which time the X app is visible. I had xdaliclock running in the background, and I could see the time displayed during the framework restart. The only difference with loading another Xorg is that it can write on top of the framework display so it remains visible.

[lukash]

Hi all,

just registered to maybe provide some information on this. I know very little of the Kindle Touch software stack, I've just been doing some reading recently, I don't own the device (yet).

Kindle Touch seems to be running the Awesome Window Manager, so that is most probably the cause of the overlaying of the X apps by the Kindle UI. Awesome is configurable using the Lua language and there will be a rc.lua somewhere on the filesystem that defines the rules for displaying the applications.

Here is rc.lua posted by a user to the Awesome mailing list (the thread). From the looks of it, they are using a modified version of Awesome with the rc.lua also containing a lot of custom code and quite some number of hacks. Your issue is most probably hidden in there somewhere and could be changed.

That is also the place that handles all the input before passing it to the applications, so any global shortcuts can be placed there - like taking a screenshot, you can find the code for that in there. All in all, you can do a lot in that file, making it a great and easy way to mod the device.

[Nyoxi]

Hi everyone,

since I have just discovered this thread I thought I'd add my 5 cents. I have already experimented with Xorg and running other apps (I'm working on simple GTK frontend to opkg) and here's what I have found.

So first to sum up what you have already said:
1) you can start other X apps without any magick on display :0
2) there's awesome WM running
3) normally you cannot see the window because it's hidden under the framework (there's a trick to it, see below)

Now there is rather complex set of lua scripts (in /etc/xdg/awesome/) for window management (also some stuff to handle different screen orientations) so if anyone wants to hack with that by prepared to get your hands dirty. I didn't spend too much time figuring all what's going on there and at some points I'm still uncertain, but for the moment I have figured enough.

To make the windows visible there is a naming scheme what windows are expected to have in their title. The value is set of key:value pairs separated by "_" (underscore). For example "L:C_N:searchBar_ID:system". You can run "xwininfo -tree -root" to get a better idea. And to dig deeper into this start with "addClient" function in "lab126LayerLogic.lua". The example shows keys L, N and ID but there are few more which are not necessary. Key N defines the type of an application and for normal 3rd party windows the value 'application' seems the right choice. ID seems to be either name of the window or the application (probably the former). The L defines on what layer you want your window displayed.

The available codes for the various layers are the following (from lab126LayerLogic.lua):

A -- Application Layer
C -- Chrome Layer
D -- Dialog Layer
KB -- Keyboard Layer
SS -- ScreenSaver Layer

Here's a piece of content of rc.lua explaining how are the layers organized:

-- Z Stack Layers matching
-- internal layers in Awesome
-- 0 and 1 are used by awesome
-- and we do not use them here
LAYERS = {}
LAYERS.HIDDEN = 2 -- hidden
LAYERS.BLANK = 3 -- below
LAYERS.APP = 4 -- normal
LAYERS.CHROME = 5 -- above
LAYERS.DIALOG = 6 -- dialog
LAYERS.KB = 7 -- KB
LAYERS.ALERT = 8 -- ALERT
LAYERS.FULL = 9 -- FULL, not used
LAYERS.SCREENSAVER = 10 -- ontop

If your window name doesn't comply to the naming scheme above your window is automaticaly placed on layer HIDDEN. The layer BLANK seem to contain just one black window covering whole screen (so as to hide what is to stay hidden). The rest should be self explanatory.

That's all for the moment.

[bhaak]

Thanks, that was really helpful.

Just a small FYI, you can test out different window titles by using xev, for example "xev -name L:A_N:application_ID:x11xev".

This little X11 helper program is installed by default on the Touch and will print out any X11 event it receives.

[Nyoxi]

Originally Posted by bhaak

Just a small FYI, you can test out different window title by using xev, for example "xev -name L:A_N:application_ID:x11xev".

That's a nice tip bhaak.

Since it seems that this is interesting to more people I will share again the few things I have learend recently (since my new post).

Chrome layer contains the searchbar on top and ads on bottom (for SO version).
Window title is contained in special window called titlebar.
Titlebar is normaly on chrome layer.
If PC:N titlebar behaves like a chrome (e.g. hides when chrome hides). (TODO: find
out when chrome hides and if it's of any use)

params:

L   str  layer
N   str  window type: "application", "dialog", "pillowAlert", ...
ID  str  name of the window or the parent window for dialogs
         "system" is reserved for system stuff
PC  str  "N" - set size to full screen
         "TS" - size to show chrome layer
         other or missing - normal window, size so that title bar is visible
         valid for L:A only
M   bool modal dialog window
         valid for L:D only
RC  bool round corners of the window
RKB bool requires KB -- positioned so as to expect showing keyboard
         valid for L:D only

bool value is expected to be: "true"/"false"

[silver18]

Is it possible to use this naming scheme to hide the status bar while running something like this?

https://www.mobileread.com/forums/sho...d.php?t=169216

Thanks a lot!!

[Nyoxi]

Originally Posted by silver18

Is it possible to use this naming scheme to hide the status bar while running something like this?

What do you mean by statusbar? (I couldn't find any screenshots)