Android Tablets Forum banner

Bounty for Working Debian with Touchscreen Driver for the Eken m001

79K views 251 replies 40 participants last post by  seba1978 
#1 · (Edited by Moderator)
Following the fantastically successful software bounty started by xdpirate (for Win CE with touchscreen support), I'd like to start a bounty for Debian with touchscreen support.Thousands of sophisticated applications await an onscreen keyboard and finger stroke. And this time no fear of secret agents from Redmond saying nix. Just the satisfaction of knowing the world is ten digits more accessible. What could be better? Amaze your friends!I'll throw in $25 to start it off(As xdpirate created the last bounty, I'll quote his words here -- with OS name changed to protect the innocent...): This is a donation thread. Offer up any amount you'd be willing to pay to the person(s) who gets Debian fully working, with touchscreen drivers, and I'll list you here, with username and amount.Donor list:vtpad - 25 USDSlateDroid - 50 USDbobobobo1618 -10 USDTotal prize pool: =85 USDPM me (vtpad) or post in this thread with the amount you'd be willing to donate for a working Debian touchscreen build. If a team releases it, it will be donated to the leader of that team. If several people get it working at the same time, it will be split. If a single person performs this feat, they will collect all the donations. There is no minimum donation amount. You can donate everything from $1, so feel free to chip in with any amount!BREAKING NEWS!!!! Debian with touchscreen a reality on the Eken M001! Won by by jacob019. See Post #33
 
#4 · (Edited by Moderator)
The netbook steps don't work without a bit of tweaking. If you follow the steps on this page then you'll be able to run Debian on the M001:http://projectgus.com/2010/07/debian-on-the-eken-m001/You still won't have a functioning touchscreen, though. If the promised kernel source release from VIA comes, then this should be quite easy. As-is, I could get it to register one touch with coordinates but no subsequent touches had coordinates...
But I didn't try very hard. If people really want it, then I'll have another poke around.
 
#6 ·
hello allOnce again Team SlateDroid would like to offer fifty dollars for a working touchscreen version of debian linux I personally think Projectgus will be the one to pull it off as I have read his blog. But if not good luck to all ThanksThe SlateDroid Team
 
#10 · (Edited by Moderator)
imayoda;21838]ehm.. armv7 means cortex.. we can hope for debian as they still compile in armv4 aka oldest arm7 processors <img src= said:
Though' date='[QUOTE'] Ubuntu jaunty targets the ARM EABI, with an expectation of minimum compliance with the ARMv5t instruction set.
Slack on the other hand:
Target Minimum CPU Starting with Slackware ARM 13.1, packages are compiled for the following minimum target:
  • ARMv4t
  • Little endian
  • EABI (Version 4+)
This means that the user space will run on the majority of ARM devices on the market today. Unlike the x86, usually each type of ARM device requires a specific kernel. So even on an "unsupported" ARM device, the majority (if not all) Slackware ARM packages will run on the device, you will need a specific Linux kernel for your device. Please read this article for a great introduction to this topic. Debian also have a detailed discussion regarding "old" and "EABI"
But of course, I don't mean to distract here from the Debian effort.
 
#12 ·
Back to theoriginal topic, is there anything to be learned about touchscreen drivers in the WinCE version now working on the Eken that could be of value to the Debian touchscreen effort?
 
#13 ·
[quote name='vtpad;22196]Back to theoriginal topic' date=' is there anything to be learned about touchscreen drivers in the WinCE version now working on the Eken that could be of value to the Debian touchscreen effort?[/QUOTE'] i think not, cause driver approach is slightly different from win to linux kernel... :(too bad.. bushing should be more informed about this, as he is rebuilding the wm8xxx kernel.. i think
 
#15 ·
fering;22265 said:
I am far from a linux expert wouldn't the opensource driver from Wolfsonmciro help?
It would! Coincidentally, the WM97xx drivers from Wolfson are now part of the main Linux kernel tree - as of 2.6.29 (coincidentally the same version that the M001 is running.)However, for reasons unknown, VIA chose to reimplement WM9715 support in their own proprietary kernel modules - wm9715-api.ko and friends.So, a while ago I tried compiling the open source WM97xx modules and loading them in place of wm9715-api.ko. However, this doesn't work.The reason, best as I can tell, is that WM97xx is connected via an ac97 bus (same bus as the audio.) The standard Linux kernel has a module called ac97_bus that provides access to the bus, this is what the open source WM97xx drivers use. VIA, for whatever reason, seem to have their own ac97 support which is just called 'ac97'. The two are not compatible, and VIA's ac97 support is compiled in to the kernel so it can't be removed - preventing the open source ac97_bus for working.That's what I think is going on, anyhow.However, there is some good news. I had another quick look last night, and I think I might have identified two custom ioctls that are used to initialise VIA's WM97xx driver. When I have time (maybe over the weekend) I'll write a little program that calls the ioctls and we'll see if that's enough to get the touchscreen talking to us properly.If that doesn't work, if VIA release the promised kernel sources then we should be able to remove their proprietary ac97/WM9715 support entirely and roll it all into the existing open source modules.
 
#16 ·
[quote name='imayoda;22197]. bushing should be more informed about this' date=' as he is rebuilding the wm8xxx kernel.. i think [IMG]http://www.slatedroid.com/public/style_emoticons/<#EMO_DIR#>/smiley.gif[/IMG][/QUOTE']Wow.......
 
#22 ·
I've been spending many hours trying to figure this thing out. I can confirm that the input/event device is sending only pressed data but no coordinates. I ran the evtest app under android and the data is running fine. The WM9715L datasheet shows the register addresses that adjust the mode of operation (see p43). I believe that these can only be adjusted through the closed source drivers through some ioctl calls, but they are undocumented. I've been trying to locate the hardware initialization code in android in hopes of finding the appropriate ioctl calls.I decompiled com.wmt.BootReceiver.apk: http://jacobstoner.com/BootReceiver.tar.gzI'm not very good with Java, but it's all wmt specific code that loads the touchscreen calibration data. I couldn't find any hardware specific calls there, maybe you will have more luck.There are also 5 interesting libraries: libubootenv.so, libwmtapi.so, libpointerboot.so, libpointercal.so, and libpointertch.soI tried to disassemble them with objdumb, but it doesn't recognize the architechture. Maybe someone can point me in the right direction to disassemble them. My money is on the initilization code being in one of these libraries.My next effort will be to try and fire up android in a chroot jail to initialize the hardware. If it works we can set it up to run at boot, die after 10 seconds, and continue with the debian boot process, but I am doubtful as to whether it will run without the andriod init. I'm goint to try translating the init.rc into a shell script. Anyone know if it's possible to run a new init process inside a chroot?Please help!
 
#23 ·
jacob - nice progress.If you can track down the forum post with hex-rays disassembled library code (looks like the forum admins have broken all static links again, so good luck!) then there are some calls to ioctl() on the touchscreen driver (grep for /dev/touchscreen).If you run strings on the module itself, then you can see reference to two ioctl constant names - one is something like _START_CALIBRATION and the other one is _CALIBRATION_DONE.I think these are same ioctl values, the decompiled code seems to call one ioctl and then sit in a loop waiting for the other ioctl to succeed. I'm guessing the first is "start" and the second is "wait until done". There's a third ioctl value in there as well though, so maybe my guesses are wrong.I intend to write a little C program that makes these calls, and see where I end up, but I've been busy so I haven't had time yet. Let me know if it works for you, and I'll let you know if I get time to try again.
 
#24 · (Edited by Moderator)
Thanks for pointing the way projectgus. We're getting so close...It seems the driver is waiting for calibration data. Once calibrated the event device starts emiting coordinate data.I got the ioctls working, sort of... There are three calls:0x7401u (TS_IOCTL_CAL_START)0x40047402u (TS_IOCTL_CAL_DONE)0x80047403u (TS_IOCTL_GET_RAWDATA)We can call any of them with a c program:
Code:
#include <fcntl.h>#include <sys/ioctl.h>int main(){	int fd;	fd = open(&quot;/dev/touchscreen&quot;, 2);	//ioctl(fd, 0x7401u); //TS_IOCTL_CAL_START	ioctl(fd, 0x40047402u, &quot;TEST&quot;); //TS_IOCTL_CAL_DONE	//ioctl(fd, 0x80047403u); //TS_IOCTL_GET_RAWDATA}
Each ioctl produces output in dmesg. TS_IOCTL_GET_RAWDATA produces large number coordinate pairs in dmesg.TS_IOCTL_CAL_DONE loads the calibration data and initializes the event device. Once this is called we start receiving data with evtest, albeit junk data without a valid calibration.TS_IOCTL_CAL_START must be used for creating a new calibration file. I don't think we need it now since we can just borrow the calibration file from Android.We know the calibration data since android stores it at /etc/touchcalMine is:-129 -26283 105670863 15925 -268 -1091734 128609The only call we need is TS_IOCTL_CAL_DONE. The calibration data is sent with the ioctl as the third parameter. I'm not sure yet how to structure the data. Interestingly if I pass a string, different numbers are loaded for different strings. Integers don't work. There is some data structuring code that works with these numbers in libpointerboot.c, but I'm not very familiar with this language, so it will take some time to determine the proper way to structure the data for this call.We're right on the verge here. If we can just load in the calibration data then our touchscreen will work.We're now down to just one parameter. I need to sleep now, but I hope someone else can give it a crack.---Check out www.jacobsparts.comWe sell computer components and accessories at unbeatable prices.
 
#26 ·
Jacob, I've had a quick play today, and a new read of the hex-rays decompiled source.I might be wrong, but I don't think we're going to nail this easily. It looks like there's a bunch of calculations that are done in userspace in order to complete the calibration, and I don't think there's enough info there to really reverse engineer those without a lot more work (they're C++ calls I think, the 'a1' parameter is the object the function pointer calls to ()(a1+X)() are instance methods, and hex-rays doesn't done much of a job of decompiling those.)I thought JNI_Load in libpointerboot might be a good entry point to just call the library from debian and get it to do its thing, but it looks like the library it actually loads JNI data across from the Java side so that's probably too complex to consider.Given that it looks like (touch wood) we'll be getting proper kernel source in the next few weeks, I think the best course of action is to wait for that and then drop VIA's module altogether, replacing it with the proper open source AC97 support & WM97xx touchscreen driver.Good luck if you keep at it!
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top