I have a touch screen device that is running on windows CE. after 30 second the screen goes off to save power and will come back on it you touch it.
The problem is that randomly when the screen goes off the device will not come back on simply by touching the screen. I have a done a bunch of tests and there is no noticeable pattern to when this happens.
It appears to be performing the same action as when you press the suspend button from the main menu.
I have done some research and found there are 4 power saving settings in the registry and I think I need to disable one to stop the device from "suspending". I never want the device to turn off except for the screen going off, it is always connected to power.
Does anyone know how I can do this or why it is randomly suspending ?
And the entire device is in Chinese So really precise instructions would be appreciated. My application runs on top of the CE.
I know you're after precise instructions, but it's not that simple. The device OEM defined and implemented the power management system for the device, Microsoft only provided the structure for it. The OEM could have implemented power management in any way they sought fit,, and in fact they could have completely ignore the Microsoft-provided framework (wouldn't be the first time an OEM did that). Really you need to get a hold of the OEM and ask them how to prevent the behavior you're seeing or to get something different.
Barring that, you could always play around with the registry entries, but again, there's no guarantee any of them will work. You might look at adjusting power state or the activity timer registry entries.
Playing with the power manager control panel applet might also help (it's probably labelled 电源管理)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\Timeouts]
"BattSuspend"=dword:0
Related
Do You know the situation when on screen in application you have not fully refreshed view? You need to hover the mouse on the object to make it visible/refreshed? Or You need to open close page/screen to refresh all objects?
I have PC-box with Win10. PC has only one DVI port, so extended the screens with USB to DVI adapter (3x VGA2725) and desktop is extended to 4 monitors. Each monitor is used to show the same software (SCADA) 4 different 'windows'. On the screens with adapters there is problem with view/screen refresh, like a 'artefacts' or part of screen not updated. In that situation the page needs to be closed/opened again. The CPU and disk is not overloaded.
Could You help me if above is more software issue or more hardware issue? Shell I look for bad drivers? What shall I check?
EDIT: sorry, missed the fact that the adaptor is multiplying the signal to all monitors.
Nevertheless, check with only one monitor at a time and different combinations to isolate is my suggestion.
PLEASE DISCARD THE FIRST ANSWER BELLOW..
Has the adaptor been tested on one of the other monitors?
If it has been tested on all monitors and the error is only on one
of them, checking that monitor's specs, and the adaptor's specs; to
see if there are any incompatibilities, is probably the best approach.
If no testing on a different monitor has been done, I would definitely
try to isolate the issue by connecting the adaptor to all external
monitors.
If you encounter the same error on a different monitor, we know it is
most likely the adaptor, or it's drivers.
I want to know if there is any way we can make either Windows or Linux machine shut down for let's say "N" minutes. and then it powers up automatically at the end of "N" minutes.
I know we can switch between OS using Grub from Linux and using third party software on Windows but never heard of such software or command to make it shut-down for certain time.
Check your BIOS, sometimes motherboards have a "boot at specific time" option in there if it's a regular thing
If you machine doesn't need to be fully off, then you could also hibernate. rtcwake is popular, allows disk-written low power hibernation and can be set to come back up automatically
Lastly if you need (or want, for energy reasons) it to be for reals off, and you don't have a timer boot option, most motherboards allow "Wake on LAN" or "Power by Eth" or something along those lines. Keeps enough power going to the network card to detect a broadcast packet with a wakeup signal matching your machine's
NIC's MAC address from the network, even when the computer has properly shutdown. This is my favourite method because it's true remote boot, but it means you need to have another device on the network.
There are readily available phone apps which can send a wake signal, I've only ever used manual ones but there's bound to be one on a timer. For linux I know there's ethtool and wakeonlan available, (haven't used either personally though.) Worst case scenario, there are several tutorials for baking your own, and the protocol isn't complex.
For Windows:
To my understanding you need to create a new task on the Windows Task Scheduler and let that task run after N minutes. The scheduler will program the BIOS' "power up on time" feature to the specified time. If the machine is powered (plugged in to wallsocket) and Windows is only in standby or hibernate mode (that is, not shut down), it should power up on the given time.
You might want to set the waking time about a minute early or so, since booting takes time as well. Also make sure energy saving options are not set too strict like "go to standby after X minuted of idle time" and this is in the middle of the unattended task execution ;)
I used this a lot when programming my PC to record from my TV card on a specific date and time and it worked well. DVBViewer handled all of the task creating stuff. I never set them up manually. There surely are other tools to automate the task creation if needed.
The manual way is something like this:
Right click on the Windows Start Button, select "Computer Administration Console" (or similar, I don't know the correct english naming), then a window pops up where you can right click in the tree view on the left handside on the item "Task Scheduler" (again, naming may differ) and select "Create simple Task" or "New Task..." (more advanced options). Hope you can manage from there.
Should work on Windows 7 to 10. Maybe earlier versions as well, but you need to figure out how to get to the task creation wizard.
Hope this helps, good luck :)
My question is about the delay between calling the present method in DirectX9 and the update appearing on the screen.
On a Windows system, I have a window opened using DirectX9 and update it in a simple way (change the color of the entire window, then call the IDirect3DSwapChain9's present method). I call the swapchain's present method with the flag D3DPRESENT_DONOTWAIT during a vertical blank interval. There is only one buffer associated with the swapchain.
I also obtain an external measurement of when the CRT screen I use actually changes color through a photodiode connected to the center of the screen. I obtain this measurement with sub-millisecond accuracy and delay.
What I found was that the changes appear exactly in the third refresh after the call to present(). Thus, when I call present() at the end of the vertical blank, just before the screen refreshing, the change will appear on the screen exactly 2*screen_duration + 0.5*refresh_duration after the call to present().
My question is a general one:
in how far can I rely on this delay (changes appearing in the third refresh) being the same on different systems ...
... or does it vary with monitors (leaving aside the response times of LCD and LED monitors)
... or with graphics-cards
are there other factors influencing this delay
An additional question:
does anybody know a way of determining, within DirectX9, when a change appeared on the screen (without external measurements)
There's a lot of variables at play here, especially since DirectX 9 itself is legacy and is effectively emulated on modern versions of Windows.
You might want to read Accurately Profiling Direct3D API Calls (Direct3D 9), although that article doesn't directly address presentation.
On Windows Vista or later, once you call Present to flip the front and back buffers, it's passed off to the Desktop Windows Manager for composition and eventual display. There are a lot of factors at play here including GPU vendor, driver version, OS version, Windows settings, 3rd party driver 'value add' features, full-screen vs. windowed mode, etc.
In short: Your Mileage May Vary (YMMV) so don't expect your timings to generalize beyond your immediate setup.
If your application requires knowing exactly when present happens instead of just "best effort" as is more common, I recommend moving to DirectX9Ex, DirectX 11, or DirectX 12 and taking advantage of the DXGI frame statistics.
In case somebody stumbles upon this with a similar question: I found out the reason why my screen update appears exactly on the third refresh after calling present(). As it turns out, the Windows OS by default queues exactly 3 frames before presenting them, and so changes appear on the third refresh. As it stands, this can only be "fixed" by the application starting with Directx10 (and Directx9Ex); for Directx9 and earlier, one has to either use the graphics card driver or the Windows registry to reduce this queueing.
I've got a WinCE device powered over ethernet (PoE) and I want to prevent File-System corruption following a potential power loss, e.g. user pulling the plug.
As a side note, I'm already using TexFAT which is supposed to prevent FS corruptions. While the later certainly does help reducing FS corruptions (over using plain old FAT), it doesn't entirely prevent some to still occur from time to time... So, I'm considering using a small rechargeable backup battery that would give WinCE enough time to cleanly shut down. Now, I can't find any info on the shutdown process: how to trigger it, how long it takes, and so on... MSDN is pretty quiet on this topic. Any idea?
The powerdown sequence is totally platform dependent.
The following answer is relevant to Windows CE 6. It may be different for previous versions of CE.
If you include the power manager component in your system, then the sequence is plus minus this:
Send go to D4 to all the drivers that are powermanageable and that reported they support this state. Otherwise, the driver gets the lowest powerstate it supports.
XXX_PowerDown is called, but it is not commonly used in Windows CE 6.
In between the registry is flushed in case you have a Hive Based registry and you enabled the registry flush thread. You should disable this in a fragile system such as yours
OEMPowerOff
device down
Just found a post by Bruce Eitman on what happens when Suspending. He puts it better than I do.
The Suspend sequence is what you'd do before loosing power.
I want to be able to intercept (and do arbitrary processing on) auto-repeating key presses on Windows. I'd like to know how keyboard auto-repeat is implemented so that I know what options I have. i.e. can I intercept at the:
application,
device driver and/or
hardware level
?
Update: It looks like auto-repeat is (poorly?) generated at the hardware level and then overridden by device drivers (see here).
To modify or filter behavior, you can intercept keys using a hook:
SetWindowsHookEx using WH_KEYBOARD
The hook procedure receives, among others, the repeat count (due to holding down the key)
Note that the low level keyboard hook (WH_KEYBOARD_LL) does not receive the repeat count.
If all your windows are created in the same trhead, you can use a thread-specific hook, and avoid moving the hook procedure to a DLL.
I dimly remember that repeat counts are generated by the keyboard itself and the LL hook sends repeated keydown events - I may be mistaken, though. Under DOS, the key repeat rate and time that was set in BIOS or through a BIOS call did return to default values when a DIN or PS/2 keyboard was unplugged and replugged. I am not sure WHY you need to know exactly.
I suggest that you might want to edit your question... your actual question is "How to suppress auto-repeat on Windows in ${yourLangauge}"...
To which my response is, I haven't got a clue, I've only ever done it in assembler (MASM 80286)... and even then I found a solution on a BBS (does anyone remember them) and just used it. From memory, the intercept has to be done at the device-driver level.
The implementation of autorepeat ($100 says it's assembler) problably won't shed any light on supressing it... that and Microsoft plays those cards very close to it's chest.
Cheers. Keith.
EDIT: I've just thought... techniques may now differ between versions of windows and the plethora of various devices... Oh goodie!
Sounds likes this is "Not programming related", however.
Go to "Accessibility Options" in control panel.
Select "Settings" under "Filter Keys" group, in here, you can switch off repeating keys for that user on that machine.
Hope this is what your looking for.
P.S. Above instructions given for Windows XP.