Gmu Music Player
Gmu is an open source music player for portable gaming consoles and handhelds. There are versions available for the GP2X (both F100 and F200 devices are supported), the GP2X Wiz, the Caanoo, the Dingoo A320/A330, the Ben NanoNote, the Pandora handheld and the Zipit Z2. Gmu supports lots of audio file formats and includes various features. For an overview have a look at the features list below.
- Supports Ogg Vorbis, Ogg Opus, MP3, MP2, Musepack (MPC), FLAC, WavPack, Speex and various module formats (MOD, XM, IT, S3M, STM, ...)
- M3U playlist import/export
- PLS playlist import
- Internet audio streaming (web radio)
- Various play modes including random and repeat modes
- File browser
- Cover viewer (Gmu supports jpg, png and bmp image files and cover images embedded into ID3v2 tags)
- Graphical spectrum analyzer
- Hold function (turns off display backlight for power saving)
- Customizable key mappings and skin support to be able to change Gmu's look & feel
- In addition to the SDL frontend, there is a new ncurses text interface (usable over the network!)
- There is also an experimental WebSocket-based browser interface (Gmu's webserver is listening on port 4680)
By the way, Gmu has been mentioned in an article in the German magazine "LinuxUser" issue 04/2008. The article is available on their website
Source gmu-0.10.1.tar.gz (487 KB)
Source gmu-0.10.0.tar.gz (493 KB)
Zipit Z2 OpenWRT build gmu-0.10.0-zipit-z2.zip (475 KB)
gmu-0.9.1.pnd (Pandora package, 2.5 MB)
gmu-0.9.1-caanoo.zip (Caanoo package, 0.7 MB)
gmu-0.9.1-dingux.zip (Open Dingux package, 0.7 MB)
gmu-0.9.1.tar.gz (Source, GPLv2, 0.5 MB)
gmu-0.8.0BETA1-gp2xwiz.zip (GP2X and Wiz version)
725 KB, md5sum: 400e08bb7e2be3266d9b96a1c7405579
gmu-0.8.0BETA1-dingux.zip (Dingoo A320/A330 [Dingux] version)
775 KB, md5sum: 8a05ac8fcfc040b2e36ebb52cd0d5e31
gmu-0.8.0beta1.pnd (Pandora version)
1.4 MB, md5sum: dba836ffcd3937b0a0d8d86b73c0e1b4
gmu-0.8.0BETA1-zipit-z2.zip (Zipit Z2 [uClibc] version)
245 KB, md5sum: d61f9f7da4a88d3e1432e2e34a90580e
gmu-0.8.0BETA1.tar.gz (GPLv2 source)
240 KB, md5sum: a1a3d346802f3877b4c739b3c65225d6
Does Gmu support Speed - http://www.speex.org/ - if not is it a feature anyone would be interested in adding? Would be happy to make a donation to help this feature work well with gmu on ben nanonote - would like to include a lot of spoken word stuff preinstalled on ben nanonotes Freedom Included, Inc. sells (FSF / GNU / RMS speeches etc.), and speex is fantastic at speech compression.
Also, is there a good way of talking about gmu other than this "Leave a comment" box (mailing list / forum / identi.ca / etc)?
Also going to make our standard donation for software we find really useful in general (sorry it's not much; not raking in the money quite yet ;-)
\|/ Daniel JB Clark | Activist; Owner
FREEDOM -+-> INCLUDED ~ http://freedomincluded.com
/|\ Free Software respecting hardware
Daniel J Clark: Thanks for the donation. :)
speex is currently not supported, but I'll have a look at the speex library. It is probably not very hard to include support for speex. I could possibly include support for it in there next Gmu release.
As for talking about Gmu, besides commenting Gmu releases on my blog (which some people do), people also discuss Gmu on the gp32x.com forums and some talk about it on the qi-hardware mailing lists. I myself don't like mailing lists very much, so I tend to use forums more than mailing lists. Usually whenever I release a new version, the Gmu release thread over there at gp32x.com is also being used for feature requests and discussion.
Currently there is no specific Gmu forum or mailing list, though.
I'm trying to compile gmu for the Ben Nanonote using Opemembedded toolchain in order to get mp3 playback support. The problem is that in the decoders folder FLAC and VORBIS files are not included and it causes errors. I've skipped this encoders and now I can play mp3 but not flac and ogg files. Is there any reason for not to include these files?
sucotronic: Please verify that your gmu-0.7.1.tar.gz file is intact. You should try re-downloading it if it is broken.
Its md5 checksum should be 62653037d2046d992626eaf6d0a365e3.
In the src/decoders folder there should be the following files: flac.c mikmod.c mpg123.c musepack.c splay.cc vorbis.c and wavpack.c.
To be able to build the FLAC and Vorbis decoders, make sure you have the necessary libraries installed in your toolchain. A recent libFLAC 1.2.1 is required for the FLAC decoder to be built. For the Vorbis decoder you'll need Tremor (also known as libvorbisidec).
You were in reason, I forgot to build the Vorbis and Flac packages before making gmu. Thanks for the help and the program!
sucotronic: You're welcome!
I can't get it work on my F200. After a while, get back to the launcher screen. Is there anything to install?
Ted: On the F200 it might only work with the Open2X firmware. In case you are using the old GPH firmware, you could use the old Gmu 0.6.3 which works with that firmware or switch to the Open2X firmware.
I've been using GMU since i got my wiz and it's a beauty.
I've only one question, have you got any idea why using a 16 gb SD it crashes after playing six or seven songs in continue mode ?
The 8 gb SD doesn't give me this problem.
Thank you very much, nice work.
Marco: Gmu does not care what kind of SD card is being used, which is why I suspect that there is something wrong with the card itself or the filesystem on it. You could try to check the filesystem for errors or reformat the card.
Thanks for the reply but I can't find any of previous versions of GMU. Could you post link to them.
Thanks in advance.
Ted, here you go: http://wejp.k.vu/files/gmu-0.6.3.zip
Thank you very much. It's working as well as it used to.
Great job for this soft by the way.
i just switched to 0.7.2 and now it crashes when i try to load it i've tried downloading it twice etc no dice
never mind that last comment works great thanks
I loved your player on my GP2X F100 and use version 0.7.2 on my Pandora now. I noticed that I cannot get a file to play directly pressing the A-Button (nothing happens). That's a pity as I liked that feature quite a lot. Would be really great if you could fix that.
Abaddon: I'll look into that issue. It is probably only a missing/different key mapping.
what font do you use for the gmu playlist area? thanks again for my favorite player on gp2x!
starpause: It is a bitmap font (drawn with the Gimp). Have a look at the theme directory, you'll find it there as a PNG file.
Thanks for GMU, it's an absolutely awesome player!
On the pandora, 0.7.2, The (A) button to play single files in browser mode is not working for me though; is that a known bug?
Timothee Groleau> Thanks. :)
I might have made a mistake with the Pandora keymap. If I remember correctly, someone else mentioned the same thing a while ago. I'll fix the keymap with the next release. If you want to, you can also easily edit that file yourself to fix that (and also remap any buttons you like). It is the pandora.keymap file (plain text) inside the Gmu .pnd.
First of all, nice music player for my dingoo!
But is there any way to get only mono output without compiling?
jmi: Gmu itself does not support mono output for stereo audio files, but if you are using a kernel with ALSA (I think OpenDingux uses ALSA), you might be able to create a virtual audio device through .asoundrc to downmix the stereo signal to mono output.
May I ask what you need mono output for?
wejp: Thx for the quick reply! My right audio channel is broken (headphone and av-out), so my plan was to connect both headphone socket connections with my left channel and use mplayer and gmu with mono output. Your idea was my plan b, guess I will go for it.
Thanks Johannes, I'll try to edit the keymap and get the A button working :) . On a separate note, what would it take to have AAC support in GMU?
Adding AAC support would be a matter of writing a decoder plugin for aac using aac decoder library capable of decoding with integer math only. I'm not very interested in implementing such a decoder plugin, for a few reasons. For one I don't have any AAC files myself, but more importantly I think AAC is a bad format which should not gain too much use. I would strongly suggest using Ogg Vorbis instead.
If you want to implement an AAC decoder plugin, you are welcome to do so. Gmu's decoder plugin API is pretty simple and easy to use. If someone can give me a _really_ good reason for doing so, I might consider implementing it myself, but until then I rather implement other useful features for Gmu.
Looks very good..
I would be deeply grateful for a Caanoo Version,
why is this file offline?
 gmu-0.7.2-dingux.zip (Dingoo version)
