I have been scouring through the different Kaiser,Polaris and Diamond threads that concern driver issues that we would all want solved. What i have found is that all 3 of these phones use similar driver .dlls and if HTC drops a driver for one of those 3 phones....will somebody be able to render the drivers to work for the other 2 phones that the driver didnt come out for? Like if the diamonds drivers are droped, will Polaris and Kaiser individuals be able to use the same driver to help there video playback? Seems highly unlikely for HTC to drop individual drivers for all 3 top level HTC phones but maybe a universal QUalcomm MS7200 chipset driver for these phones would come out. If not, would somebody be able to make a Polaris driver work for the Diamond or Kaiser? the phones may have different .dlls or D3D or Open GL registrys if its a MS7500 or even similar MS7200 chipset. If you guys havent seen this postt check it out plz
http://forum.xda-developers.com/show...postcount=1004
Hey everyone,
I had a question oncerning the Kaiser's video drivers. I know there are numerous drivers floating around that have been working great. I was curious if PDA phone operate like computers when it comes to having differennt drivers for the monitor and the video card or are they basicaly all wrapped into one driver. I was curious if any portion of these drivers controls the refresh rates of the screen for the kaiser device. Hopefully this question makes sense.
Thread moved. Not related to ROM development.
Thanks
Dave
As far as I know, the attempts at making OpenGL ES drivers for the TyTN II have been discontinued. But why did the developers decide to abandon the project?
Did the developers of the drivers ever release the source of their work for any other developers to pick up and continue where the first developers left off?
Has it ever been confirmed that the hardware actually does/doesn't exist and is/isn't wired in such a way that a driver can be used to add OpenGL ES support? I mean, even if the chip exists and is accessible by the OS, it doesn't have to mean that the chip is connected to the display of the device in such a way that you can utilize its features.
If so, it's be pretty much like having a computer with a powerful video card, but without the monitor connected to the card.. Instead the monitor is connected to a poor performance card in the same computer, making it possible to use the powerful card to generate "screenshots" which are then simply displayed through the poor performance card, but still without achieving the same performance as you would if the monitor had been connected directly to the powerful video card.
Can someone update me a bit on the progress, or perhaps direct me to the right place to read more? I used to closely watch the htcclassaction.org website, but now that website seems to be dead, without any info about why the development just stopped.
I know that this device is getting old and pretty much belongs to the history books now, but now that android is being ported for the TyTN II, the device may have a new chance of seeing daylight again. Perhaps someone is willing to take a look at the driver issue again and make some TyTN II video driver for android? I certainly hope that the development didn't stop because it was simply impossible to make a driver. After all, you cannot write a driver for hardware that doesn't exist.
Thanks.
yeah, up for this, and is there any driver that will install on the default wm 6.1? thanks for the upcoming reply people
I don't think it's a matter of history yet. The newer devices that have physical keyboards have the same chipset and, therefore, same performance issues they TyTN II has. That extra 124mhz the Touch Pro/2 have aren't doing much to remedy the problem.
Excuse me, what's the currently true problem ?
Some OpenGL ES applications don't runs ? ( an example ? ) or they runs too slowly ? ( an example ? ).
In my "beta" configuration everything seems to work decently.
Regards,
Stefano G.
I think some people were working on it most recently under the development and hacking thread...search Neos2007 open vg drivers...They managed to get some accelleration in much newer msm7201A devices with the ati d3d drivers but when I tried it on my tilt it had a device exception error when I ran some d3d samples...What worked for me for now was:
1. Disable manila/chome
then
2. intall Gfxboost 1.1 by chainfire
then
3. install neos2007 driverpack 2A
then
4. install HTC-CA drivers
By following the procedure above I was able to actually run the program GL benchmark and most of the d3d samples (except text) but somehow some d3d samples break the drivers too...
I have tried some Kaiser " SuperRam - 101/102 MB " roms,
nobody was completely compatible with HTC-CA drivers.
With my rom ( no SuperRAm ) I obtain the best result replacing
the DLL "ahi2dati.dll" with a renamed copy of "ahi2dati_dm.dll".
Regards.
We already have a ROOT, so maybe think about the new video drivers for WF? current drivers cause errors in texture and are terribly slow.
I tried to move the drivers from other devices, but they caused the system to stop the HTC logo. Unfortunately, Android is not my forte.
Devices with the same processor at the WM, cope better with 3d graphics.It seems that this is only the problem of 3D drivers.
Broadcom announced the release of the raspberry pi's gpu source. Heres what a user on arstechnica had to say about the release; it is most likely whats going to happen in our device and the reason why it will probably never be overclockable unless broadcom alows it to:
Unforunately it's not really open source at all. I'm not too familiar with Broadcom's SoC, but it seems like the bulk of the driver is running on a side processor. The open sourced code simply passes commands and data back and forth between the user's code and the real driver doing the work. Now, a lot of hardware uses firmware these days, so it's tempting to think of what's running on the side processor as firmware, but when the driver running on the main CPU is just an RPC layer and most of the magic (including things like the shader compiler) is happening on the side processor then I would think that any person familiar with the hadware/software interface would rightly say that the "driver" is really the code on the side processor and not the open source code.
Now, having the CPU layer as open source is better than not having it, but this is nowhere near an open source GPU driver. TI does the same sort of thing with their DSP and some auxiliary processors on their OMAP chips, most of the "driver" is running on another processor.