I've been looking for an explanation why the 320x320 resolution on these devices could not be enabled. Is there an insufficient RAM allocation? Does this device have VRAM? The 800W can do the higher resolution so where is the difference? If there is a better place to ask this then please redirect me and/or move this post.
I thought it had to do with the LCD screen, there are only so many pixels in the X and Y axis on the screen. All LCD screens have a native resolution. That is the highest resolution you can achieve with the screen. Anything higher than the native resolution will just zoom in.
Like on LCD flat screen tv, a 720p LCD tv converts the 1080p signal before it is displayed.
The screen only has 240x240 physical resolution. It's a hardware limitation, not software.
Yuxi
I don't think it's the LCD. I've seen techs put a 700W LCD on a broken 700P when doing repair so if it is a hardware problem, it ain't the LCD. Anyone else with a more authoritative reply?
Techincally, you can get 6.5 to run on a 240x240 device. The problem with the 700wx is the display driver. NightRaven and I have both made MANY attempts to get 6.5 to run on this device, but the video driver fails to initalize during gwes.exe initialization, therefor gwes.exe hangs and the boot stops. The last gwes.exe that will initialize the display was from build 207xx something. Unfortunately, 6.5 will not boot with such an old gwes.exe due to the many changes in it since.
We were able to get past that using a dummy ddi.dll driver, but of course no video. We were looking at attempting to recompile another driver for the 700wx device but haven't done it yet.
joojoobee666
Noted. Everything I have read assumes the LCD hardware resolution is 240x240 but I have seen a tech replace a 700P LCD from a broken 700WX which leads me to believe they are the same 320x320 LCD.
gmaslin said:
joojoobee666
Noted. Everything I have read assumes the LCD hardware resolution is 240x240 but I have seen a tech replace a 700P LCD from a broken 700WX which leads me to believe they are the same 320x320 LCD.
Click to expand...
Click to collapse
I believe you are correct on that assumption. NightRaven believes that it was a driver limitation forcing it to 240x240 due to it being a WM5.0 device initially, which did not have 320x320 support. One of the things we are going to try when we get around to compiling a new driver is testing 320x320.
joojoobee666
It's nice to get replies that reflect contemplation. I can't tell you how many forums insist the LCD is 240x240. I have conjectured that there may be a ROM call which sets memory allocation only sufficient for 240x240 operation. As far as I know, there is no VRAM or frame buffer RAM on the 700WX. If there is then the issue becomes considerably more complicated but if we can find the all the calls related to RAM allocated for display purposes, we should be able to unravel the mystery behind the video driver failure.
The displays on the 750, 700w(x) and the 700p are the same part numbers, so they would be the same resolution. Which is why I suspected the 700wx could support 320x320 with the right driver.
Once we get the necessary files for the pxa27x display driver sample, we should be able to create a new driver. We will attempt to create both 320x320 and 240x240 driver.
NightRaven
Awesome! I really appreciate the corroboration. Do you know if the WX uses VRAM or allocates system memory for its display? Is there anyway I can help? Do you know if Palm licensed Apple Quickdraw for the display engine? That might explain why writing a new driver is such a p.i.t.a.
NightRaven
Any news? I'll be checking in on this thread every month or so.
yeah this is a very interesting thread...
keeping an eye on it as well..
would love to up the res on my treo
Related
I'm quite pissed.
Before Windows Mobile 2005, HTC did not make their camera API public, so developers could not make use of the camera.
This all changed with WM2005 and the introduction of DirectShow. For devices released in the first year (since release of WM2005), this meant that one could "simply" use DirectShow to access the cameras.
But then HTC fell back to old habits again:
The HTC TyTN (Hermes) reports only a single video mode via DirectShow: 160x120 at 7.5 fps, which is a joke. Furthermore, trying to access the front camera via DirectShow fails too: It is simply not exposed (enumerated) at all.
The HTC Mteor (Breeze) goes even one step furher: It does report 160x120 and 320x240 (both at 15 fps), but actually both modes deliver pictures at 160x120. For the 320x240 mode, everything seems to work fine: IMediaSample tells that the picture is in that resolution. The memory buffer has the correct size (320x240x12bits), but the image in the buffer is really just 160x120.
Of course I tried several ROM versions (HTC, i-mate, etc.) but no chance.
So, I'm quite pissed. I already tried calling HTC but didn't get very far (which makes sense if these restrictions are on purpose...)
Daniel
No comments on this?
Nobody every using DirectShow?
I guess I also wouldn't do it if I wasn't force to...
Daniel
So with simple words if you want to use WM5 camera api in your application you can not do it in any HTC device
So how did the makers of CoolCamera go about? I was kinda under the impression that it used wm5s camera api, or am I wrong?
I think they've rewritten the interface from scratch. Look into the CPU developers' manuals. Not a small endevour!
V
CPU Developers' manual
Hi Vijay555,
Would you be so kind to post a link to where I can get this manual ?
Thanks in advance!
I don't think anyone wrote anything from scratch nor do I think this has much to do with a CPU manual... the devs at CoolCamera may have *somehow* managed to get their hands on the infamous HTC TyTN camera api... what exactly are you referring to when you mention the CPU manual?
Also, has anyone ever found a location where this api may be available or a means to get it? HTC developer support is non existant.
Eric, what makes you so sure that they didn't write it from scratch? Maybe they did acquire illegally or otherwise HTC's intellectual property, or maybe they just did what other manfacturers do and wrote some code.
Look at the device support - it's not a single device, it's many, across many different CPUs (Intel, Omap, Samsung), across many different camera sensors and support chips. However, implementation of a camera at software level is not impossible: how else do companies sell their sensors and chipsets?
http://www.ovt.com
Ask the sensor manufacturer, they'll give you chips specs, schematics, implementation code and draft driver code.
Then, look up the SC32442A developers' manual and you'll see that it encompasses a camera interface, again with necessary schematics and hardware IO information.
Sure it's hard to write a camera interface, but once you've written one, it gets easier to support others.
V
they need to continue writing then because my camera application frequently fails in that pictures are corrupt, can't be viewed, and the picture review is just black
Sure it's hard to write a camera interface, but once you've written one, it gets easier to support others.
V
Click to expand...
Click to collapse
What kind of effort are we talking about here? Days? Weeks? Do you think this would need to run in kernel space, or we could get away with user space?
Hi, please tell me if there is a way to make the message boxes and windows (of course some of them are outside the screen area) to force to display in screen area, not to have a part of window outside screen.
The display driver is ddi.dll.
Thanks for your help.
Unless its your windows (from your own app) no.
ddi.dll is the generic name for WM / CE display driver so it tells us nothing of the device.
If you describe your problem in more details, like the exact device, the apps that do not display properly etc. perhaps someone will be able to help.
Ok, the device is a pna running win core 5.0. Apps. that are outside are using gdi (apps which use gx are displayed normally thanks to gapi 4.0), but the others designed for 230x320 are outside (the device has display 320x240).
Ok, I think I understand what you are trying to do - you "opened" a PND and are trying to run PPC apps on it right?
Unfortunately, currently there is no way to help apps that can not adjust to screen resolution by themselves.
PNDs are intentionally limited in features and screen rotation option was removed from the driver.
Unless a program was written to take in to account the screen size (many PPC programs were not) there is no way to force it to the right resolution.
And even if it could be done (there is a theoretical way) it will always be buggy and unstable.
First of all, I am not a developer. But I am trying to figure how this possibly trivial problem is resolved.
In many shipped Android tablets today, the landscape view is wrongly defined within Android as the portrait view, resulting in issues with many fullscreen applications.
For example, on a 800x480 screen:
800x480 is treated as portrait
480x800 is treated as landscape
When an activity is defined with android:screenOrientation="landscape" under Androidmanifest, this results in the breaking of certain apps due to layout issues of the app expecting landscape to be 800x480 when the screen only has 480x800 available.
This is apparently not an issue on certain tablets, such as the Archos 7 Home Tablet. I have not figured out how to solve this.
I believe this should be defined somewhere in the Android framework, but before I look through the hundreds of files there with my limited expertise, I thought I would be able to ask someone here.
Where would I try to change this? If someone knows the exact file or files, please advise.
My target Android tablet is a Rockchip RK2808a platform running Android 1.5, which already has issues running a 800x480 as it is. I am not sure if this affects more Android tablets, but I have seen this issue in at least the typical Telechips TCC8902 configuration as well as the OMAP 3530 configuration on 800x480 screens, on Android 2.1.
After this change, I am aware that the rotation definitions may have to be modified under PhoneViewManager and WindowOrientationListener to redefine the rotation behavior.
Hi!
After searching the forum, it comes up with no info on what i need to know.
HTC touch diamond have resources like GSM, GPS, G-Sensor, 528 MHz Clock and a big block of RAM.
Microcontrollers have resources like, 2 to 4 8-Bit, input, output registers,using which, i can nearly make any control device. but they are difficult to be interfaced with LCD displays, GPS IC's etc.
What exactly i;m trying to do is, give and take orders between these two devices. I can't buy another windows phone because that will cease my project budgets
So, please tell me a way to make Diamond, a serial port equipped device, Not all the pins of port are necessary, like in PC, just RxByte, TxByte and gnd are importent.
I've read about bluetooth Serial adapters, but em not sure, they will do the job for me.
What i'm trying to do is, communicate b/w an HTC touch Diamond and microcontroller, like, ATMEGA16. The only medium of transfer is RS232 protocol, USART. But, i don't know whether diamond can do so or not. I can write codes in C# for my diamond and on the other hand, have a good skill on Microcontroller programing.
So, both cities at the sides of river are ready to be populated, just their llinking bridge is missing.
Help me, please !
So I have the unfortiounet task of fixing a tablet for a co-worker. The co-worker origionally gave the tablet to another co-worker who, unknowingly at the time, flashed firmware for the previous generation device. To make a long story short, it boots ok, Screen sensors sound wireless etc works EXCEPT the touchscreen.
I do not think that the drivers that were with the rom he installed were correct (go figure, newer device ... larger screen etc.)
So my first question How would I go about determining the touchscreen hardware without cracking open the case?
I know in a *nix environment you can use lspci or lsusb to get some basic information about the hardware on the usb or pci busses but I dont think that archetecture exists here, I may be wrong.
Ultimatly If an existing driver cannot be found I am facing writing a driver for the hardware at hand.
Thanks in advance for advice/help.
Anyone?
Identifying touch screen controllers
I'm having trouble finding drivers too. Starting with touch screen manufacturer.
This looks promising.
w w w. touch-base. com
/documentation/ identifying%20touch%20screen%20controllers. htm
(sorry for the screwed up link. the site doesn't allow new posters to post outside links.)
If you find a good source for drivers let me know.
Thanks,
The frustrating part is NEC has a dedicated product page but they have no drivers and only the manual for the non-touch version of the monitor.
NEC AccuSync LCD51-BK-TR (i.e. ASLCD51-BK-TR) 15" LCD touch screen monitor.