I want a graphical application for Linux that displays the contents of CD/DVD/blu-ray drives and allows play or eject, and I'd like the solution to be general, so that I can donate it to Linux Mint, that is any drive type and any number of drives. In my system I have three dvd drives and a blu-ray drive.
I'd like to write it in bash using the dialog functions inside a terminal window but I need to have the dialog displayed in perpitude therefore, I need an interrupt to signal when the drive is opened or closed - what signal could I trap? Also, how can I include logic to select a program to play the media depending on the media type.
Also, should I consider writing it in java, python, C++, or other language and if so how to get hardware information (such as the number and capability of drives, and the type and title of optical media in drive)?
Ignoring the side of "I want to donate this to Linux Mint", which I believe is a bit pretentious, there is a eject utility in Linux.
The source code of that can be found here:
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/sys-utils/eject.c
In that code, there is also code to sense if the drive is open, closed, has no disk, etc.
To do CD or DVD playback is a whole other kettle of fish. To write a audio-player is not entirely trivial (even in the simple case of a straightforward PCM encoding, obviously MP3 is a fair bit more complex again), and a video-player is a lot more than that.
To "select a program", you'd have to know what the available players may be called, and, if you want to be fancy, check which ones are actually installed. I'm not aware of any really clever way of achieving that, beyond having a list of players in your code (which needs to be updated). In fact, I know that is how the photo viewer geeqie works when you want to edit a shot: it has a list of "known editors", and it scans the PATH to find which ones are available.
Related
Is there a Windows standard way to do things such as "start fan", "decrease speed" or the like, from C/C++?
I have a suspicion it might be ACPI, but I am a frail mortal and cannot read that kind of documentation.
Edit: e.g. Windows 7 lets you select in your power plan options such as "passive cooling" (only when things get hot?) vs. "active cooling" (keep the CPU proactively cool?). It seems the OS does have a way to control the fan generically.
I am at the moment working on a project that, among other things, controls the computer fans. Basically, the fans are controlled by the superIO chip of your computer. We access the chip directly using port-mapped IO, and from there we can get to the logical fan device. Using port-mapped IO requires the code to run in kernel mode, but windows does not supply any drivers for generic port IO (with good reason, since it is a very powerful tool), so we wrote our own driver, and used that.
If you want to go down this route, you basically need knowledge in two areas: driver development and how to access and interpret superIO chip information. When we started the project, we didn't know anything in either of these areas, so it has been learning by browsing, reading and finally doing. To gain the knowledge, we have been especially helped by looking at these links:
The WDK, which is the Windows Driver Kit. You need this to compile any driver you write for windows, With it comes a whole lot of source code for example drivers, including a driver for general port-mapped IO, called portio.
WinIO has source code for a driver in C, a dll in C that programmatically installs and loads that driver, and some C# code for a GUI, that loads the dll and reads/writes to the ports. The driver is very similar to the one in portio.
lm-sensors is a linux project, that, among other things, detects your superIO chip. /prog/detect/sensors-detect is the perl program, that does the detecting, and we have spent some time going through the code to see how to interface with a superIO chip.
When we were going through the lm-sensors code, it was very nice to have tools like RapidDriver and RW-everything, since they allowed us to simulate a run of sensors-detect. The latter is the more powerful, and is very helpful in visualising the IO space, while the former provides easier access to some operations which map better to the ones in sensors-detect (read/write byte to port)
Finally, you need to find the datasheet of your superIO chip. From the examples, that I have seen, the environment controllers of each chip provide similar functionality (r/w fan speed, read temperature, read chip voltage), but vary in what registers you have to write to in order to get to this functionality. This place has had all the datasheets, we have needed so far.
If you want something real quick to just lower fans to a level where you know things won't overheat, there's the speedfan program to do so. Figuring out how to configure it in the early versions to automatically lower fans to 50% on computer startup was so painful that my first approach was to simply byte-patch it to start the only superio managed fan I had at lower speed. The newer versions are still bit tough but it's doable - there's a graphical slider system that looks like audio equalizer except that the x axis is temp and y is fan speed. You drag them down one by one. After you figure out how to get manual control for the fan you want, this is next step.
There's a project to monitor hardware (like fans) with C#:
http://code.google.com/p/open-hardware-monitor/
I haven't extensively looked at it, but the source code and use of WinRing0.sys atleast gives the impression that if you know what fan controller you have and have the datasheet, it should be modifiable to also set values instead of just getting them. I don't know what tool is suited (beside kernel debugger) to look at what Speedfan does, if you preferred to snoop around and imitate speedfan instead of looking at the datasheets and trying things out.
Yes, It would be ACPI, and to my knowledge windows doesn't give much/any control over that from user space. So you'd have to start mucking with drivers, which is nigh impossible on windows.
That said, google reveals there are a few open source windows libraries for this for specific hardware... so depending on your hardware you might be able to find something.
ACPI may or may not allow you to adjust the fan settings. Some BIOS implementations may not allow that control though -- they may force control depending on the BIOS/CMOS settings. One might be hard-pressed for a good use case where the BIOS control (even customized) is insufficient. I have come across situations where the BIOS control indeed was insufficient, but not for all possible motherboard platforms.
WIndows Management Instrumentation library (WMI) does provide a Win32_Fan Class and even a SetSpeed method. Alas, the docs say this is not implemented, so I guess it's not very helpful. But you may be able to control things by setting the power state.
I am running Arch Linux on a Raspberry and need to get the positioning data for 4 USB mice from a C++ application, as in for each individual mouse I need to know how many pixels it has moved whenever it moved. I do not have x server on my system and would prefer to leave it that way unless necessary because this is for an embedded project that does not require a GUI and I would prefer not waste space or overhead on x server.
The most useful thing I have found is this link https://www.kernel.org/doc/Documentation/input/input.txt but I cannot really figure out how to make it work for my purpose. As can obviously be determined I am NOT experienced in Linux development do don't be to hard on me please.
You open e.g. /dev/input/mouse0 for reading (using open), then read the structure defined in the document you linked (at the bottom of the document), it also says which header file to include.
I'm guessing you will get an event of type EV_REL for mouse-movement, with a code of REL_X or REL_Y for the direction of the movement, and the value is the number of units the mouse moved. Compare the timestamp to the timestamp of the previous event to see how fast it moves.
When I connect the iPod (or iPhone) to the Windows PC,
it look like an USB drive, but I can't open a file on it because I can't know the correct file path.
I was also unable to drop the file to my application because the drag source does not have CF_HDROP.
Some applications can open a file on iPod, but it was a copy on the local temp folder.
screenshot http://img862.imageshack.us/img862/5396/ipodx.png
My question is ..
How can I directly (programmatically) open and read the picture file on iPod?
If I double click on it (or right click and select Preview menu),
it launches Windows Photo Viewer -- it is not my default picture viewer.
Can I change the file (.PNG) association to other application?
What's the viewer application's requirement to be a default viewer for files on ipod?
Applications that do that use Picture Transfer Protocol (PTP). On Windows Microsoft implements many interfaces as part of Windows Image Acquisition (WIA). Read more here: http://msdn.microsoft.com/en-us/library/ms630344(v=VS.85).aspx
http://support.microsoft.com/kb/307859 or manually edit registry at HKEY_CLASSES_ROOT\.png
Try the iPhoneBrowser program. It should give you a fair idea of the path.
From everything I've read I don't think Apple gives you access to the file system on the iPhone / iTouch / iPad; they want you to use iTunes to transfer files back and forth. I believe the Android and Windows Phone environments have similar restrictions. (If you "jailbreak" or "root" your device that's obviously a different story, which is why many such utilities explicitly state they only work on rooted devices.)
In part, this is a security precaution: if it were possible to directly access the file system on the mobile device it would be that much easier for someone to plant malware on your phone or PDA.
For this reason, updates to the various mobile OSes frequently include changes to (1) make jailbreaking more difficult and/or (2) close the loopholes that allow software like the iPhoneBrowser to work.
Some of the portable music players that use (Windows) Media Player have similar limitations. For example, I had a Sansa m100 (I think) where I could just drag files to the device and the playlist would automatically get updated; on at least some of the newer models (eg the c200) you have to use Media Player to download content. Which to me is annoying since there doesn't seem to be a way to use Media Player to delete content from the device.
There probably are APIs to do this sort of thing, but I would guess they're somewhat specific to the platform you're using -- ie I don't think you're going to be able to just use CreateFile() or something like that.
I'm not actually well versed in C++ or SDL_Mixer, but I'm asking this question anyway on behalf on the Doom community. Put simply, nobody writing Doom source ports can seem to figure out how to control normal sound volume and MIDI sound volume independently using SDL_Mixer on Windows Vista or 7. I'll let James Haley, author of Eternity Engine, put it in his own words:
Seems the concept of independent volume for native MIDI doesn't exist under Windows Vista or 7, as using MIDI volume sliders in any application that has them (including most games that use SDL_mixer) also affects the volume of digital sound output. This makes attempting to adjust the relative volume of music for comfort impossible.
Has anybody found any workarounds for this? I'm guessing it's unlikely given how Microsoft seems to have skimped throughout the OS on any way to control the volume of individual sound devices separately.
I've heard of various workarounds all involving a Timidity driver, but this requires the user go above and beyond simply installing the game on his system. The only port that I know of that definitively fixes this issue is ZDoom, but it uses the GPL-incompatible FModEx and is thus not a suitable solution.
If you want some code to look at, Chocolate Doom is perhaps the easiest Doom source port to grok and you can grab its source here.
Any suggestions on other open-source sound and music libraries would be welcome as well.
A solution would be to ship with a FluidSynth-enabled SDL_mixer. You would also need to ship a SoundFont2 file to go with it. Fortunately, there are free SF2's out there, and some are even optimized for Doom's MIDI files. Licenses shouldn't be a problem, since SoundFonts are assets, not code.
You then load the SF2 using Mix_SetSoundFonts().
You may want to look at different MIDI libraries outside of SDL.
http://wildmidi.sourceforge.net/
http://sourceforge.net/apps/trac/fluidsynth/
http://timidity.sourceforge.net
I am maintaining a similar game port (Descent 2), and I have come across the same problem. Afaik there is no solution for it when using SDL_mixer. A cure to avoid sound being muted when turning off midi music I have found is to retrieve a handle to a temporary midi device, set the midi volume to max and then close the temporary device again.
For the longest time, the only solution we found was to use something like PortMIDI. However, Quasar of Eternity Engine fame has come across a neat solution:
http://www.doomworld.com/vb/showthread.php?s=&postid=1124981#post1124981
He essentially puts SDL_Mixer into its own process and controls it with RPC. Very clever.
So one problem with the previous answer I gave was that sometimes the MIDI subprocess did not behave itself, and would break or stop working in strange ways. Eternity's specific implementation used IDL, and I personally re-implemented it using pipes, but the subprocess itself was a bug magnet.
Thankfully, another answer was figured out rather recently. You can simply bypass SDL_Mixer entirely and deal with Windows' native MIDI support directly, which turns out to not require a ton of code once you know what you're doing.
https://github.com/chocolate-doom/chocolate-doom/blob/master/src/i_winmusic.c
You can also implement this sort of idea with PortMIDI and get the benefit of being able to communicate with external MIDI devices as well.
https://github.com/odamex/odamex/blob/stable/client/sdl/i_musicsystem_portmidi.cpp
I am trying to fix an Audacity bug that revolves around portmixer. The output/input level is settable using the mac version of portmixer, but not always in windows. I am debugging portmixer's window code to try to make it work there.
Using IAudioEndpointVolume::SetMasterVolumeLevelScalar to set the master volume works fine for onboard sound, but using pro external USB or firewire interfaces like the RME Fireface 400, the output volume won't change, although it is reflected in Window's sound control panel for that device, and also in the system mixer.
Also, outside of our program, changing the master slider for the system mixer (in the taskbar) there is no effect - the soundcard outputs the same (full) level regardless of the level the system says it is at. The only way to change the output level is using the custom app that the hardware developers give with the card.
The IAudioEndpointVolume::QueryHardwareSupport function gives back ENDPOINT_HARDWARE_SUPPORT_VOLUME so it should be able to do this.
This behavior exists for both input and output on many devices.
Is this possibly a Window's bug?
It is possible to workaround this by emulating (scaling) the output, but this is not preferred as it is not functionally identical - better to let the audio interface do the scaling (esp. for input if it involves a preamp).
The cards you talk about -like the RME- ones simply do not support setting the master or any other level through software, and there is not much you can do about it. This is not a Windows bug. One could argue that giving back ENDPOINT_HARDWARE_SUPPORT_VOLUME is a bug though, but that likely originates from the driver level, not Windows itself.
The only solution I found so far is hooking up a debugger (or adding a dll hook) to the vendor supplied software and looking at the DeviceIOControl calls it makes (those are the ones used to talk to the hardware) while setting the volume in the vendor software. Pretty hard to do this for every single card, but probably worth doing for a couple of pro cards. Especially for Audacity, for open source audio software it's actually not that bad so I can imagine some people being really happy if the volume on their card could be set by it. (at the time we were exclusively using an RME Multiface I spent quite some time in figuring out the DeviceIOControl calls, but in the end it was definitely worth it as I could set the volume in dB for any point in the matrix)