868 KB, md5sum: 080cda8e2a90d2a49fa6f3b30faeb97b
karl: Must have been lost when I moved my website to a new server. Any reason in particular why you want that old version?
Thank you for your work. I'm using it on my Dingux to listen to audiobooks. Very appreciated.
I was having a couple of questions
1. Will there be an equalizer? (I haven't found an easy way to hardcode equalizer settings to mp3s and my audiobooks could really use some equalizing so they sound better)
2. Is it possible to do some key remapping? (I usually accidently press A button instead of the X button when I want to pause/resume audiobooks, since I keep it in my pocket and it's the first button that touches my fingers)
3. GMU skips the last 10 seconds of every mp3 file. (I haven't tried it with shorter files, mine are about 15-30 minutes each file.)
4. Will GMU ever be able to remember position of files even when I listen to something else instead? That's the reason I'm using it only for audiobooks, because if i want to listen to music I have to search the audiobook again to find where I was.
/ Thank you! / Jonis
1. Currently there is no equalizer, but I'm considering to add one in the future. I can't say much more than that right now.
2. Yes, this is possible. All you need is a text editor. You have to open the .keymap file that is being used in an editor (should be dingux.keymap in your case) and modify it according to your needs. I'd say the file's format is pretty self-explanatory. Also have a look at the README.txt file that comes with Gmu. There is some more information on that matter.
3. That should not happen. If there is any way you could supply me with a test file (we can discuss this by mail), I could have a look at that. I haven't noticed anything like that before. All I could imagine right now is, that files with variable bitrate, that are broken somehow (e.g. files that have an invalid XING header) could cause such a behaviour, but even in such a case Gmu should play the whole file, unless try to seek in the file. In such a case the remaining playtime display could be wrong, though.
4. Interesting idea. If I understand you correctly, you want Gmu to be able to remember the position on a per file basis? This is currently not possible, but would be possible to implement. I'm not sure how this could be integrated nicely with the user interface. Maybe I could add some sort of bookmark featre where one can bookmark files including the current position. I guess I need to think about that one some more. If you have an idea how to present such a feature to the user, I'd like to hear about it.
Thank you for such a nice application. My gp2x now serves mainly as a multiformat music player in my car.
I also got it to on my linux box. The key mapping took a little trial and error but I think I'm satisfied now. :)
ps. I play the same modules with modplug and it seems mikmod is missing a channel or two sometimes. Anyone else notice that? And thanks again for the nice software!
I just want to thank you for this great app.
I used to enjoy it on my gp2x, but now it's broken :( I got a Caanoo now and I miss gmu !
What about an android port?
A linux desktop (SDL?) port would be great too!
Cyberic: Every now and then people ask about an Android port and I have actually considered creating one. The problem with that is, that I would at least have to rebuild the entire GUI to somewhat match Android's look and feel and make it touchscreen friendly. So I might actually do this, but this will take some time for sure. When I do that, I want to do it right. I really want to avoid releasing something that's barely usable.
As for the PC port, this is much easier to do. Actually one can already compile Gmu for a PC (at least for PCs running some sort of Linux or BSD) and it'll work fine. On the PC, Gmu can run in windowed or fullscreen mode. There is no support for mouse control yet, but this might change in the future. Also I am currently implementing another user interface for Gmu, which can be used instead of the current interface or in addition to it. As it is work in progress, I will not say more than this right now.
Great, good news, I didn't know about the linux port, I'll give it a try!
About the Android port, you could do as Rockbox did: they kept the same interface! for the first version you could even add a kind of virtual keyboard and/or virtual arrows, like in emulators for instance.
This would be sufficient to be used, I think, even it everything is not "android-like" at first.
Great news for the PC port.
As long as it can run in the frambuffer without X, I don't care about mouse support.
I was hoping to download Dingoo 0.7.2 too. Need the mpg123 decoder/library for BNN mp3 playback.
Justin: Here you go: http://wejp.k.vu/files/gmu-0.7.2-dingux.zip
Thanks wej. Matching library and decoder works perfectly with matching release. I should have a couple $ to donate next month.
Justin: Thanks, I appreciate that. :) Glad that it works for you.
Is there a way to fast-forward through the file that is currently playing?
Justin: Yes, there is. Which button or button combination to use, depends on the device you are using. On devices like the Dingoo (and similar devices) it is usually configured such that fast-forward/backward is on the same buttons as skip forward/backward combined with the modifier key (that's the button that switches the other buttons to their second functions while hold down).
Awesome! Alt-M does the trick on the Ben. Thanks wej.
Awesome project! Thank you so much!
By the way is there any way to run Gmu playback in background on Dingoo A320? Would be very useful imho. I'm surprised that no one ever did request for this feature.
vigilancer: You're welcome! As for the background playback: I understand that background playback would be a useful feature and I am interrested in implementing that. Actually, I am kind of working on it (preparing things for being able to actually implement it), but it is not as easy as it might seem at first, so better don't hold your breath for that feature. ;) I want to add it eventually, but it will take some time.
Hi wej, thank you for this project. I can re-purpose my Caanoo now to be a network music player.
One thing I observed is that the http server is not started on Caanoo. The password is 9 chars long and gmuhttp.Listen is set to All. I checked the port with netstat on Caanoo, and it's not open.
Also, I would like AAC support, because most online radios in my country use AAC, probably because it sounds better at lower bit rates than MP3.
0sAND1s: Thanks for the feedback, I'll have a look at the http server issue with the Caanoo version.
Thank you very much for this Programm, I hope it will help to make my Girlfriend loves my Gameing-Consoles cause she loves music and Player that shows Covers, Lyrics ...
So I'm very happy to test it soon on my GCW Zero.
Can this Programm also handle my PodCast OPML Files from old Podkieker?
Mae: OPML is currently not supported. As OPML files are XML files, an XML parser would be needed to support that format. Unfortunately XML parsers tend to be rather bloated. Maybe I'll evaluate available XML parsers at some point or write my own to add support for such formats. I don't want to use libxml2 (or anything of similar size).
Hi, Still using GMU on my Nano Note among other other music/audio players.
A feature request x2:
*ReplayGain support with the option to toggle it on and off in the GUI, pretty please. :)
*and what about Opus support, assuming it's practical to decode on my NN compared to the optimized Vorbis decoder?
Thank you very much for your work.
Should you impermanent them/replaygain then I hope a build becomes available for NN's. I haven’t got around to setting up a compiling env and probably won't any time soon....
Astr: Opus support is in the works and will be available with the next release. I haven't done any testing of the Opus decoder on the NN yet, but it should work okay.
As for replay gain, I will probably implement that at some point, but I can't give a timeframe when that will be ready right now.
I'll try to build Gmu binaries for most of the supported systems. On the Nanonote, Gmu should be part of the official firmware, so (at least in theory) new Gmu releases should become available with new Firmware versions for the NN. In case there is no new firmware to be released, I'll probably try to build a binary for the NN myself. It is quite some work to build binaries for all supported plattforms, so I might omit one or two plattforms occasionally, though.
Any plans to put this up on the AUR? I'd be willing to create a package if a Git repo is available.
David N.: I'd be interested in having Gmu in AUR, but currently there is no public git repository. So the package would have to rely on the release tarball (which is safer anyway as repository snapshots are not guaranteed to be working properly).
I haven't been able to cross-compile Gmu for the Zipit Z2, but I successfully built it on the Zipit itself using unknown.mk. However, I get an error: 'Could not initialize SDL: No available video device.' If I can get a working build, I'll try writing an AUR package for it, based on the release tarball.
David N.: Thanks for trying to create an AUR package. The SDL error message you get there probably is not an issue with Gmu, but with the SDL library itself. It looks like the SDL library in use has not been compiled with support for the framebuffer device, but only for X (which is not very useful on the Z2, but might be useful on ARM devices that run an X server).
wej, I think a couple of Zipit distros run X, but I have no idea which of the 56 packages to install from group 'xorg,' or if installing X would even fix the problem. Maybe creating a package for SDL that compiles it with framebuffer support would solve the SDL problem. Either way, I have a feeling this package is going to get out of hand rather quickly.
Any idea if there is a package that provides arm-openwrt-linux-gcc for cross-compilation? I ran it through pkgfile, but the search came up blank.
David N.: Yes, it is possible to run X on the Z2, but it is not that useful. To use X beyond what's possible with the framebuffer device alone, you would need a larger screen resolution. To use it merely for running SDL applications it, it wastes way too much of the rather small RAM of the Z2. Also, because of the additional abstraction layer it is slower than simply using fbdev. Building a SDL package compiled for frame buffer device would most likely be more helpful than using X.
As for the OpenWRT gcc: As you will most likely need more than just the compiler anyway, it is probably best to simply use Openwrt's toolchain script to bootstrap a complete OpenWRT build environment. That way you have a working compiler and you can also easily build new and existing OpenWRT packages. It is very configurable (through an interface pretty much like the Linux kernel configuration curses interface).
I am not exactly sure what you wanted to use that openwrt gcc for. I assume for building openwrt packages.
For building Archlinux ARM packages I suggest you check out ArchlinuxARM's website. There is some information about how to cross-develop packages.
If I remembery correctly, the easiest way was to use a chroot ArchlinuxARM environment with QEMU. That way you don't have to deal with the hassle of real cross-compiling at all.
wej: Do you think SDL2 (https://www.archlinux.org/packages/extra/i686/sdl2/) is an option? It comes with framebuffer support by default, but I'm not sure if it is a drop-in replacement for the SDL package. I'll try installing SDL2 and recompiling Gmu, but I'd also like to hear your thoughts. If it works, an AUR package will be as simple as SDL2 as a dependency (at least for ARM devices?)
I asked about arm-openwrt-linux-gcc because:
$ make TARGET=zipit-z2
/bin/sh: arm-openwrt-linux-gcc: command not found
Makefile:97: recipe for target 'core.o' failed
make: *** [core.o] Error 127
Emulating an ALARM environment does sound like a better alternative, but if I can get Gmu to build and run correctly on the Zipit, neither emulation nor cross-compilation will be necessary. That way the same package can be used on desktops and the Zipit (and probably other ARM devices).
David N.: Oh, now I see why you asked about the openwrt gcc. The Z2 build config file included with Gmu was initially created for the Z2 OpenWRT distribution, which is why it uses that compiler. It is configured in the zipit-z2.mk file, where you can easily change the compiler to something else, or you could create an .mk file for ArchlinuxARM, as Gmu for Arch ARM would probably not be limited to just the Z2, but run on basically any ARM device with a framebuffer.
For building instructions also check out the BUILD.txt file which I have included wiht the Gmu source. It is fairly simple to create new build configurations for new platforms.
About SDL2: Unfortunately SDL2 is not compatible with SDL 1.2. At some point I will most likely "update" Gmu to (also?) support SDL2, but currently this is not very helpful, as many of the supported platforms Gmu runs on, do not yet support SDL2, but only SDL1.2. Some of them probably never will support SDL2.
Building Gmu natively on the Z2 should work an din that case you should be able to initially build it with the default unknown.mk file (which uses gcc without any prefix by default).
One thing to keep an eye on is the memory usage. Especially linking all the files into the binary can use quite a bit of RAM. You might need swap to successfully do that on the Z2 and it will probably be pretty slow (which should not be that much of a problem as Gmu is not that large).
All .mk files except the unknown.mk are meant to be used for cross-compiling. Of course all those files can easily be adjusted to use the native compiler, if necessary (through the CC=... line).
"The Z2 build config file included with Gmu was initially created for the Z2 OpenWRT distribution" Ah, that explains a lot. I guess there's no point in using zipit-z2.mk on ALARM then.
"Building Gmu natively on the Z2 should work" It builds fine, but that's what led me to the SDL runtime error. Updating to SDL2 would be the best solution (for devices that support it), but that's of course easier said than done. To allow SDL 1.2 devices to continue working, a -DUSE_SDL2 option might suffice.
I'm thinking the best option for now is to include a version of SDL compiled with framebuffer support and link it as a static library.
> To allow SDL 1.2 devices to continue working, a -DUSE_SDL2 option might suffice.
Something like that would probably be what I'd do. The thing is, I would have to maintain two code paths, one for SDL1.2 and another for SDL2.
> I'm thinking the best option for now is to include a version of SDL compiled with framebuffer support and link it as a static library.
Linking statically would be one option, another would be to create a proper SDL package for ALARM with framebuffer support. The advantage of that would be that it could be easily used for other SDL-based applications as well, which would be very useful. If you then say in the frambuffer SDL package configuration that it is a valid replacement for the normal SDL package, none of those SDL applications would have to be recompiled or anything. They should just work with that SDL package on the Z2, assuming that the applications in question support the Z2's screen resolution of course.
So, I created an 'sdl-directfb' package. I'm waiting for it to compile at the moment (once again, I can't make any promises), but if it works, I'll create a Gmu package with it as a dependency. Should I give it a specialized name (i.e. 'gmu-directfb') and save 'gmu' for a desktop (SDL+X11) version, or just call it 'gmu'? (Keep in mind sdl-directfb replaces Extra/SDL)
It would be best to configure the Gmu package to depend on SDL and then build the sdl-directfb package such that it works as a replacement for the default SDL package. That way, there is no need for a special Gmu-directfb package at all. Also, every other existing SDL application can make use of that SDL-directfb package without any changes.
wej, Ah, so what you're saying is create an AUR package called 'SDL' that replaces Extra/sdl and has directfb support? That's easy enough to change from what I have currently. Although I'm going to see if I can install a precompiled binary from the "SDL with directfb" package; it's been compiling for hours and it's /still/ not done.
When you say "works as a replacement for the default SDL package" do you mean using
or by giving it the same name ('sdl')?
> When you say "works as a replacement for the default SDL package" do you mean using replaces=('sdl') or by giving it the same name ('sdl')?
I think the correct variable would be 'provides' (and maybe also 'conflicts') not 'replaces', so provides=('sdl'). 'replaces' is only used when a package is to be renamed. You do not have to call the package 'sdl', though. It could very well be called sdl-directfb or something like that.
wej: Just an update: I haven't abandoned this endeavor (yet), but I have run into some trouble running ALARM in a Qemu virtual machine, and compiling SDL on the Zipit, while possible, isn't really feasible. It turns out emulating an ARM system is quite a bit more tricky than an x86. If I can get an ALARM VM running, I'll see if I can compile SDL with directfb and package the binaries using provides=('sdl'). After that, Gmu with unknown.mk /should/ work.
Hi, Is it programmed to run in the A320 OpenDingux? It force closes after trying to open... Is there any version compatible with A320 OD? Thanks in advance.
Daniel: Yes, it is. Are you sure you have executed the right file (gmu.dge NOT gmu.bin)? If so, did you try the older versions as well?
Version 8.0 Beta 1 worked for me. Thank you.
machst du noch was am GMU manchmal?
Ich hoffe es geht dir gut, schon lange nimmer gelesen :D
schön von Dir zu lesen! Ja, ich mache tatsächlich noch was an Gmu, nur geht es relativ langsam voran. Ich habe hier schon einen Haufen Änderungen herumliegen, muss es nur irgendwann mal schaffen, ein Release zu machen. :)
Hi, not sure if it's been asked but does gmu run on raspberry pi running raspbian?
pdrift: Gmu should run just fine there. I've tried it on a Raspberry Pi 1 and had no issues (although not with Raspbian in my case). Since Raspbian is basically a Debian system, it should be rather trivial to build Gmu on that system. You might want to adjust the key bindings to your liking, but that can be done by simply editing an easy to read text file.
Thank you for you your response. I have used your player on my zipit z2 and really like it. As far as building it, is there a guide on the procedure?
pdrift: There is. Gmu comes with a file called BUILD.txt where I explain most of the build process. Also, starting with the 0.10.0 release of Gmu I have simplified the build process by including a configure script. So basically all you have to do is run that script and then run "make" afterwards. Of course given that you have all dependencies installed. Many of Gmu's dependencies are even optional (like all decoder libraries - if you don't need or want a certain decoder, you don't need to have the decoder library installed).
Thanks wej, I will try and figure out how to do it on the Raspberry pi. I had an idea to replace the stereo in my car with a raspberry pi and a small touchscreen. Your GMU would work great for this. I miss using your player on my zipit z2. Maybe I will clean the dust off it and listen to some music with it.
I'm reading the README file and I see that there is a "hold state" in the program for GP2X, which is activated by "CLICK+SELECT" (per section 3.1).
Is there a HOLD STATE for Dingoo A320? It doesn't seem to be listed in section 3.2 of the README.
Does somebody know?
Frivolutionary, there is! The Dingoo A320 has this power switch which also acts as a hold switch. Gmu recognizes this switch so when you switch it in the hold position, Gmu locks itself until you put it back in the normal position. If you want to change any of the key mappings (including hold), that's also possible, but you have to edit a config file for the key mappings.
Hi Johannes, thanks for responding. I'm actually using GMU on a LDK handheld. I'm sure you didn't build GMU for this device but I think its design has evolved from Dingoo A320 and the version I'm using was probably ported from a version for Dingoo. It has 14 buttons (including D pad and shoulder buttons, etc) and an on/off switch. I think the switch of this device probably works differently because it only switches the power on and off so I think I will have to map a different key. I have never delved into development for linux devices so I'll consider myself a layman here. Can you tell me how to find a list of the available keys for my device (ie, which config file is it listed in) and how to assign the hold function to another button? Thank you!
Frivolutionary, there are two config files in your Gmu directory that are relevant to the button mapping dingux.keymap and gmuinput.dingux.conf. The gmuinput file maps the SDL keycodes to button names like "A" or "Start". Those names can then be used in the .keymap file to assign functions to those buttons. You should check out the Lock=... and Unlock=... lines in the .keymap file and assign them to a button available on your device.
Super excited about GMU. I too am using an LDK landscape. Apparently that is the in thing right now. I have been adjusting my button mapping and getting things to work like I want. I have also adjusted some of the obvious things in the conf file. To take it a step further, I was wondering if there is a guide somewhere to options for each conf file setting. So for instance, the LDK has a volume wheel. I noticed there was a setting in the conf file called: VolumeControl=Software I am assuming that I might be able to turn the application volume control off, leaving it on max and let the volume wheel and the hardware to control it, but I am not sure what the options are for this config option to change it. Let me know if there is anything. Thanks
the VolumeControl=Software setting is used to tell Gmu to use its software mixer to control the volume. This is useful for devices that do not have the capability to control the volume with a hardware circuit. This software/hardware distinction does not say anything about buttons or volume wheels, but rather if there is a hardware mixer present or not. If there isn't Gmu can scale the amplitude of the audio signal in software to control the volume.
In your case, you can set the software volume to its maximum value and just do not assign any keys for volume control since you have a volume wheel on your device. So you would set Gmu.Volume=100 and Gmu.VolumeControl=Software
If you then remove any key mappings for volume control you should be good to go. That way Gmu won't do any volume control on its own and you can use you volume wheel as usual.
This came insrtalled on my RetroGame 300, most of the interface is in chinese, is there any way to change it all to English?
Paul: That's interesting. The official Gmu releases are all in English, so they must have changed it for the RetroGame 300. Unfortunately, I don't know what exactly they have changed and if they have left a way to switch back to English. You could try to use the Dingux version from here. It could possibly work on your device.
The one installed has chinese lettering, ill give this a try, do i just drop the folders over the top of the one thats installed? or is there some way to install the program automatically.
The files in the FRONTEND folder are completely different in size from your version!
Paul: Yes, you pretty much just replace the files. In case it does not work properly, it is probably a good idea to make a backup of the existing files first.
Yea just tried it, it doesn't work unfortunately, oh well, thanks anyway.