Related
*** PLEASE READ CAREFULLY BEFORE INSTALLING OR FLASHING ANY SOFTWARE POSTED IN THIS THREAD ***
The software posted here is for TESTING purposes only, Myself, NikMel or any of the posters of software, or links to software on this thread take absolutely no responsibility or liability for damage caused by the result of installing or flashing software or links to software found on this thread - correctly or otherwise, you do so on the sole understanding that you do so at your own risk.
-----------------------------------------------------------------------------------------------------------------------------------------------
Project Name: Polaris Project P3D
CAB Name: HTC-CA-Polaris-Drivers
Development and Testing Team: Bally3, NikMel, Neos2007, NuShrike, Rogro82
Bally3 - Development, testing and updates
NikMel - Development, ROM updates and testing
Neos2007 - Development, CAB updates, videos and testing
NuShrike - Development and code optimisation
Rogro82 - Development, code optimisation and testing
JesseW - Design & testng
11/10 - With the release of the 2D driver and also a rom dump of the long-awaited Toshiba G810 rom - We are temporarily suspending further development and discussion of the 3D driver whilst we pursue our other ambition of bringng better 2D capabilities to our devices.
Please see the Poilaris 2D Driver development thread here:
http://forum.xda-developers.com/showthread.php?t=435190
Thank you - we will continue the 3D driver improvement discussions shortly.
-----------------------------------------------------------------------------------------------------------------------------------------------
8/10 - Today, The P3D team are proud to announce the release of the P3D Polaris 3D driver in an installable (and uninstallable!) cab form through its partnership with the htcclassaction.org website. Our thanks to Chainfire and the Kaiser team for the creation and distribution of the cab file via its website and enabling the p3D team to concentrate on further development and improvement to the driver.
We wish them all the best
The link to the cab can be found on this page: http://www.htcclassaction.org/driverprogress.php#update_20081009_1
-----------------------------------------------------------------------------------------------------------------------------------------------
2/10 - Distributed new set of drivers that are compatible with the Polaris ddi to all rom chefs to test and integrate into their roms.
-----------------------------------------------------------------------------------------------------------------------------------------------
30/9 - Initial feedback from Itje's rom is encouraging - users express faster speeds with a few exceptions. NuShrike has success making the original Polaris ddi,dll work with the 3D driver - tested and confirmed working with improved results.
-----------------------------------------------------------------------------------------------------------------------------------------------
28/9 - Asked rom chefs to assist with testing with their own roms with the drivers cooked in - ije released a new version with 3D drivers.
-----------------------------------------------------------------------------------------------------------------------------------------------
27/9 - Testing continues with some impressive benchmarks from NikMels rom which has the files cooked in.
-----------------------------------------------------------------------------------------------------------------------------------------------
26/9 - Group set up for development team: http://forum.xda-developers.com/group.php?groupid=18
-----------------------------------------------------------------------------------------------------------------------------------------------
25/9 - NuShrike and Rogro82, our developers on this project had a breakthorough to fix the scrolling. Neos2007 created a cab which will be posted out to all testers on this project.
An updated video from Neos2007 of the non scrolling 3D acceleration can be seen here: http://www.youtube.com/watch?v=58PFxhIVeE0
A Cab file has been generated by Neos2007 for testing FOR the team - we will release a Public Beta after some testing.
PLEASE DO NOT POST REQUESTS FOR THE CAB!
------------------------------------------------------------------------------------------------------------------------------------------------
23/9 - After trying every angle to fix the scrolling we are now looking at help from NuShrike, a veteran from the CA Kaiser driver who has agreed to help us in porting the CA driver to the Polaris.
-------------------------------------------------------------------------------------------------------------------------------------------------
UPDATE: After much research and some interesting development work, NikMel has posted a rom which shows hardware acceleration working in concept! - you can see a few youtube videos here:
Neos2007: http://nl.youtube.com/watch?v=69_6zgIZLaU
SuperJMN: http://www.youtube.com/watch?v=0RMYnI23JB4
What you ask IS what we all want to know. Why the Kaiser, but not Polaris?
Is it capable to do it? It is not? Is is a matter of time?
Putting my thoughts to graphical paper here. it might help someone or it might not.
So when I enquired about whether the 3D driver for the Kaiser from htcClassAction.org would work on the Polaris, the answer was a resounding NO!..
Apparently the Polaris was missing a potential ddi.dll file that was rumoured to be included in WM 6.1.
UDK's Syrius R0 looked promising but the bugs forced me to look elsewhere so I flashed swtos new rom which claims to include the ddi.dll and have "3D Support", though swtos also mentions that there is NO hardware accelerated driver available for the Polaris.
Swtos' Rom included the 3D tests which show the D3DM demo cube actually moving at about average 3.2 fps but the lights program still shows HARDWARE RASTERIZATION: false and "Using system memory".
Athough there are clear speed differences from my UDK R8 rom, video playback is slightly smoother, overall rom speed after installing all programs faster its clear that apart from some tweaking and the ddi.dll file (or tweaking BY the ddi.dll file) this is only software acceleration.
So the question is:
IS THE POLARIS CAPABLE OF HARDWARE ACCELERATED 3D?
From my limited understanding of this, the only way to verify that the Polaris is running on hardware accelerated 3D mode is that the lights test should say "Using Video Memory".
I tried installing the kaiser 3D driver in the hope that now I have the ddi.dll file this may work. no such luck - exception errors etc..
So started looking at the dll files mentioned in the lights program and googled the file named on the first screen which was d3dmref.dll. I found this interesting article at Microsoft:
Failed on Direct3D mobile Test in Test Tools
Apparently d3dmref is a Microsoft D3D reference driver (not hardware accelerated)
(Continued)
------------------------------------------------------------------------------------------------------------------------------------------
Some questions then:
drdmref.dll is a referenced driver. So what is ddi.dll and what does it do specifically?
The ddi.dll performs better than the Samsung Omnio driver which in itself proved to show much improvement than before - why?
If we now have the required ddi.dll, what else needs to be done to make the HtcClassAction Kaiser 3D drivers work with the Polaris?
What other files are we missing?
Time for a break.. and hopefully someone might be kind enough to provide some answers.
SuperJMN said:
What you ask IS what we all want to know. Why the Kaiser, but not Polaris?
Is it capable to do it? It is not? Is is a matter of time?
Click to expand...
Click to collapse
Sure it is.. and here's hoping somehow we get an answer from someone.
Swtos, UDK, these guys must know a little though the actual 3D bit seems to be a carrot dangled to get everyone excited over individuals forthcoming roms.
udk does not directly answer the 3D question, swtos in his defense, has been blunt about the fact that HARDWARE acceleration doesnt exist in his rom which is fairplay.
bally3 said:
.....
So the question is:
IS THE POLARIS CAPABLE OF HARDWARE ACCELERATED 3D?
...
Click to expand...
Click to collapse
the think is, if the chipset have hardware alleleration, so the polaris have hardware acceleration. we just need the software to unlock it. a time ago i read something about the qualcomm chip and there where standing that the chip have hardware acceleration. i dont think that htc has made a new chip for the polaris so it dont have hardware acceleration. they just used the chip how it was.
Which would mean it should be capable and we should try to ascertain which, if any files are missing from the Polaris as opposed to the almost identically specced Kaiser which has now seen true hardware acceleration.
Of course it might be some simple tweaking to the registry or the dll files to make the classaction drivers working.
I Found this thread in these forums. Look at the last post:
Can anyone run the D3d Mobile samples?
"i,ve had kinda the same problem trying to get some of the samples to run on my trinity, try changing d3dmpp.AutoDepthStencilFormat = D3DMFMT_D24S8;
Dont know if its the same problem but it helped me out."
Anyone care to venture a thought?
This is an interesting article:
microsoft.public.win32.programmer.directx.graphics
might be old news, might be new but this Don Crouch guy seems to know his stuff. Of interest is this line:
"Any device manufacturer should be spanked for shipping this driver as it was only designed for generating golden images to test drivers against. MS prohibits it from being shipped on any device."
This is in reference to the d3dmref.dll which IS present in the Polaris!
Been reading the Kaiser thread to see if I could better understand the issue:
D3D or OpenGL ES hardware acceleration for Qualcomm MSM7200
Reading the last posts we now also have to consider another question if there is a heat issue and HTC were aware of it:
SHOULD we try to hardware accelerate the Polaris???
bally3 said:
Been reading the Kaiser thread to see if I could better understand the issue:
D3D or OpenGL ES hardware acceleration for Qualcomm MSM7200
Reading the last posts we now also have to consider another question if there is a heat issue and HTC were aware of it:
SHOULD we try to hardware accelerate the Polaris???
Click to expand...
Click to collapse
good point. i mean, does anyone have real problems because he dont have the drivers? tomtom could be a little more faster but it works. last time i drove over 350miles and was using tomtom all the time and the device got really hot. so if its true i dont think i will use the drivers....
another question....does the kaiser really have 3d drivers ? i dont read the hole story.
OK, putting the "should we" question aside I've been doing some more delving into why the HtcClassAction.org kaiser driver doesnt work out of the box (mainly cos we all would still like to see the Polaris doing hardware accelerated 3D - and who could blame us?
So heres what I've found out so far:
1. Kaiser driver is compatible with roms which include a ddi.dll file version 3.28 and up - someone mentioned 3.55(my file version in the swtos rom shows 3.13.0.0?)
2. We might be missing some required dll's (anyone fancy doing some digging here plz?)
... I'll investigate further!
thanks bally3 for those news...
ouioui01 said:
thanks bally3 for those news...
Click to expand...
Click to collapse
You're right welcome!
It seems this is the missing link, the wm6.1 that htc officially releases must have a ddi.dll file of 3.28 or above built into it, but I dont know what tweaks are meant to be involved to make a difference.
I'm currently looking for a ddi.dll ver 3.28 as mine is in the Windows directory so I'm assuming its not going to blow up if I try it! (might mean yet another HARD RESET - but it would only be my 10-11th reset since udk's R0 release! - and I always have my current swtos rom on my card ready to flash back if it doesnt boot).
Anyone find this file might want to post it - or brave enough to try it?
Reading this thread in the Kaiser forum, whilst looking for the illusive dll and its dependencies, I came across this thread which contains a ddi.dll file that I do have as a cab on my ppc and was wondering what it would do:
Tutorial - FIX The ClearType in Landscape
It mentions that any ddi.dll file under 3,28 must be a wm6.0 ddi file.
Seeing that mine happens to be 3.1 in swtos new rom which does seem to show some hardware improvements, am I looking in the wrong place or was the 6.1 rom built with a 6.0 dll simply with some jigger-pokery (sorry my technical expression!) to make it work better?
Will the OFFICIAL WM 6.1 come with the required ddi.dll file?
I think I'll quit my hunt for the dll file for the time being and look for more info on the official WM6.1, which is rumoured for release some time in the very near future...
I just want to share my tests
This test is made by Spb Benchmark
I don't think that there is a test like this high.
Who did these tests? and were they done on the current 6.0 release?
These are my test on my polaris wm 6.1 with the latest drivers from o2.
I can share this rom but there is a BIG problem camer is not working and video call too.
I made this rom.
if you've installed the rom can you tell us what version the ddi.dll is then please?
..and thank you for contributing to this thread
NikMel said:
These are my test on my polaris wm 6.1 with the latest drivers from o2.
I can share this rom but there is a BIG problem camer is not working and video call too.
I made this rom.
Click to expand...
Click to collapse
It doesn't really matter!! All we wanna do is TESTING! Please, share that ROM to see if it has some clues for us to carry out research on possible improvements
SuperJMN said:
It doesn't really matter!! All we wanna do is TESTING! Please, share that ROM to see if it has some clues for us to carry out research on possible improvements
Click to expand...
Click to collapse
hmm.. maybe you're right but the ultimate question about hardware acceleration like the kaiser lies with the version of the ddi.dll. But yes, if the benchmarks are that good its worth testing it so please do share the rom with us, who knows, with different radios the video calling and problems may get fixed and will only help to improve the rom.
I made this test after installation of keiser video fix from htc....org
Uploading.....
*** PLEASE READ CAREFULLY BEFORE INSTALLING OR FLASHING ANY SOFTWARE POSTED IN THIS THREAD ***
The software posted here is for TESTING purposes only, Team P3D or any of the posters of software, or links to software on this thread take absolutely no responsibility or liability for damage caused by the result of installing or flashing software or links to software found on this thread - correctly or otherwise, you do so on the sole understanding that you do so at your own risk.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Project Name: Polaris 2D Driver Project
Driver Name: P3D 2D Driver (Working title)
Development and Testing Team: SEE Post #2
---------------------------------------------------------------------------------------------------------------------------------------------------------------
ANNOUNCEMENT:
The P3D team would like to extend an OPEN INVITATION to all developers and programmers from all forums of EVERY device to come forward and help us create the 2D driver which, as it is being developed from scratch will require much development work with many dll files created from scratch.
If you are interested in helping, please post your interest in this forum and we will add your name to the developers list. If you would like to help but own a different device to which the 3D driver is yet to be ported to, we would also like to hear from you and hopefully assist you with the knowledge we have gained in return for your efforts here. (actually we'll help you anyway but.. we do want your help! )
---------------------------------------------------------------------------------------------------------------------------------------------------------------
11/10 - BigKVak successfully dumped the G810 rom and work has started in analyzing its content
---------------------------------------------------------------------------------------------------------------------------------------------------------------
P3D 2D Driver Development Team:
Administration/Testing:
Support and Testing:
Bally3
NikMel
Neos2007
BigKvak
Imfloflo
Developers: (TBC)
Rogro82
NuShrike
Chainfire
Monkeyass
maqui01
It started with a few simple questions:
"Can the Polaris be hardware accelerated?"
"Why doesnt the CA Kaiser 3D driver work on the Polaris?"
That was a month ago..since then, thanks to the help and support of NikMel, NeoS2007, Rogro82 and NuShrike to name a few, we now have a working 3D driver which is currently in a version 1 state and with the release of the cab version through CA last night, we can now concentrate on improving speed and compatibility to make better use of the graphic chips capabilities.
My intention then was never to start a 2D driver or work on a 2D driver until I was satisfied no more could be done to improve it and a "final" release was in the cards, but through my own testing and various posts and conversations, I now find myself wondering whether the improvements with 3D is linked to the 2D driver?
From day 1, before we released the 3d driver and after, users have expressed faster speeds in 2d as well as 3d - though many have explained it to be a "placebo" effect, we naturally attributed this to the gpu sharing the workload with the cpu which makes sense in a common sense way - itje posted a humorous answer on his thread explaining this very thing as worth a read just to put a smile on your face, but on a serious note a question has to be asked - Does improvement on 3D really effect 2D and if that is the case, would a 2D driver help improve the 3D drivers perfornance?
So why start a 2D thread when the 3D driver still needs refining?
Well, apart from the question above, the overwhelming requests for 2D support on both Polaris and Kaiser forums (it should work on both in theory), we now have a dump of the long awaited Toshiba G810 rom to get us started- A BIG THANK YOU TO BIGKVAK - welcome to the team!
Originally Posted by BigKvak
I have dumped ROM from Toshiba, here the link http://rapidshare.com/files/152085600/dump.rar.html
Click to expand...
Click to collapse
It is inevitable then that work needs to start on this project. We also need to preserve the 3D thread for future 3D driver developments and defer 2D driver related posts from it, for these reasons, this new thread has been opened for all to start working with the P3D team in bringing 2D greatness to our devices.
Lets share our knowledge and have fun doing it like we did with the 3D driver!
PS: Although I have named the project Polaris 3D driver project, I would like to extend an invitation to users of all devices that could benefit from the 2D drivers creation, after all through CA Kaiser development, we have now ported the 3D driver to the Polaris AND the NIKE and hopefully to many more devices
Let our devices not make us divisive - whats is the point?
It is common knowledge that files from newer devices are used to help create the drivers we need for our devices - so why should we gloat and mock other less supported devices, should we not help them and share our knowledge and in the words of a good friend here "Pay it Forward?"
This is not the spirit of XDA Developers and it is certainly not the ethos of Team P3D - We have and pledge tol share all knowledge with users of all devices.
Besides, its so much more fun when we all work together!
It appears that HTC-CA were already in the process of
Reserved for p3d 4
Reserved for p3d 5
Reserved for p3d 6
Reserved for p3d 7
Reserved for p3d 8
Reserved for p3d 9
Reserved for p3d 10
I found this link on microsoft MSDN: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1214862&SiteID=1
It's a guy asking for a 2d driver library. Maybe we can look into that?
I have dumped ROM from Toshiba, here the link http://rapidshare.com/files/152085600/dump.rar.html
Click to expand...
Click to collapse
To move the discussion of 2d in here..
Windows Mobile 2D and 3D explained on MSDN
I believe this: http://msdn.microsoft.com/en-us/library/aa911096.aspx will be out first place to look. It's mostly there: 2D AND 3D info.
Here's what functions there are:
AlphaBlend API
Provides information about adding support for the AlphaBlend function to your OS design.
Direct3D Mobile
Provide information about adding 3-D graphics support to your OS design and creating applications that use the API.
DirectDraw
Provide information about adding 2-D graphics support to your OS design and creating applications that use the API.
Gradient Fill Support
Provides information about adding support for the GradientFill function to your OS design.
Imaging
Provide information about adding support for compressed still images to your OS design and reference information for the API.
Multiple Screens
Provide information about adding support for multiple displays to your OS design and creating applications to support them.
NeoS2007 said:
I believe this: http://msdn.microsoft.com/en-us/library/aa911096.aspx will be out first place to look. It's mostly there: 2D AND 3D info.
Click to expand...
Click to collapse
reading it now.. some of it we know.. let see what we can learn..
http://msdn.microsoft.com/en-us/library/aa925824.aspx
Here we go:
"Applications direct output to a specified device by creating a device context for the device. The device context is a GDI-managed structure containing information about the device. An application creates a device context by calling device context functions. GDI returns a device context handle used to identify the device.
Applications can direct output to a physical device, such as a display or printer, or to a logical device, such as a memory device.
A device context also contains attributes that determine how GDI functions interact with a device. These attributes eliminate the need to specify every piece of information Windows Embedded CE requires to display an object on a device. If you want to change an attribute, you can use attribute functions to change current device settings and operating modes. Operating modes include text and background colors and the mixing mode that specifies how colors in a pen or brush combine with colors already on a display surface."
GDI is the source of 2D on our devices. Maybe we need to look out for GDI tweaks in the registry?
BPP (Bits Per Pixel) explained
I also found this blog about the colors used on a mobile device. It's said that if you have a colordepth of 18 instead of the usual 8, 16, 32 bits, it's more cpu intensive. Isn't there a registry key for colordepth?
http://blogs.msdn.com/windowsmobile/archive/2005/09/07/462187.aspx
"The next thing to understand is how the bits turn into colors on the screen. Say you've got a typical PocketPC with a resolution of 240x320 and 65536 colors. That means you've got 320 rows of 240 pixels (dots), each of which has 16 bits of data representing its color. All of that information is stored in a chunk of memory known as the "Frame Buffer." The LCD hardware takes whatever is in the Frame Buffer and converts it directly to what's on the screen. Want to change what's on the screen? Change what's in the Frame Buffer and the screen will update.
Okay, so we need 16 bits for every pixel, and we've got 240 times 320 dots. 16 bits is two bytes, so that's a total of 153600 bytes, or 150K of RAM used to hold what's on the screen."
Maybe a good thing to mention: we're hoping that the Toshiba g810 Portege has the files we need to develop a 2D driver. We're currently trying to extract a dump we got. Anyone have experience in extracting Toshiba's .Bin files?
Direct Draw explained
On MSDN:
"The DirectDraw® API provides support for hardware-accelerated 2-D graphics. It offers fast access to display hardware while retaining compatibility with the Windows graphics device interface (GDI). DirectDraw is a specialized memory manager for both system and display device memory and uses hardware acceleration where available. With DirectDraw, you can allocate and manipulate both system and graphics memory, including transfers between the two.
DirectDraw for Windows Embedded CE is adapted from DirectDraw for Windows-based desktop operating systems. Some capabilities from the desktop version have been extended and others have been curtailed to better suit embedded devices.
DirectDraw supports the following effects:
Bit-block transfers (blits)
Page flipping and multiple back buffers
Overlays, which is placing one image surface over another on the video display
Alpha source over destination blending, which is blending two surfaces using the source alpha image component
Video YUV pixel formats and color conversion
Direct video access to the frame buffer
What if we compare our HKLM\system\DDRAW\ keys in the registry with other devices? I see the values in ALL keys there are empty.
Yes.. I've noticed that and played around with them.. no difference.
I've tried the LG KS520, Diamond and HD ddraw.dll files.. none work out of the box. Maybe the G810 one might make a difference?
We need to find out what calls are made and to what other dll files. If you remember the problem we had with the 3.13 ddi? it could be similar situation in that theirs a dependencies issue.
How is Android actually ported to work on the Vogue?
Are you guys literally taking the source code, changing things, compiling & releasing it?
How have you guys learned how to do it?
I'm really interested in helping out and would like to learn more, so any info is great!
Still interested. If any developers could chime in I'd really appreciate it.
Even if you just post a link to some resources I could read.
I googled...I found..
http://www.kandroid.org/android_pdk/index.html
It may be old IDK....Have fun
Thanks!
If anyone has anything else.. please post!
http://cs-alb-pc3.massey.ac.nz/vogue/
^A bit of info about how the project came to be and progressed
Thank you for the reply!
So, when it comes to myn and plemen releasing their builds, what exactly are they doing? Are they getting the source code from Google and completely customizing it, or are they customizing a source that has already been ported for the Vogue? Or... what?
To summarize:
The brunt of the porting effort is in the kernel (the heart of Linux) - a kernel which supports the Vogue hardware needed to be constructed, and the Android-specific extensions added and made to support the hardware. Martin (dzo) did most of the work on that.
Then, there are some core user-space libraries in Android which interface with the hardware and kernel (audio and radio being the big two, with lights, GPS, camera, etc. following). These also needed to be created and updated to support the Vogue hardware. Each time a new Android version comes out, these libraries tend to change and parts need to be rewritten to keep up with Android. A lot of people were and are instrumental in this process.
Then comes the questions you're asking, the "userland" pieces of the build: porters can start from an AOSP (Android Open Source Project) build, which is built ground-up from the released Android sources, a build from another phone (Tattoo, Hero, Droid, etc.), or an SDK emulator build (which is usually not preferred because SDK builds have extra debugging and are missing features for real hardware). To "port" a build, the Vogue libraries are copied in and init scripts and build properties are updated to support the Vogue's screen resolution and hardware initialization. Some porters go an extra mile and unpack, modify, and repack application data to support 320x240 better or to add new themes. For the most part, this is what people like myn and plemen do.
Builds can also be "zipaligned" (package files are aligned to match cache and block boundaries, so they're loaded faster), and image files downsized or removed to enhance speed.
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?
I have with experience in VLSI, shell scripting (bash, windows powershell) and basic programming languages like C and Python (Matlab too, which uses a similar syntax).
I want to get into app development but I am completely new to this and unfamiliar with the whole structure - the IO libraries, rendering libraries especially. I mainly like to develop it for Windows 11 (but would be nice if I could make it cross platform, say using something like Vulkan as rendering library).
I wish to make a stylus based note making app (similar to one note, drawboard pdf etc). I wish to know about the libraries available for taking input from surface pen (or other pens). I found that there are a few API available for windows - RealtimeStylus, Windows Ink, etc but I am unable to find anything cross platform. I would like to know if there are open source, or cross platform alternatives. Alternately, I would like to know if it is possible to bypass these and create a custom API myself (including my own algorithms for tracing curves and predicting handwriting etc, at present I am left to use whatever was done in these APIs I think), also possibly making it lower latency within the app. To some extent I realized that pen position is very similar to trackpad input (on the data input to pc side) and then we have tilt and pressure sensitivity data which I'm not sure how it is accessed and used. I remember reading a little about libsdl sometime ago. I would like to know if there are alternatives to libsdl, or if Vulkan supports any alternate libraries.
I would like to know how I could code a program that works on both x64 and aarch64 on windows 11 (Not into 32 bit as I belive my tool will use more than 4GB RAM anyway, as a priority), and as mentioned above, it would be fantastic if I could make it cross platform. What I got from this page is that ( https://docs.microsoft.com/en-us/windows/arm/ ) if I write my program in C++ it should be possible to compile it for both x64 and aarch64 (and make possible optimizations for each of them separately). I am not sure how the whole development environment works - what is dotnet, what is unity, what is xamarin, and differences between each. I found a few code macros in dotnet that help in rejecting certain inputs (could be useful for palm rejection etc) : ( https://docs.microsoft.com/en-us/do...s.uielement.isinputmethodenabled?view=net-5.0 ) (https://docs.microsoft.com/en-us/dotnet/api/system.windows.uielement.ishittestvisible?view=net-5.0 ). As far as I am aware dotnet is cross platform. I might want to make instruction level optimizations to the software (like SSE, AVX, certain 64 bit instructions etc if that gives any hint) and would like to know if the dotnet environment/toolkit has sufficient low level coding possibility to access these. Also, I am curious if it supports vulkan or opengl. Vulkan is written in C++ and supports multiple platforms so I am more inclined to try it.