The Problem
I'm working on a research project and need to get the Toshiba Bluetooth Stack to work with 3rd party hardware, a long range Bluetooth receiver, in a Windows 8 environment.
It worked fine for the first month, but then I got a message stating that the "Evaluation Period" had ended. (similar forum complaint)
Does anyone have an idea as to how I can disable the flag that's causing the evaluation period message or any other way to work around the software to get this up and running?
An interesting observation is that we do use the short range Toshiba wart dongles elsewhere in the lab with the same software. It works fine for those, but gets aggressive with the third party equipment. I've had to do related research with the short-range dongles and they can barely work for my purposes, with a lot of workarounds
Constraints
Both of my research devices are Bluetooth. One's a Wii Remote, so there's lots of work arounds out there, but the other is expensive, proprietary equipment that the (small) developer only really built to work with the Toshiba Stack
I've tried dealing with the Windows 8.1 stack, but it's highly unreliable, fussy to setup, and doesn't give me the COM port control I really need.
I've tried contacting the manufacturer of the Bluetooth receiver, but they're some thinly supported Chinese developer and haven't responded back to me
I've tried looking for alternatives to the Bluetooth receiver, but haven't had much luck, as most people have given up on applications involving long-range bluetooth.
I really need to stay with my proprietary hardware provider, as they've got other, unique hardware-related specifications that are necessary.
Fantastic solution from [Mike at Closet Junk] http://mikescloset.blogspot.com/2011/12/dell-toshiba-bluetooth-350-and-windows.html
Edit the Registry at HKEY_CURRENT_USER\Software\Toshiba\BluetoothStack\V1.0\Mng. Add a new DWORD key called TestVersion. Set it equal to 1.
Related
Scenario: A critical computer system is operator-controlled via standard USB keyboard and mouse. Also, there is a DVI-monitor connected to view the operator-targeted GUI. The computer system runs a soft-PLC system based on Windows 7 Professional or, alternatively, Windows Embedded Standard 7 (the "system software").
Question: Is there a software solution, to detect the loss (disconnect/failure) of USB HID-devices such as the keyboard or mouse, and the single DVI-display? This is important, since the critical system can no longer be expected to function properly, without the operator able to manipulate it or see displayed content.
Own considerations: This likely requires low-level WINAPI calls, which is fine. I am thinking that a windows service might be constantly seeking to enumerate the number of keyboards and displays - perhaps even identify them via model or serial number. If this enumeration and/or identification reaches zero or fails entirely, the system-software must of course react fast and appropriately (i.e. go to fail-mode or similar).
As far as I see it, this is general issue with all critical operator-controlled systems. Question is then: Is there already software or hardware for this in existence perhaps?
Note: Operator is always human.
Alas, as for an answer this isn’t going to be much more than a “read the docs” plus some links... Sorry.
First, MSDN documentation.
RegisterDeviceNotification
Detecting Media Insertion or Removal
Talking to USB devices, start to finish (Windows Store app)
I found a C# class on CodeProject.com that does this; the accompanying article is pretty good.
Detecting USB Drive Removal in a C# Program.
I admit that the last time I did anything like this was some years ago, and only for CD notifications. I’ve since lost the code (both my primary and backup hard drives failed within days of each other, LOL).
I'm looking to create a driver for a game controller I have (a cobalt flux www.cobaltflux.com ). The physical controller itself has nine face buttons and two control-box buttons (start/select). The control box has a usb port, but as far as I can tell no one has ever written drivers for it before. The end result I want is to be able to plug in the cobalt flux via the usb port and have windows recognize it as a game controller.
I have some programming experience. I'm a senior undergraduate student in computer science at UC Davis and an intern at a large embedded systems company, however this project involves several aspects I have no experience in: interfacing hardware and software via a USB port, investigating feedback from hardware I didn't build (which bits light up when I press a button?), and creating drivers and indeed programs in general for windows.
Since I don't personally know anyone who would be able to set me on the right track for a workflow to solve this problem, I'm asking here. I imagine the approach going something like:
I connect the device via a usb
I open up a program to poll what the effects of pushing buttons are on the USB channel
I write a program that interfaces those signals from the USB port to the game controller drivers that windows has
It may be worthwhile to note that I need to have joyPAD support and not joySTICK support for the buttons since play will involve pressing down any number of buttons at once and joysticks generally only register one direction of input at any given time.
Any advice or help would be greatly appreciated. I am having trouble figuring out where to start.
I have exactly the same problem for more than a year now and I did not found the right solution yet.
When you plug in the pad via USB it announces with a device ID and a vendor ID which device it is. Windows Plug-and-Play starts searching for a driver. This mechanism spots it is a pointing device (in my case one or 2 mice) and makes sure that it is treated as a raw data input device. Input from these devices is converted to messages handled by the OS. The solution seems to be to pass the messages of such a raw input device to the right handler. In my case the two mice are both recognised as mice and the messages are used by the same handler as the ones coming from the 3rd mouse that is really my pointing device. I am not experienced enough in C++ coding in order to dig into the rawinput API. I just received an interesting link as answer on my question: http://www.icculus.org/manymouse/ at least this gives an answer on my problem. May be it will give you ideas for writing your driver! Good luck !!! Stefan
Some computers (e.g. Dell, Vaio) come with software that prevents a battery from charging.
This functionality allows me to use my laptop with battery (protected from power outage) and keep my battery from charging until it's down to, at most, 50% battery/charge remaining.
I want do write some code to automate this task.
I searched Dell Support Center for a solution, and I searched Google, too - no luck with either.
I thought about downloading the program and debugging it, but I couldn't find it.
Has anyone ever seen something like this?
Thanks
PS: I want to do this on a Dell Inspiron, and the code can be in C++/C# (or something)
I've never heard of a program that disables battery charging. (Why on earth would you want this?) If such programs exist, I imagine that they interact with the firmware or hardware at a very primitive level.
One thing you can try is a busy loop (burning power like mad) that checks the battery level and sleeps for a bit once it gets down to the target level. This won't do good things to the cpu temperature, however.
Some laptops come with battery charge limiting functionality - it is not via software though, but via firmware plus dedicated internal hardware I guess. Some Lenovo and Acer have such capability. The logic is not in software as the charge limiter kicks in even when the laptop is off.
The reason is that battery degrade when kept at 100% - as it is the case with laptops that are always plugged in. The new Acer Swift would limit at 80%, some Lenovo let one input a particular value.
If interested I can provide you with the software side - it works on Windows and Linux but can easily be available on MacOS. It works in conjunction with external hardware - i.e. a homeplug.
The code works but it's by no means production ready. It would need a bit of tweaking for a particular operating system and homeplug. Let know if interested.
Available on github: Charge Limiter
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
As a programmer I found it very hard to use my laptop and workstation with two different input devices, Can anyone suggest a good solution to use single mouse and keyboard to control my two machines
I am not looking for a Virtual Machine or RDP solution to see my machines in a single monitor,
Synergy.
Synergy lets you easily share a single mouse and keyboard between
multiple computers with different
operating systems, each with its own
display, without special hardware.
It's intended for users with multiple
computers on their desk since each
system uses its own monitor(s).
Redirecting the mouse and keyboard is
as simple as moving the mouse off the
edge of your screen. Synergy also
merges the clipboards of all the
systems into one, allowing
cut-and-paste between systems.
Furthermore, it synchronizes screen
savers so they all start and stop
together and, if screen locking is
enabled, only one screen requires a
password to unlock them all.
P. S.
See also how to fix Synergy problems on Vista.
What you want is a small gadget called a KVM switch (keyboard, video and mouse switch). Googling for that term will hook you up with plenty of suppliers.
There is also a neat software solution called Synergy that lets you use your cursor and keyboard input over multiple computers connected by a network.
Yet another vote for Synergy for a software KVM solution. I'm not sure about the others, but it's unique if your computers are running different operating systems. It worked very well when I had a W2k/Linux setup across 3 computers.
Synergy is great, but also give something like VNC a try: it consolidates not only the keyboard and mouse but also the screen. In my case my desktop monitor is much larger than my laptops, and I'm more comfortable facing forward anyway (not looking off to the side where the laptop is.)
There is a lag compared to using a KVM switch, but no loss in video quality.
In my experience Synergy is the best way to merge multiple monitors.
Others include:
- x2vnc
- x2x
- win2vnc
- osx2x
- win2x
... pretty much just take what OS/platform you're on, which one you want to connect to, and put a '2' in the middle. Type that into google and you're good2go.
For my linux machine I use QuickSynergy since it provides a gui for easier configuration. It also has a Mac OS version.
The best...
Synergy
I'll put in another vote for Synergy, but with a caveat - setup can be a little tricky. The first time I tried it, I could move my cursor over to another PC but I couldn't move it back. Spend some time with the documentation before you proceed.
InputDirector is better than Synergy. Here's why...
It has built-in AES encryption functionality (without requiring you to install OpenSSH) for secure transfer of input between machines.
It allows cut & paste of text and files between machines (by automatically translating to C$ and D$ shares)
Based on extensive use with a laptop, it is far more reliable and stable than Synergy when reconnecting after undocking & docking. Synergy would frequently just stop working after docking and undocking, requiring me to kill it, restart it, and reconnect. InputDirector rarely has any issues.
The configuration UI is easier to use, and has more options, than Synergy.
Lots of little things, like matching of cursor location between machines during screen-edge transitions, and overriding mouse settings of "Slave" machines with those of the "Master" machine.
Beyond that, as far as I can tell, it does everything Synergy does. There's only a Windows version, but apparently it's also Vista compliant as well.
I've used both tools extensively, first Synergy, and then InputDirector. InputDirector is just a more robust application. It has all the features of Synergy and then some, plus the key ones listed above. It's website isn't as attractive, and while it isn't GNU GPL'd like Synergy, it free nonetheless, and an oustandingly well-functioning tool.
I used to use a KVM switch, but lately I've started running all my computers as virtual machines on a single hardware platform. Each "system" is a window on my desktop!
I have a triple monitor display, and I just remote desktop into my other machines. I have 2-3 laptops on my desk at any given time, and 3 servers to administer. Over a 1 gbps connection, I have very little latency to worry about, and I can be working on three computers at once without much trouble. This may or may not help you, but I thought I would throw it in there for you.
If you mean: two machines on your desktop, a lot of places use KVM-style switches.
They come in legacy PC-style and also USB. The USB version works with Macs and PCs.
My experience is that the small desktop switches are a bargain, and if you learn the keyboard shortcuts, you'll jump back and forth without much problem.
The machine room, 3-level tree KVM's are also pretty useful. They flake out more often, but when you have 60 machines, you simply can't have 60 pairs on input devices.
I'll second Zarkonnens comment about KVM Switches as I use one for this purpose all the time. However I might share some rather frustrating experiences with them:
I have found that PS/2 interfaces tend to be somewhat more reliable on KVM switches than USB - I have had very bad experiences with some supposedly upmarket DVI-USB KVM kit from Gefen and Avocent. Due to a quirk of my Viewsonic monitor where it would drop back to analog most of the time these were exacerbated to the point of the system being nearly unusable.
DVI and USB are finicky. DVI monitors will often time out and sleep if they get no signal. The KVM switch will assume that there is no monitor if it is not active, which will then be passed back to the video card. USB interfaces will also get put to sleep randomly.
The net effect of this was that it was very difficult to get two machines to boot up and work on the KVM switch and the switch would lose keyboard or mouse input on one or both machines every few days. This was followed by an hour or more of trying to get all of the hardware to come up and play nicely. I got the same issue with the Avocent and Gefen switches on several different machines.
My older Belkin VGA/PS2 kit worked fine with the Viewsonic monitors on VGA but I spent nearly £1000 on switches and cabling to try and get a working DVI-USB KVM setup.
In the end I got two HP LP2065 screens that didn't have the bug that the Viewsonics exhibited. These have two DVI inputs and I used one of my older Belkin PS/2 switches to switch the keyboard and mouse. The computers are plugged directly into the monitor and the monitor's input selector is used to pick the computer. The keyboard and mouse are switched off the KVM switch. This is the setup that I'm using today.
The monitors and KVM have to be switched individually but it's much more reliable than the DVI-USB KVM switches that really did not work at all. Caveat emptor.
You should also check out Multiplicity from Stardock.
The Free MS Windows replacement operating system ReactOS has just released a new version. They have a large and active development team.
Have you tried your software with it yet?
if so what is your recommendation?
Is it time to start investigating it as a serious Windows replacement?
Targeting ReactOS specifically is a bit too narrow IMO -- perhaps a better focus is to target compatibility with WINE. Because ReactOS shares so many of its usermode DLLs with WINE, targeting WINE should result in the app running just fine on ReactOS.
Of course, there will always be things that WINE can't emulate well (hence the need for ReactOS). In this way, it seems that if something runs in WINE, it will run in ReactOS, whereas the fact that something runs in ReactOS doesn't mean that it will necessarily run in WINE.
Targeting WINE is well documented, perhaps easier to test, and by definition, should make your app compatible with ReactOS as a matter of course. In this way, you're not only gathering the rather large user base of current WINE users, but you're future-proofing yourself for whenever anyone wants to use your app with ReactOS.
In their homepage, at the Tour you can see a partial list of office, tools and games that already run OK (or more or less) at ReactOS. If you subscribe to the newsletter, you'll receive info about much more - for instance, I was quite surprised when I read most SQL Server 2000 tools actually work on ReactOS!! Query Analyzer, OSQL and Books Online work fine, Enterprise Manager and Profiler are buggy and the DBMS won't work at all.
At a former workplace (an all MS shop) we investigated seriously into it as a way to reduce our expenditure in licenses whilst keeping our in-house developed apps. Since it couldn't run MSDE fine, we had to abandon the project - hope in the future this will be solved and my ex-coworkers can push it again.
These announcements might as well be also on their homepage - I couldn't find them after 5 mins. of searching, though. Probably the easiest way to know all these compatibility issues is to join the newsletter, or look for its archives.
I have been tracking this OS' progress for quite some time. I believe it has all the potential to really bring an OSS operating system to the masses for it breaks the "chicken and egg" problem: it has applications and drivers from the very beginning (since it aims to have full ABI compatibility with MS Windows).
Just wait for their first beta, I won't be surprised if they surpass Linux in popularity really soon after that...
Post Edit: Found it! Look at section Support Database, it's the web place to go look for whether a particular piece of hardware of some program works on ReactOS.
ReactOS has been under development for a long long time.
They were in some hot water earlier because some of their code appeared to be line by line dissasembly of some NT kernel code, I think they have replaced all of it.
I wouldn't bother with cross platform testing until they hit the same market penetration as Linux, which I would wager is never.
Until ReactOS doesn't randomly crash just sitting there within 5 minutes of booting, I won't worry about testing my code on it. Don't get me wrong, I like ReactOS, but it's just not stable enough for any meaningful testing yet!
No, I do not think it is time to start thinking of it as a Windows replacement.
As the site states, it's still in the Alpha stages. More importantly, whos Windows replacement? Yours? Your users? The former is one thing, the latter is categorically a no-go.
As an aside, I'm not really sure who this OS is targetting. It has to be people who rely on Windows software but don't want to pay, because people who simply don't want Windows can use MacOS / Linux, and the support (community or otherwise) for these choices is good.
Moreover, if you use Linux you already have some amounts of Windows software support via Wine.
Back to people who rely on Windows software but don't want to pay. If they are home users they can just simply pirate it, if they are large business users they already have support contracts and trained people etc. It's hard enough for large businesses to be OK to update to new versions of Windows, let alone an open source replacement.
So I suppose that leaves small businesses who don't want to obtain illegal copies of MS software, can't afford the OS licences and rely on software that only runs on Windows and has bad of non-existent Wine compatibility.
It is a useful replacement for Windows when it runs 'your' software without crashing. At the moment it is not a general purpose os as it is too unstable (being only alpha) but people have used ReactOS successfully in anger for specific tasks already. As a windows replacement it has multiple potential uses, sandbox systems, test and development systems, multiple virtual instances, embedded devices, even packaging/bundling legacy apps with their own compatible o/s. Driver and application compatibility, freed from Microsoft's policy of planned obsolescence and regular GUI renewal, what's not to like?