xmahjongg for Kindle as Kual extension

[NullNix]

Originally Posted by NiLuJe

That error message is fairly straightforward: your app depends on libX11.

You need to build libX11 . Which may or may not depend on a full XOrg install, can't recall, and not on a Linux box to check right now.

You need a bunch of proto headers and other libs (xcb, xtrans), but nothing more than that: only a small percentage of the full X11 tree. xcb needs Python, but only at build time. It's much better than the old days of xmkmf when all you had was 'make World'.

[knc1]

Try this one, it is already built:
https://packages.debian.org/jessie/a...jongg/download

There has been a lot of posts here on un-packing and running Debian packages in user storage (without a chroot).

[Hanspeter]

Originally Posted by knc1

Try this one, it is already built:
https://packages.debian.org/jessie/a...jongg/download

There has been a lot of posts here on un-packing and running Debian packages in user storage (without a chroot).

Thanks, will give it a try.

[Hanspeter]

Originally Posted by NiLuJe

That error message is fairly straightforward: your app depends on libX11.

You need to build libX11 . Which may or may not depend on a full XOrg install, can't recall, and not on a Linux box to check right now.

Once it's installed, it should be in a standard path (provided you configured it with the right --prefix), and you won't have to tinker (more than usual) with CPPFLAGS/LDFLAGS.

Did I mention that building GUI stuff risked getting hairy fairly rapidly? ^^.

Hm, that's worth then I expected. I hoped that I only need to copy some header files and some libs from the kindle to the tool chain.
Now know why there is less documentation here about how to work with the tool chain. The tool chains I worked with before had all the libs and headers that are available on the device already included.
So I only needed to add or compile the tools that where not already on the device manually.

Hanspeter

[knc1]

It builds native on your pc, so use the a copy of the headers that are installed there.

Copy the libraries required from the Kindle itself.

No need to re-build X11 (it would probably just come out wrong anyway).

[knc1]

Originally Posted by Hanspeter

- - - - -
So I only needed to add or compile the tools that where not already on the device manually.

Hanspeter

Things have changed, this is not as difficult as it may seem.

You have a fairly recent Linux distribution (Ubuntu did you say?).
You will want a flavor that is running the same or at least nearly the same kernel version as the newer touchscreen devices (3.0.x).

Install full binfmt_misc support (which should include qemu-static).

Now you can simply execute any arm binary on your Intel/PC.

Then install an armel (Debian/Jessie is a good match for recent touchscreen devices) distribution in your directory tree.

Add qemu-static to that tree.

Now when you chroot into that directory, everything will 'just work' and you can do native builds for the Kindles.

There are lots and lots of 'HowTo' documents on the 'net for the above process.

[Hanspeter]

Originally Posted by knc1

Things have changed, this is not as difficult as it may seem.

You have a fairly recent Linux distribution (Ubuntu did you say?).
You will want a flavor that is running the same or at least nearly the same kernel version as the newer touchscreen devices (3.0.x).

Install full binfmt_misc support (which should include qemu-static).

Now you can simply execute any arm binary on your Intel/PC.

Then install an armel (Debian/Jessie is a good match for recent touchscreen devices) distribution in your directory tree.

Add qemu-static to that tree.

Now when you chroot into that directory, everything will 'just work' and you can do native builds for the Kindles.

There are lots and lots of 'HowTo' documents on the 'net for the above process.

I wasn't aware of that approach. You are right my last cross compile is about 8 years ago. It was for the VDR project on the Siemens M740AV DVBT/SAT receiver http://open7x0.org/

I understood what the idea of the new setup is and I like it. Will have to dig into it and document my results. So I can add it to the Wiki when I find the time later on.
Because that was the first place, after the forum, where I tried to find information or a how to about compiling code for the kindle. But this will take some time as my spare time for this projects is limited.

HaPe

[Hanspeter]

Originally Posted by knc1

Try this one, it is already built:
https://packages.debian.org/jessie/a...jongg/download

There has been a lot of posts here on un-packing and running Debian packages in user storage (without a chroot).

I got forward with that one. Attached a wrapped Kual extension, that can start it but you do not see the window as it is below of all other windows

So that is what I have at the moment trying with two shell windows:
1st Window to start the game:
[root@kindle root]# cd /mnt/us/extensions/xmahjongg/
[root@kindle xmahjongg]# ./run.sh
^C
[root@kindle xmahjongg]#

2nd Window to try to get the window shown:
root@kindle root]# export LD_LIBRARY_PATH=/mnt/us/extensions/xmahjongg/lib:$LD_LIBRARY_PATH
[root@kindle root]# xwininfo -tree -root | awk '/xmahjongg/{print $1}'
0x1600004
[root@kindle root]# xwininfo -tree -root | grep home
0x1200026 "L:A_N:application_ID:com.lab126.booklet.home_M:fa lse_PC:TS_RC:true_WT:true_O:U_WTNB:true_WTPB:false ": () 758x899+0+125 +0+125 MapState=IsViewable
0x120004b "L_N:non-centered_ID:com.lab126.booklet.home_M:dismissible_ RD:false_FH:F_CD:true_TAC:search-bar_TAB:menu_RC:false_HIDE:background_BS:true_A:Ki ndleMenu": () 517x786+231+121 +231+121 MapState=IsViewable
[root@kindle root]# /mnt/us/extensions/xmahjongg/bin/xdotool windowreparent 0x1600004 0x1200026
[root@kindle root]#

