I need to be able to control brightness of my Windows CE 5.0 device.
I've found that there is an API function ExtEscape to do that ( http://msdn.microsoft.com/en-us/library/aa453063 ) but it needs a structure ContrastCmdInputParm (http://msdn.microsoft.com/en-us/library/Aa447689 ) as a parameter.
Since ExtEscape is unmanaged, I cannot pass a .net structure.
What is the simplest way to call this function?
Before you go down this road, contact your OEM to see if they have an API for controlling backlight intensity. In my experience no one implements it via ExtEscape (I've not seen it even once). Generally if backlight adjustment is supported at all (sometimes it's not physiclaly possible on a device, sometimes it's not implemented by the OEM), then it has a proprietary API for adjusting it.
So again, contact your device OEM before going any further to avoid wasting your own time.
Related
I've got a big ask here, but I am hoping someone might be able to help me. If there's another site you think this should be posted on, please let me know.
I'm the developer of the free app Amphetamine for macOS and I'm hoping to add a new feature to the app - keeping a Mac awake while in closed-display (clamshell) mode while not having a keyboard/mouse/power adapter/display connected to the Mac. I get requests to add this feature on an almost daily basis.
I've been working on a solution (and it's mostly ready) which uses a non-App Store helper app that must be download and installed separately. I could still go with that solution, but I want to explore one more option before pushing the separate app solution out to the world.
An Amphetamine user tipped me off that another app, AntiSleep can keep a Mac awake while in closed-display mode, while not meeting Apple's requirements. I've tested this claim, and it's true. After doing a bit of digging into how AntiSleep might be accomplishing this, I've come up with 2 possible theories so far (though there may be more to it):
In addition to the standard power assertion types, it looks like AntiSleep is using (a) private framework(s) to apply non-standard power assertions. The following non-standard power assertion types are active when AntiSleep is keeping a Mac awake: DenySystemSleep, UserIsActive, RequiresDisplayAudio, & InternalPreventDisplaySleep. I haven't been able to find much information on these power assertion types beyond what appears in IOPMLibPrivate.h. I'm not familiar at all with using private frameworks, but I assume I could theoretically add the IOPMLibPrivate header file to a project and then create these power assertion types. I understand that would likely result in an App Store review rejection for Amphetamine, of course. What about non-App Store apps? Would Apple notarize an app using this? Beyond that, could someone help me confirm that the only way to apply these non-standard power assertions is to use a private framework?
I suspect that AntiSleep may also be creating a virtual keyboard and mouse. Certainly, the idea of creating a virtual keyboard and mouse to get around Apple's requirement of having a keyboard and mouse connected to the Mac when using closed-display mode is an intriguing idea. After doing some searching, I found foohid. However, I ran into all kinds of errors trying to add and use the foohid files in a test project. Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app? I'm not asking for code help with that (yet). I'd just like some help determining whether it might be possible to do.
Thank you in advance for taking a look.
Would Apple notarize an app using this?
I haven't seen any issues with notarising code that uses private APIs. Currently, Apple only seems to use notarisation for scanning for inclusion of known malware.
Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app?
Taking a quick glance at the code of that project, it's clear it implements a kernel extension (kext). Those are not allowed on the App Store.
However, since macOS 10.15 Catalina, there's a new way to write HID drivers, using DriverKit. The idea is that the APIs are very similar to the kernel APIs, although I suspect it'll be a rewrite of the kext as a DriverKit driver, rather than a simple port.
DriverKit drivers are permitted to be included in App Store apps.
I don't know if a DriverKit based HID driver will solve your specific power management issue.
If you go with a DriverKit solution, this will only work on 10.15+.
I suspect that AntiSleep may also be creating a virtual keyboard and mouse.
I haven't looked at AntiSleep, but I do know that in addition to writing an outright HID driver, it's possible to generate HID events using user space APIs such as IOHIDPostEvent(). I don't know if those are allowed on the App Store, but as far as I'm aware, IOKitLib is generally fine.
It's possible you might be able to implement your virtual input device using those.
I need to run a local application on a windows CE 6.0 platform I am doing some work on.
Basically, ALL I need to do is run a command line application with a few arguments. I don't really even need to see the return value.
Basically, I have a little closed-source CE program which interacts with some specialized hardware, and I'm trying to control said hardware from within the software I am working on. Once I have everything set up, I am interacting with the hardware through it's API, but there are a few configuration settings which the API neglects to expose, and I need to alter to make everything work correctly (I'm working on getting the manufacturer to fix the API, but I need a working prototype soon).
Everything I have read says the system() call is what I need, but it does not seem to be present in Windows CE's stdlib.h.
ShellExecuteEx seems to be available, as does CreateProcess, if ShellExecuteEx isn't sufficient (and it should be), CreateProcess definitely will be, if a bit more work.
OK, this is basically just about any non-default OS API running on all different OS. But for my example let´s consider platform Windows, API SDL (Simple DirectMedia Layer).
Actually this question came to my mind when I was reading about SDL. Originally, I thought that on Windows (and basically any other OS) you must use OS API to make certain actions, like writing to screen, creating window and so on, because that API knows what kernel calls and system subroutines calls it has to do. But when I read about SDL, I surprised me, because, you cannot make computer to do anything more than OS can, since you cannot access HW directly, only thru OS API, from Console allocation to DirectX.
So, my question actually is, how does this not-default-OS APIs work? Do they use (wrap) original system API (like MFC wraps win32 api)? Or, do they actually have direct access to Windows kernel? Or is there any third, way in between?
Indeed, SDL is a wrapper for OS-specific calls, although with many simplifications and convenience functions. On Windows, SDL uses DirectX.
I have the following requirements:
I need a api that works on CE (x86) + .NET Compact Framework to play videos (Similar to CorePlayer API... Just free)?
Is their anything else available or must I use CorePlayer?
You could use the MediaPlayer with COM interop. Have a look at this and this.
Also, Media Player may not be installed in your device.
You need to use DShow and have the codecs for whatever media you intend to play in the image. COM interop for WMP 9.0 (which is what ships up through at least CE 5.0, maybe also in 6.0) is a non-starter for managed code.
If you don't know DShow, it's a fair amount of work - even in native code - as DShow is not a fun or friendly API set.
The plus side is that you don't need WMP at all in the image, so you can typically use a Core CE license (Pro is required to use WMP). I know of a commercial DShow control, but you said you're looking for a free solution and I'm not aware of anything other than rolling your own. Depending on your level of familiarity with COM interop (which you'll need for the DShow stuff) and the use of DShow and filtergraphs, I'd allocate at least a week or two to getting this working.
One added note - the complexity also changes depending on how you want the video displayed. If it's just full-screen then it's a bit less work than getting it inside a Window within your app. Not a lot less, but at least a little.
DirectShow?
Check out this page for a starting point.
Provided that DirectShow is present on your CE, which I don't know...
EDIT: Since you can use DirectShow, I'd like to add a bit.
As ctacke notes, it can be a lot of work if you do everything manually, but it's pretty straightforward if you can use IGraphBuilder (see the sample I linked above).
I don't know much about DirectShow versions, but the one included with Windows Mobile 6.0 lacks a splitter for MPEG audio. It means, e.g., that out of the box it won't play .mp3 files unless you wrap them in RIFF headers.
I bet you can convert some of DirectShow.Net to run on CE if you are looking for a C# solution.
I'm writing a program that needs to take input from an XBox 360 controller. The input will then be sent wirelessly to an RC Helicopter that I am building.
So far, I've learned that this can be done using either the XInput library from DirectX, or the Input framework in XNA.
I'm wondering if there are any other options available. The scope of my program is rather small, and having to install a large gaming library like DirectX or XNA seems like excessive. Further, I'd like the program to be cross platform and not Microsoft specific.
Is there a simple lightweight way I can grab the controller input with something like Python?
Edit to answer some comments:
The copter will have 6 total propellers, arranged in 3 co-axial pairs. Basically, it will be very similar to this, only it will cost about $1,000 rather than $15,000. It will use an Arduino for onboard processing, and Zigbee for wireless control.
The 360 controller was selected because it is well designed. It is very ergonomic and has all of the control inputs needed. For those familiar with helicopter controls, the left joystick will control the collective, the right joystick with control the pitch and roll, and the analog triggers will control the yaw. The analog triggers are a big feature for the 360 controller. PS and most others do not have them.
I have a webpage for the project, but it is still pretty sparse. I do plan on documenting the whole design though, so eventually it will be interesting.
http://tricopter.googlecode.com
On a side note, would it kill Google to have a blog feature for googlecode projects?
I would like the 360 controller input program to run in both Linux and Windows if possible. Eventually though, I'd like to hook the controller directly to an embedded microcontroller board (such as Arduino) so that I don't have to go through a computer, but its not a high priority at the moment.
It is not all that difficult. As the earlier guy mentioned, you can use the SDL libraries to read the status of the xbox controller and then you can do whatever you'd like with it.
There is a SDL tutorial: http://sdl.beuc.net/sdl.wiki/Handling_Joysticks which is fairly useful.
Note that an Xbox controller has the following:
two joysticks:
left joystick is axis 0 & 1;
left trigger is axis 2;
right joystick is axis 3 & 4;
right trigger is axis 5
one hat (the D-pad)
11 SDL buttons
two of them are joystick center presses
two triggers (act as axis, see above)
The upcoming SDL v1.3 also will support force feedback (aka. haptic).
I assume, since this thread is several years old, you have already done something, so this post is primarily to inform future visitors.
PyGame can read joysticks, which is what the X360 controller shows up as on a PC.
Well, if you really don't want to add a dependency on DirectX, you can use the old Windows Joystick API -- Windows Multimedia -> Joystick Reference in the platform SDK.
The standard free cross plaform game library is Simple DirectMedia Layer, originally written to port Windows games to Unix (Linux) systems. It's a very basic, lightweight API that tends to support the minimal subset of features on each system, and it has bindings for most major languages. It has very basic joystick and gamepad support (no force feedback, for example) but it might be sufficient for your needs.
Perhaps the Mono.Xna library has added GamePad support, which would provide the cross platform functionality you were looking for:
http://code.google.com/p/monoxna/
As far as the concerns about the library being too heavy weight, sure, for this option it may be true ... however, it could open up opportunities to do some nice visualization in the future.
disclaimer: I'm not familiar with the status of the mono xna project, so it may not have added this feature yet. But still, 'tis an option :-)