I am having an issue with connecting the Color Converter DMO object in graphedit (graphstudio, and in code). It works on one machine and turns green in graphedit, however on the machine I have to demo the program on it will not connect! I've looked at sdks, installs, and the machine should mimic my machine.
I also noticed that I can reregister the filter on my machine with regsvr however it fails on the other machine.
Any ideas as to what the culprit could be?
Why would you want to re-register it, it is either a core OS component, or not available at all
It is not a filter, it is dual interface DMO/DSP and while it is available within DirectShow through DMO Wrapper Filter, this use scenario is not guaranteed to work out smoothly and you possibly have to workaround issues.
Having wrapped it through DirectShow.NET library, the number of issues might increase, so you have to gather and provide more details about the errors on the way (HRESULTs etc).
Related
I've read similar questions others have had in using FTDI (CDC Class) and WebUSB, however none of the suggested answers have worked for me.
I'm trying to communicate to an Arudino Mega via:
this.device_.selectConfiguration(1)
this.device_.claimInterface(0); // or this.device_.claimInterface(1);
but I get a DOMException.. and chrome://device-log shows the device in blue ("USB user").
I know Chrome must use an interface that is not bound or attached to Windows, however, the USBconfiguration shows 2 interfaces, both not claimed, and yet I can't claim either.
Despite trying to uninstall and use WinUsb.sys, Windows always loads the ftdiport.sys driver NOT WinUsb.sys. Not sure what could be the problem.
The two interfaces are listed as unclaimed because your page hasn't claimed them. Whether or not there is another application or driver on the system claiming the interface is not reflected in the API.
Fighting with Windows to not load ftdiport.sys may be a losing battle. I am working on implementing the Serial API in Chrome which should offer a better solution for this class of devices. Alternatively, have you tried installing the WinUSB driver with the Zadig tool?
I have installed Domino Designer in a Windows VM on VirtualBox on OS X.
When I start entering code in the JavaScript editor, Domino starts to work for every letter I type. The hourglass icon appears and the network symbol on the status bar flashes. This operation takes up to several seconds for every letter I type.
If I try to type anything before the hourglass disappears, the keyboard may hang up and the result is a long list of the same letters that I have to delete again (causing the hourglass to appear for each letter I delete again).
I have tried to disable functionality like "Content Assist", "Quick Diff" and other helpful stuff without luck.
I would really appreciate hints or tips to make this nightmare vanish...
I've not used domino designer, but first thought would be that your VM isn't handling the processing required by the designer.
What are the specs on you windows VM? Did you allocate enough RAM, for example? Make sure they match the requirements to run the designer:
http://www-969.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProduct?deliverableId=1351628933716&osPlatform=Windows
Thanks to Joel for leading me into the right path.
I did several things, and together it now seems that I have a much better environment. I still see the hour glass from time to time, but it does not mess up my code anymore, and most of the time it does not bother me.
What I did was the following:
Changed the memory settings for Domino in this file:
[notes dir]\framework\rcp\deploy\jvm.properties
New values:
vmarg.Xmx=-Xmx1024m
vmarg.Xms=-Xms512m
vmarg.Xmca=-Xmca512k
Then I changed the virtual memory of my guest Windows install to a fixed swap file of 4096 MB.
At least I connected my Mac to a faster network using Thunderbolt to Ethernet cable adapter. I don't think the last thing did any difference, but at least I now have a faster and more reliable network connection.
One of my customers had a problem with a Xeon E5 machine: they were having one gpu (I believe it was an NVIDIA one) hanging and they solved by adding the
intel_iommu = igfx_off
in the grub loader.
What is this value and what does it? I read around but couldn't just figure that out in simple terms
Quoting from the "Intel-IOMMU.txt" file included in the Linux kernel documentation:
"If you encounter issues with graphics devices, you can try adding option intel_iommu=igfx_off to turn off the integrated graphics engine. If this fixes anything, please ensure you file a bug reporting the problem."
Apparently the GPU in this case was not working properly with the DMAR (DMA Remapping) feature provided by the Intel chipset. Using the "igfx_off" parameter allows the GPU to access the physical memory directly without going through the DMAR.
The purpose of the DMAR feature is to enable things like direct assignment of hardware to virtualized guests. If you have to use the "igfx_off" parameter then you probably won't be able to use this GPU in such a direct-assigned virtualization scenario.
I am working on a QT application for which I've integrated DirectX 11 into a custom widget. The application renders a scrolling display - a graphical representation of data being read from a file. The user can speed up and slow down the scrolling speed.
For the most part, this is working great. The DirectX 11 rendering is presented to my custom widget just as I'd expect. The problem is that the graphics driver randomly hangs and crashes my program. I say "random" because I have been testing this with the same data file and it never seems to crash at the same point in the file, after a specific amount of time, or at a specific scrolling speed (the faster the scrolling speed, the more work being done by the GPU per frame).
When the application hangs, my screen freezes for a moment, goes black, then returns with a nice message from NVidia that it has recovered from a driver crash. The Debug Output in Visual Studio contains the following:
D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice:
Device removal has been triggered for the following reason
(DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of
time to execute its commands, or the hardware crashed/hung. As a
result, the TDR (Timeout Detection and Recovery) mechanism has been
triggered. The current Device Context was executing commands when the
hang occurred. The application may want to respawn and fallback to
less aggressive use of the display hardware). [ EXECUTION ERROR #378:
DEVICE_REMOVAL_PROCESS_AT_FAULT]
I have discovered that by simply commenting out the IDXGISwapChain1::Present call, the application will run through the file at blazing speed. Graphics-wise it is still pushing data to the GPU and drawing to render targets, it just never gets displayed to my window.
What I'm hoping for is help with ideas of what types of things cause driver hangs. My shaders are incredibly simple - basically just positioning my vertices using a projection matrix. And considering what I described in the above paragraph, shaders should still be cranking through vertices and pixels even when Present isn't being called, yes?
I was suspicious that this could be a compatibility issue with Qt - I know DirectX isn't officially supported by Qt. So I tried creating a separate window using CreateWindowEx and using that for my swap chain instead of the custom Qt widget. It rendered to that window but also hung the driver just like before.
I was also suspicious of a driver bug in my laptop, so I tried running the application on a beefier desktop PC that regularly runs another DirectX 11 application (non-Qt) without a hitch (worth mentioning that this other application renders similar data in a scrolling display as well, using shaders that are a lot more complex). But my QT application hangs the driver on that PC as well.
Anyone know of a way I can get a more detailed description of what is causing the driver to hang?
Thank you in advance for any help you can offer.
UPDATE: 2013-08-01 17:16 CST
I am currently investigating a possible thread syncing issue that may be the culprit. Will continue tomorrow morning and post if I solve this on my own.
After some testing today, it appears to have been a threading issue. I have run several times today with no graphics crash. So my problem must be fixed, unless I've just been getting lucky with my tests today (or unlucky, rather - if this shows its ugly face again in a day or two).
I was aware that the immediate device context is not thread safe. Rather than using deferred contexts, though, I was using critical sections to sync my threads and coordinate use of the device context. What I did not realize is that it is not safe to call IDXGISwapChain1::Present while another thread is using the device context. Makes sense, but since it is not call directly from the device context itself, I overlooked it. I literally moved my Present() call a few lines up into my critical section block, and it hasn't given me a crash since.
I would like to change the output mode of an Intel GMA450 based graphics chip to "cloned" mode.
Since the environment is a Windows Embedded Standard and only one of the connected monitors might be visible for the enduser, I would like to either permanently set the output mode to cloned or reset it continuously to cloned mode in case the actual mode differs (e.g. after a reboot, disconect/reconect of the second monitor or by other means).
Is there a way (Registrykey, API for the Intel driver, Win-Api) to change the display mode to cloned / dual output programatically?
Update:
I found the SDK for the IEDG driver it seems that I might be able to programatically set the resolution, clone mode etc.
However, I can't find the SDK or any information for the driver I am currently using: Intel® Graphics Media Accelerator Driver for Windows* XP, version 14.32.4.4926.
This isn't a good answer, but it might get you headed in a direction to figure it out.
My last laptop had an external monitor connected, and the Intel drivers would often be confused about the orientation of the secondary after a reconnect or a reboot. I got tired of dealing with that and tried to fix it programatically because the clicks were too many in the GUI. Select this monitor, select rotation, select other monitor, select rotation, apply, arrange, apply, wait...
I spent about a day on it (ahh, the days of being an employee vs. self-employed!) and the solution I found was to use a program to compare the registry (regshot perhaps?) to discover what keys were involved in the correction (what they were before versus what they were after) and then there was an intel-provided exe that forced the driver to reset based on the registry-- the exe was essentially like pressing the "apply" button in the gui. I was running XP and if I recall, the gui management was for configuration of the Intel Graphics Media Accelerator Driver for Windows XP as well. So the final solution became a cmd file on my desktop that would apply a REG without confirmation and then run an exe with some parameters.
Now, I don't have that laptop (they didn't let me walk out the door with it when I quit!) and I do not remember the specifics on the exe that was required to do the reset. Just changing registry keys didn't spontaneously cause it to take effect-- there was an api call involved, which I just handled with their exe. I know that isn't a lot to go on, but something tells me the file was in the driver package, or somewhere on the drive already, and I just found it. Running it at the command line gave options. Like /reset.
I hope that helps you a little. Be sure to post back if you figure it out.
Also post back if I'm completely mistaken and it didn't happen like this at all. But that's the way I remember it. :)