[fastrobot]

Originally Posted by davidfor

I have no idea where it is. The options are in libnickel and I assume it interprets them. Whether the telnet implementation is part of nickel or it simply enables something somewhere else, I don't know and have only a passing interest in finding out. When I'm curious about something, it works.

No problem. As I said, I already compiled a telnet host replacement.

What inconsistency? As I keep saying, and no one seems to believe me, the firmware is identical between the devices.

I didn't mention the inconsistency to you, rather it was to another poster; but I'll answer you anyway.
I know that the updates, which are partial replacements -- are in fact identical; because I know I use the same one for both the AuraHD and the Glo. It's not a matter of disbelief in you personally, it's rather I'm baffled as to why my kernel driver works on one device perfectly but is causing the other device to lock up semi-randomly. If they were truly identical, that shouldn't happen... but it does. There may be other explanations for why it's locking up besides differences in the Glo and AuraHD -- But I just can't think of any that make sense off the top of my head.

And yes the kernel is different and that should account for the rest of the hardware differences but is probably built from a common source.

Hmm... I didn't know that -- and hadn't thought about that, for I only compiled my driver against the source code in KoboLabs/Kobo-Reader/hw/imx507-aurahd. The reason is that I downloaded the git repository a month ago -- and there wan't a directory in my clone of the github labeled KoboGlo. So -- since the updates are identical, I assumed the kernel had to be identical.

I just went back to browse git-hub to point out which directory I compiled from, and to point out that there was only AuraHD and not a Glo directory -- but to my shock, I now notice that a Kobo Glo directory was added 20 days ago called "glohd".

sigh.

https://github.com/kobolabs/Kobo-Reader/tree/master/hw

So -- there's an another example of an inconsistency ... which if that kernel proves to be the Glo's kernel (and maybe it's not); it was a belated posting to KoboLabs which caused me to waste my time .... (and yours in dealing with me...). It would have been nice if I knew for sure which kernel my Glo ran the first time I downloaded the repository.

The thing is that what most of us see when using the device is identical running taking the hardware differences into account. And everything running behind the scenes is the same.

And specifically, the developer options and telnet work on all the Kobo devices I have.

I've never tried the depeloper option; so that may well be true. I'm not contradicting you, just stating my experience with trying to follow other instructions found in these forums.

The same goes for all other options that aren't hardware dependent (no light, no function and only the Aura supports mult-touch).

I read through the driver for the zforce-ir-touch, and basically -- that's just a software driver issue. The hardware reports enough information to do multi-touch in the Aura-HD for sure, and the Glo could do it as well -- though I'm not sure the stock driver for multitouch will work on the Glo.

For the rest of your question, sorry I can't help. I have little experience and knowledge in this area, and to be honest, very little interest.

NO problem. I found a copy of gdbserver binary on my rasberry PI, which is also an ARM processor -- and it just so happens that the server runs on the Kobo AuraHD perfectly. So, I'm able to do remote debugging now, and will be able to find the cause of the bug soon.

Thanks for your time.