Hi guys,
after having some trouble with the haret-0.3.2 from
the xanadux site, i've managed to
find the framebuffer address, 'dump mmu',
watch the e/gpio lines and dump ms-registry
over wireless.
The hardware looks very similar to Himalaya,
but there are some minor differences.
The himalaya kernel doesn't boot, but that
can be a haret fault.
If somebody wants to help/advise/supply me
with the patches/wiring for the serial console,
i'd like to hear from you !
I would like to help any way that I can.
I'm awaiting a Sprint PPC-6600 Blue Angel and want to be able to use a Linux distribution for it.
I'm not experienced with much beyond compiling x86 kernels and drivers while following a recipe, though.
Anything I can do to help?
Re: I would like to help any way that I can.
philverb said:
I'm not experienced with much beyond compiling x86 kernels and drivers while following a recipe, though.
Anything I can do to help?
Click to expand...
Click to collapse
I think there are two areas where useful things can
be done right now: to patch the bugs in haret
(some lowlevel wince knowledge required), and to
describe the hardware details in wiki.
To support the basic CPU/USB/framebuffer& ramdisk is
not really difficult, since we have Himalaya code in the handhelds CVS.
The next crucial and complex step will be to understand how ATI Imageon supports the SDIO.
The next important thing is to port a driver for
the ACX100 wifi chip. The guys working on
HPAQ hx4700 (also designed by HTC) have it too
and made some progress.
Hey there!
Okay, long story short:
I've got a Toshiba Intermec CN3 device (has USB Host controller) I would like to develop a driver for a USB scanner. Can anybody give me some tips on what needs to be done in order to achieve this?
The problem is that i can't get the Windows Mobile Platform Builder/Developer... because it's way to expensive.
I was thinking of trying to port the USB Scanner Support for Linux...
I know it might sound silly but i looked everywhere and i couldn't find something like this already done. Do you know of any similar drivers?
Thanks guys!
one dont require the platform builder to make or install a driver
for wm
a search for something like this could get you in the general direction of developing
devices drivers for windows mobile
http://www.google.dk/search?source=...+mobile&btnG=Google-søgning&meta=lr=&aq=f&oq=
The guy who started this thread - http://forum.xda-developers.com/showthread.php?t=480899&highlight=zeno+usb - will probably have some answers or tips.
Thank you both for replying.
@Rudegar i don't think you've understood my question ... i don't want to develop a driver for windows XP/Vista that will support a WM device.... what I need is to write a driver to be installed ON a specific windows mobile device that is capable of USB Hosting.
So the way i see it, when you connect a scanner (for example) to the device, the device should then recognize the scanner make it possible for the user to scan documents (for example) directly from the device...
@aiiro i've already pm'ed the guy, hopefully he'll notice my message
Hello everyone,
i was wondering if anyone could give me any tips about how to communicate with android device through usb from c++ or java(i guess that won't work without JNI though). I was trying to google up some documentation on this matter but found nothing. I wanted to program something like 'nokia ovi' suit as my b.c. 'thesis'.
Thanks for reading this, Tomas Herman
Hi,
Did you found any info on this ?
Certainly should be possible since Sync applications are working ...
Daniel
Yes, this is possible but AFAIK only as a hack. You can install the USB driver for the SDK and use adb's port forwarding. See /code.google.com/p/android-notifier/ as an example. Obviously, not an elegant solution and definitely not for the general Android user.
Hello XDA developers,
As you know, Atmel maXTouch touchscreen controllers are used in a large percentage of Android phones and tablets out there.
I wanted to let you know that the latest patches for the official Atmel maXTouch Linux driver are available on GitHub. This will allow you to get the latest up to date changes before they make it into the mainline kernel.
On GitHub, search for user "atmel-maxtouch"
Happy hacking
Best regards,
Sherif
Product Marketing Manager - Atmel
thank u for ur valuable information, well can u pls post what are the latest changes and updates. that will help the devs much more.
Hi showlyshah,
The latest updates include the following:
- Support for Atmel's mXT224E, mXT768E, and mXT540E chipsets
- Support for both protocol A and protocol B reporting
- Support for kernel 3.0 in addition to kernel 2.6.35
More details are available on GitHub in the release notes.
Regards,
Sherif
Is https://github.com/atmel-maxtouch the correct URL?
Unfortunately, if it is, the drivers in this repository are structured completely differently from the ones included in many vendor source drops, and unfortunately this causes great negative impact on their usefulness.
See, for example:
https://github.com/Entropy512/linux_kernel_sgh-i777/tree/master/drivers/input/touchscreen - This includes the mxt224 drivers as implemented by Samsung on their device (Galaxy S II)
https://github.com/atmel-maxtouch/linux/tree/master/drivers/input/touchscreen - mxt224_u1.c is completely missing, indicating that the driver here is incomplete or structured very differently from the one used by Samsung, making it very difficult to use. Also, the few files there that do pertain to Atmel MXT such as atmel_mxt_ts.c in there appear identical to the mainline Linux repo.
Entropy512 said:
Is https://github.com/atmel-maxtouch the correct URL?
Unfortunately, if it is, the drivers in this repository are structured completely differently from the ones included in many vendor source drops, and unfortunately this causes great negative impact on their usefulness.
Click to expand...
Click to collapse
But it's not Atmel who are to blame. Atmel are doing a great job working directly with upstream so that all the users of mainline linux can benefit. I have been using the drivers from the vanilla kernel for quite a while on both my tegra tablet (with chromium kernel) and galaxy s2, and they work just fine, supporting multitouch in xorg in ubuntu.
The problem is OEMs who do crap like hardcoding/hacking drivers instead of using platform data, use machine-specific hacks, custom interfaces and a lot of copy-paste. That's the essence of modern consumer electronics business - no one cares for quality, only about releasing early.
Entropy512 said:
Unfortunately, if it is, the drivers in this repository are structured completely differently from the ones included in many vendor source drops, and unfortunately this causes great negative impact on their usefulness.
See, for example:
linux_kernel_sgh-i777/tree/master/drivers/input/touchscreen - This includes the mxt224 drivers as implemented by Samsung on their device (Galaxy S II)
atmel-maxtouch/linux/tree/master/drivers/input/touchscreen - mxt224_u1.c is completely missing, indicating that the driver here is incomplete or structured very differently from the one used by Samsung, making it very difficult to use. Also, the few files there that do pertain to Atmel MXT such as atmel_mxt_ts.c in there appear identical to the mainline Linux repo.
Click to expand...
Click to collapse
I think you're looking at the unchanged mainline branch: the driver releases are as tags.
The advantage of these drivers is that they are generic for all chips in the maxtouch series. mxt224_u1.c is just a renamed atmel_mxt_ts.c, it contains lots of mxt224 specific configuration and it's unlikely that it will go upstream.
You will also find some user-space tools for extracting config files in a format the kernel driver can load, on the same github account.
Missed the tags, thanks for the additional info!
I'll look into maybe playing with this when ICS time rolls around. It's getting late in the game to do a major driver rework on the Gingerbread kernel I maintain.
sherifhanna said:
Hi showlyshah,
The latest updates include the following:
- Support for Atmel's mXT224E, mXT768E, and mXT540E chipsets
- Support for both protocol A and protocol B reporting
- Support for kernel 3.0 in addition to kernel 2.6.35
More details are available on GitHub in the release notes.
Regards,
Sherif
Click to expand...
Click to collapse
Hi Sherif,
I found the project in Github, but am not able to find the the release notes. Does this driver support the Atmel mXT336S at this time?
Thank you
Hi omaha64,
Support for mXT336S is in progress.
Regards,
Sherif
Question,
I am trying to back-port the 2.6.35.7 driver to 2.6.32. I have mostly succeeded, but probe() fails because of missing platform_data. Digging through the driver code, I found the platform data structure in include/linux/i2c/atmel_mxt_ts.h:
Code:
struct mxt_platform_data {
unsigned long irqflags;
u8(*read_chg) (void);
};
So I assume that in my board file (where my i2c_board_info arrays live) I would want to create a static instance of the above struct and store a pointer to it in the .platform_data member of the i2c_board_info struct, right? But what is the preferred initialization, and what is read_chg supposed to actually do? What's the consequences of just setting it to NULL? (I know it won't crash because the driver checks it before calling it)
Need atmel mxt224 driver for Windows embedded compact 7
sherifhanna said:
Hello XDA developers,
As you know, Atmel maXTouch touchscreen controllers are used in a large percentage of Android phones and tablets out there.
I wanted to let you know that the latest patches for the official Atmel maXTouch Linux driver are available on GitHub. This will allow you to get the latest up to date changes before they make it into the mainline kernel.
On GitHub, search for user "atmel-maxtouch"
Happy hacking
Best regards,
Sherif
Product Marketing Manager - Atmel
Click to expand...
Click to collapse
Hi,
Can you please send me the multi touch driver for ATMEL MXT224(Stream interface PDD layer) for Windows Embedded compact 7.
Thanks in Advance,
Rag
Android Driver Initialization
Hi,
I would like to use MaxTouch mxt224 on a TI am335x-evm board running Android ICS, I'm looking for documentation on how to initialize mxt224 driver from board's configuration file. Can someone help me?
Thanks.
ceskobassman said:
Hi,
I would like to use MaxTouch mxt224 on a TI am335x-evm board running Android ICS, I'm looking for documentation on how to initialize mxt224 driver from board's configuration file. Can someone help me?
Thanks.
Click to expand...
Click to collapse
.
I don't know if there's such documentation to tell you how to initialize. At least a sample exists; look here:
arch/arm/mach-exynos4/mach-nuri.c
The values in "mxt_init_vals" come from Atmel's mxt224 datasheets/manual, so you'll have to find those. I would be surprised if you could not find these by Googling. When I was trying to get the mxt224 to work on an Omap4 board, I had to hack up the driver a little to handle the reset going to the IC, and to handle the /READY line from the IC to the host. Also, for ICS, you will need to have an IDC file in your root file system. Just Google for "Android Input Device Configuration File" (I'm new here and cannot post links yet).
Without that IDC file, Android considers the touch device to be a pointing device (like a mouse).
Good luck
Atmel Mxt768e Driver details
Hi Sherif & All,
Can you please share the atmel MaxTouch mxt768e driver link, I would also request you to share the driver which has the implementation for fIrmware upgrade.
Thanks,
Balaji S
Is there some place I can learn to understand and modify these? I've never done driver development before. Before I waste any time with this, can someone confirm if the input lag in most devices is because of filtering in the driver or because of the Atmel hardware?
KurianOfBorg said:
Is there some place I can learn to understand and modify these? I've never done driver development before. Before I waste any time with this, can someone confirm if the input lag in most devices is because of filtering in the driver or because of the Atmel hardware?
Click to expand...
Click to collapse
I don't think you'll be able to find a single place that describes the driver. Luckily, these drivers are small, the mxt224 is just a single C file. I've looked at the mxt224/mxt336, so the following info is specific to those. Some high level info for you to get started:
* The driver allows the exchange of "objects" between the touch IC and the host processor. To understand what the objects are, you'll need to find the datasheets/manual for the chip you're using. Just try Googling for it. Objects from the host to the IC are typically configuration data, and objects from the IC are probably touch data
* In the case of the mxt224/336, the driver needs the I2C driver
* The driver has a structure that needs to be setup from your board file (example arch/arm/mach-omap2/board-???.c). This structure has some configuration data needed by the driver
* Typically, there's a reset line that has to be pulled high on the board. May need pinmuxing to set the functionality of the pin correctly.
* The IC will also have a /CHG line that will go low when it has data to send to host. You will need to set up pinmuxing for this pin as well.
* The driver has an interrupt routine handling the /CHG line. When a touch/drag happens, objects will be sent to the driver to process. The driver formats the data and forward that up to the user space via the input subsystem.
* If you're doing this for Android, you'll need an .idc file in your root file system. Info: {link removed because I'm new. Just google Android IDC }
* The driver will look for a config file in /system/vendor/firmware, upon starting up
I can't comment too much on the lag you're talking about because I don't know the nature of the lag you're seeing. But I can tell you that the Atmel touch IC needs a "tuning" process where the internal parameters have to be adjusted to operate properly.
If you find more info on this subject, please post it here.
omaha64 said:
I can't comment too much on the lag you're talking about because I don't know the nature of the lag you're seeing. But I can tell you that the Atmel touch IC needs a "tuning" process where the internal parameters have to be adjusted to operate properly.
If you find more info on this subject, please post it here.
Click to expand...
Click to collapse
The "lag" is because the touchscreen does not recognise fast taps. You must press and hold your finger on the screen for several milliseconds before it actually recognises a touch. If it was purely a latency, then even a fast tap would be recognised after a delay. In this case, only a continuous press of a minimum duration is recognised. This makes the screen unresponsive and useless for games that need taps.
Is this something that can be resolved in the driver? I have a feeling this is coded in the firmware blob that gets uploaded to the touchscreen on initialisation.
KurianOfBorg said:
The "lag" is because the touchscreen does not recognise fast taps. You must press and hold your finger on the screen for several milliseconds before it actually recognises a touch. If it was purely a latency, then even a fast tap would be recognised after a delay. In this case, only a continuous press of a minimum duration is recognised. This makes the screen unresponsive and useless for games that need taps.
Is this something that can be resolved in the driver? I have a feeling this is coded in the firmware blob that gets uploaded to the touchscreen on initialisation.
Click to expand...
Click to collapse
I believe that if the issue you're describing is due to the IC's noise rejection algorithm, then you may be able to alter that in the driver. There are params in the chip such as number of valid ADC samples for the touch to be recognized as a true touch, that you can play with. But I don't know if you can change these parameters on the fly, or has to be done at start up. I haven't played with these params. See if you can grab hold of a "Protocol Guide" for the touch controller that you're working with. That shows all the params that you can change. In fact, you may be able to alter some of these params without having to touch the driver; search for mxt_app in github. I've used mxt_app to load configuration and change T9 object before, but that's the extent of my use of it.
Thanks for your help. Time to start reading. Some of the mach-* initialisation params can be changed at runtime such as the Vitalij value.
What is the real world best case input latency of these controllers? Can the Galaxy S2's touchscreen actually be made as good as the iPhone 5 or are the iPhone controllers simply superior?