That gets the window above the home window. You can see it, but the touches are not send to it. When you stop the game with ctrl+c in the other shell window you see that your touches where record and now send to the home window.

[root@kindle root]# /mnt/us/extensions/xmahjongg/bin/wmctrl -r xmahjongg -b toggle,above
then wait about 30 seconds and the game window will pop up. It is payable, but the graphics is messed up for whatever reason.

I call it a day now. I'm out of ideas for today.
HaPe

[knc1]

Twobob posted a lot about how to bring the window to the top and in 'focus' -
Amazon uses a strange, encoded, window name IIRC.

Anyway, his posts are the ones to search for dealing with the native graphic stack.

[Hanspeter]

I found that out later and posted it, but for whatever reason the post was not saved.

when I start:
./xmahjongg -d 0 --name L:A_N:application_ID:com.xmahjongg_O:R_PC:N -B /mnt/us/extensions/xmahjongg/data/

It is working, but the display is a little bit messed up as you cann see in picture one.
As soon as I re parent it to an existing Kindel windows the display is fine, but it dosend accept any touches any more. When I then stop the program the touches was queued somewhere and now sent to the underlining window.

Re parent command to home windows:
/mnt/us/extensions/xmahjongg/bin/xdotool windowreparent 0x1600004 0x1200026

The result is seen in picture 2

I also attach the Kual extension that start the playable app with the messed up display as in picture one.
Hope that somebody has an Idea how to tell the app, perhaps by an environment variable, to set the right color depth. I expect that is the problem.

[sguerrini97]

If you are still looking in how to setup a cross toolchain, it's very simple on debian (should work on Ubuntu too): https://wiki.debian.org/CrossToolchains#Installation
Just use "armel" instead of "armhf" to have a working CC for Kindle.
Look at my Makefile here, you may need to change the one in the project (e.g. use arm-linux-gnueabi-gcc instead of gcc): https://github.com/sguerrini97/gtk_s...aster/Makefile
Header files are the same across platforms afaik, but you need the libraries either from the Kindle or from the debian armel packages.

I think what knc1 suggested is a better approach, just wanted to show an easier way.

@geekmaster thank you, that repository is interesting. I tried to build SDL for kindle in the past but I had problems with the mouse (touchscreen).

Edit:
Here is what knc1 suggested https://wiki.debian.org/QemuUserEmulation
Get the xmahjong source then

./configure --build=x86_64-linux-gnu --host=arm-linux-gnueabi
make

Binary file is "src/xmahjongg"
When I run it I get the same result as the first screenshot OP posted

[knc1]

Originally Posted by sguerrini97

- - - -
Edit:
Here is what knc1 suggested https://wiki.debian.org/QemuUserEmulation
- - - -

Thanks.
I couldn't find that link when I was looking for it.
That is one of the more clearly written set of directions.

If you want a good match to the touchscreen Kindles, use Debian/Jessie ARMel distro in the chroot.

[sguerrini97]

I did some simple change to the source https://github.com/sguerrini97/xmahjongg_kindle
Anyway I don't understand other's source code very well and I have no idea about the reason why the window is displayed like that.. It seems like it gets squeezed but I'm not sure

[Hanspeter]

Originally Posted by sguerrini97

I did some simple change to the source https://github.com/sguerrini97/xmahjongg_kindle
Anyway I don't understand other's source code very well and I have no idea about the reason why the window is displayed like that.. It seems like it gets squeezed but I'm not sure

Well done that you can compile it.
Take a look at the create_window function in main.cc line 378. There could be a problem with the attributes or the parent window.
https://tronche.com/gui/x/xlib/windo...ateWindow.html

First guess would be the attributes or the parent window. The Parent Window could be the problem as a reparent to a other window works.


Also Line 343 and following looks interesting as it it talking about the color depth:

    for (int i = 0; i < nv && !best_v; i++)
    if (v[i].visualid == default_visualid)
      best_v = &v[i];
  
  if (!best_v) {
    visual = DefaultVisual(display, screen_number);
    depth = DefaultDepth(display, screen_number);
    colormap = DefaultColormap(display, screen_number);
  } else {
  
    /* Which visual to choose? This isn't exactly a simple decision, since
       we want to avoid colormap flashing while choosing a nice visual. So
       here's the algorithm: Prefer the default visual, or take a TrueColor
       visual with strictly greater depth. */
    for (int i = 0; i < nv; i++)
      if (v[i].depth > best_v->depth && v[i].c_class == TrueColor)
	best_v = &v[i];
    
    visual = best_v->visual;
    depth = best_v->depth;
    if (best_v->visualid != default_visualid)
      colormap = XCreateColormap(display, root_window, visual, AllocNone);
    else
      colormap = DefaultColormap(display, screen_number);
    
  }
  
  if (v) XFree(v);

I would try to comment out or delete the if /else at the end that it always requests the DefultColormap.

  for (int i = 0; i < nv && !best_v; i++)
    if (v[i].visualid == default_visualid)
      best_v = &v[i];
  
    visual = DefaultVisual(display, screen_number);
    depth = DefaultDepth(display, screen_number);
    colormap = DefaultColormap(display, screen_number);

  
  if (v) XFree(v);

First guesses from looking inside the code quickly with no skills in x-Windows programming

Some docu about xLib programming: http://www.sbin.org/doc/Xlib/chapt_03.html

HaPe

[sguerrini97]

You were right about the color depth, with the default one the window is not messed up

I launched it from the ssh session.

Still some of the tiles are out of the screen, I tried to change some values that I tought were the sizes but I don't see any changes.