How will you achieve screen syncing?
Idea is really cool, I'd be willing to try it myself, too.
I want to create an application for a windows mobile 5.0 and xp which will make the touchscreen of the handheld to function as a remote contol for SD thats in the car. It can be connected through wifi or bluetooth and will inherit the gesture interface. The whole idea is to be able to manipulate SD while chillin outside of the car or in the back seat...
Or maybe something like remote desktop, but with SD GUI open while keeping the user logged in the session and displaying the content on both screens. In other words extending the screen to a handheld.
HARDWARE: Fujitsu Stylistic ST5111w/WiFi and dock, internal Hitachi 500G HD, external 1TB HD, Sierra Wireless Aircard 550, DVD-RW, BoomzBox HD radio, XM Commander, Delorme GPS, Saitek X-52 Pro joystick, BluSoleil Bluetooth, TPMS, FB, Elm327
music on (for example... ) and I get tired of getting into the car everytime I want to change a track.
Cool idea, I think it will be very difficult to remote the StreetDeck UI to a phone since it uses Direct3D. You should be able to create an Overlay script in StreetDeck that can send functions to it and retrieve the current playing media or other info that then talks to your phone via a COM object and recreate a remote control interface on your phone using the retrieved information.
DIRECT3D over remote desktop doesn't work.
It's terribly slow, but I have run programs that use DirectDraw, Direct3D, and even OpenGL acceleration through VNC. Polling can still be used for those
programs until wrapper can be written for those interfaces. A GDI wrapper would catch 99% of all normal intended uses of VNC, and would be so much
faster than other approaches.
DirectX is COM based, which means you would have to register your own COM component with the same GUID. But if you did that, you would be unable to get to the original COM component. You *might* be able to wrap the 4 or 5 normal DLL entry points and do some pass through tricks, but I think it
will be much harder than doing so with straight DLLs. That's why I don't want to see effort that could be spent getting a working GDI wrapper spent on DirectX stuff. Get the biggest payoff with the least effort whenever possible, right?
Good idea.. I have a few PPC devices that have either Bt or wifi, i'll see what I can hookup also..
There is also an app (ill hunt for it today) which makes your PPC show as a secondary display.. Mabey as the SD multimonitor support takes shape, this could be used.. Mabey have an option to set a display as a "remote" and allow for gesture control...
Let me know if you find any software that does that, so it will work on both monitors at the same time that I can use on my 5.5" origami touchscreen running Win XP using wireless connection to EVDO/Wifi route that's also connected to carPC. I also remember that in Windows server 2003 you are aloud to display the remote session on the primary monitor.
Yeah with remote desktop connection the color depth has to be set to 32bit in order for it to work, which is hackable, but not default option in NT.
Sometimes changing it to another value gives you undefined behavior and usually causes a failure in the GDI system.
I would use VNC. RealVNC or TightVNC will work. Which one you use is a matter of preference. RDP is tied into the Windows graphics subsystem and operates at a much lower level. As a result, Direct3D will not work through it. VNC operates at a higher level and just relays what is on the screen as well as keyboard and mouse control.
So the best option is to use this software that supports depths from 4 to 32 bits:
http://www.anyplace-control.com/feat...nitoring.shtml haven't tried yet!
Also intertesting info: