[Package request] MoltenGamepad 1.1.0

[oolongbrothers]

Hi again!

Since the version from 2016 that's in the libregeek repos, MoltenGamepad has seen some substantial development. They have passed a 1.0.0 release and are now at version 1.1.0 and it seems quite mature now, at least for WiiMotes.

Version 1.0.0 I built myself in an automated Vagrant VM environment and have used the binary daily for a month with a WiiMote on my Steam Machine without any issues. Also have I created a systemd service file to automatically run MoltenGamepad as a service on boot. (and a RetroArch autoconfig mapping for the MoltenGamepad WiiMote, but I guess I should try to upstream that with RetroArch).

Would updating MoltenGamepad be something you would be interested in? I don't know about your automation infrastructure for packaging, but if you want I could help out with build automation, if you tell me how you want this to work.

Cheers, //oolongbrothers

[mdeguzis]

My packaging methods generally involve clean chroots using pbuilder + hooks to insert apt sources and other extras during build time (if needed). As long as you don't need me to build off a fork, i'll snag the latest. Would you prefer the stable release? Or latest master tree code? The project still appears to be in quick development, so I figured i'd keep to date+commit master snapshots.

[mdeguzis]

Also, do you need the other plugins? I'll have to look into packaging those libs (wiimote is default, steam controller/joycon is extra).

[oolongbrothers]

Ah, great!

Well, I generally have a tendency for stable releases. However, your snapshot packagey ways seem to work out pretty well. Also, they seem to be doing there active development in a develop branch, so their master seems to be pretty clean. So yeah, I don't see a disadvantage in picking latest master.

About plugins: Right now I'm only using the built-in WiiMote stuff. I'm definitely interested in the Steam controller plugin, but not sure how complete it is right now. I could maybe build the plugin myself and test if out to see how much value it provides right now, before you need be taking on the extra effort right now.

Do you have some sort of flow where you promote packages from testing or something?

And are you running your chroot inside a Debian installation then?

Thanks for your effort!

On 14 May 2017 05:01:51 CEST, "Michael T. DeGuzis" notifications@github.com wrote:

Also, do you need the other plugins? I'll have to look into packaging those libs (wiimote is default, steam controller/joycon is extra).

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mdeguzis/SteamOS-Tools/issues/169#issuecomment-301287730

[mdeguzis]

Pbuilder handles the clean root. I used to migrate from testing to stable on a schedule, but life is busy. I now just keep what I deem new or unstable packages there for a bit. Git snapshots. I raised an issue with Moltengampad. I believe I can ignore them, but some Debian hardening rules are treating compile warnings as errors. I'll upload the latest release soon after.

[mdeguzis]

I built and synced scraw/scrawpp. When the build errors are resolved with Moltengamepad, I can enable the Steam Controller plugin support.

[mdeguzis]

I am just going to ignore the security warnings for now and put out a release for you to try. This new release will have all plugins (steam controller, wiimote, joycon) built into the binary. Building them as external plugins doesn't seem necessary, but i'm open to suggestions. Using the external method in the Makefile will require installing into /usr/lib most likely.

[oolongbrothers]

Cool. I'm just afraid the Steam controller plugin might interfere with Stream's controller handling in my use case were MG is running in background as a service all the time. But I will test that out once you have a build up. Would be best to have everything enabled if it just works. Were you interested in adding a systemd service file to the package? Would make it easier to run this thing with BPM. The service wouldn't need to be enabled by default either if we think it might break some use cases.

On 15 May 2017 03:40:36 CEST, "Michael T. DeGuzis" notifications@github.com wrote:

I am just going to ignore the security warnings for now and put out a release for you to try. This new release will have all plugins build into the binary, as well as all plugins loaded at run time. If you don't want plugins loaded at runtime, let me know.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mdeguzis/SteamOS-Tools/issues/169#issuecomment-301356683

[oolongbrothers]

In case you are interested: /usr/lib/systemd/system/moltengamepad.service:

[Unit]
Description=MoltenGamepad
After=network.target
After=bluetooth.target

[Service]
User=steam
Type=forking
ExecStart=/usr/local/lib/MoltenGamepad/moltengamepad --daemon --num-gamepads 1 --no-make-keys

[Install]
WantedBy=default.target

[mdeguzis]

I can add the service file no problem. In a system installed case, it would just be /usr/bin instead of /usr/local/bin. So it appears you are then ok with the plugins baked into the binary. Alright. The gamepad number should be some kind of argument to the call, or 4 services will be made.

Using an instance is probably the better route:

http://stackoverflow.com/a/30457399

Environment config files is possible, but seems to be a less desired solution:

https://superuser.com/a/728962

PLEASE NOTE

I am also removing the hyphen in the package name for consistency. I will make the new package remove the old. I'll avoid using dh-systemd to auto enable/start the service, so it can be installed manually. Doing so is just an install of the unit into /lib/systemd/system.

[oolongbrothers]

Yes, let's try it out with everything baked in and see if it causes any dismay.

I'm in support of the renaming :)

I agree that it's good to keep the systemd service optional. Do I understand you right that the package install would copy the moltengamepad.service file into /lib/systemd/system, that way the service should be available but not started or enabled on boot. The end user then can enable it using systemctl enable moltengamepad, creating the symlink in /etc/systemd/system/default.target/moltengamepad.service and thereby enabling it for start on boot.

Good point about the num-gamepads parameter setting. Instances seems to work from experimenting a bit with just now. Quite nice usability to, for example, being able to runsystemctl start moltengamepad@2.service to start with two virtual gamepads. My only concern was side-effects of accidentally having several processes running (f.ex. by starting a moltengamepad@2.service after already having started a moltengamepad@4.service). However, moltengamepad does not seem to mind that much if it has several instance running, the first instance grabs a device and makes it unavailable to any further ones. So in case of several instances running, there seems to be no input duplication. The only annoyance in that case seems be to have several redundant virtual gamepad device sticking around, which seems negligible to me.

So the unit file at /usr/lib/systemd/system/moltengamepad@.servicecould look something like this:

[Unit]
Description=MoltenGamepad with %I virtual gamepad(s)
After=network.target
After=bluetooth.target

[Service]
User=steam
Type=forking
ExecStart=/usr/lib/MoltenGamepad/moltengamepad --daemon --num-gamepads %I
Restart=always

[Install]
WantedBy=default.target

Note the lack of --no-make-keys, since emulating keyboard input is actually maybe something you would want to do, especially with the Steam controller.

By the way, I chose the singleuser permissions method, which seems to fit the SteamOS use case just fine. So I'm running this on installation:

installation/singleuser/configure.sh steam &&
installation/singleuser/install.sh

[oolongbrothers]

Maybe we would also want to set Environment="XDG_CONFIG_HOME=/etc/moltengamepad" if we want the configurations to reside there.

[mdeguzis]

I agree that it's good to keep the systemd service optional. Do I understand you right that the package install would copy the moltengamepad.service file into /lib/systemd/system, that way the service should be available but not started or enabled on boot

Correct

My only concern was side-effects of accidentally having several processes running(f.ex. by starting a moltengamepad@2.service after already having started a moltengamepad@4.service).

I'll look into disallowing multiple instances in that way. This could be accomplished by an ExecPre script that checks for a running instance.

By the way, I chose the singleuser permissions method, which seems to fit the SteamOS use case just fine

I will ensure the single user templates / files are pushed down as well as a postinst script in debian folder. Though, I don't see the harm with using the system method.

Maybe we would also want to set Environment="XDG_CONFIG_HOME=/etc/moltengamepad" if we want the configurations to reside there.

I assume this goes into the systemd unit file? I am fine with that.

[oolongbrothers]

Good stuff!

I'll look into disallowing multiple instances in that way. This could be accomplished by an ExecPre script that checks for a running instance.

That surely sounds like the smart way to do it. I was just fiddling around with the --pidfile parameter of moltengamepad, but that didn't do anything in the sense of preventing to start if a pidfile already existed. So it seems just like you say, us needing implement our own locking in a PreScript, maybe enough with just a pgrep.

I assume this goes into the systemd unit file? I am fine with that.

Yes, that goes into the service section. That way it picks up configuration files from /etc/moltengamepad, which I assume is user expected behaviour.

So the file would look like this:

[Unit]
Description=MoltenGamepad with %I virtual gamepad(s)
After=network.target
After=bluetooth.target

[Service]
User=steam
Type=forking
Environment="XDG_CONFIG_HOME=/etc/moltengamepad"
ExecStart=/usr/lib/MoltenGamepad/moltengamepad --daemon --num-gamepads %I
Restart=always

[Install]
WantedBy=default.target

[mdeguzis]

Continuing to work on this, but I wonder what is wrong with the behavior of the default systemd unit file? https://github.com/jgeumlek/MoltenGamepad/blob/master/installation/systemuser/systemd.service. Does it not pick up active controllers? Say you have two controllers on, and restart the service, how does it behave? Why do you need --gamepad? I don't see it in the main readme.

[oolongbrothers]

Oh, wow. I didn't even see that one!

It will create 4 virtual gamepads, but users could change that using a systemd override file, I think that's fine.

The user and group setting is specific to the systemuser case. I think we should only support one case (system user or single user) that works well with StreamOS and have a systemd file that fits with that. Everything else is too messy, I think. From reading about it, I am sceptic about system user mode. It seems to completely remove raw access permissions for game pads (all or supported ones?) from any other user. If it monopolies all gamepad access, it will completely turn off Stream's game pad mapping support. If it's only for the gamepads it supports, the question of Steam controller support becomes critical. As permissions will disallow switching between Steam and MG mapping support. I will try to test out system user mode with my WiiMotes tonight to see if it makes sense.

On 16 May 2017 04:12:05 CEST, "Michael T. DeGuzis" notifications@github.com wrote:

Continuing to work on this, but I wonder what is wrong with the behavior of the default systemd unit file? https://github.com/jgeumlek/MoltenGamepad/blob/master/installation/systemuser/systemd.service. Does it not pick up active controllers? Say you have two controllers on, and restart the service, how does it behave?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mdeguzis/SteamOS-Tools/issues/169#issuecomment-301655592

[mdeguzis]

Ok, yea if the "system" installation method is too much, I can use the user-mode with the original systemd unit file above

[Unit]
Description=MoltenGamepad with %I virtual gamepad(s)
After=network.target
After=bluetooth.target

[Service]
User=steam
Type=forking
Environment="XDG_CONFIG_HOME=/etc/moltengamepad"
ExecStart=/usr/bin/moltengamepad --daemon --num-gamepads %I
Restart=always

[Install]
WantedBy=default.target

[oolongbrothers]

Yeah, I checked out the udev rules from the system user scripts and they seem to assign exclusive permissions to all joysticks/gamepads to the gamepads user, factually disabling Steam's controller direct controller handling.

I think that this is probably not what people want when installing this on SteamOS. My guess is that the primary use case of MoltenGamepad on SteamOS is to simply add support for WiiMotes to Steam. And for that, I can say that the single user mode has worked flawlessly for me.

For the Steam controller MG plugin, system mode could have some advantages, when one wants to handle the mapping outside of Steam. But for now at least, I think I'd rather use Steam's built-in controller handling for all normal use cases (it's convenient!) and use MG's Steam controller support only for special cases where the normal Steam BPM controller handling does not work well or is unavailable. For that flexibility, the single user mode seems to lend itself better for.

But hey, maybe it's just a matter of setting up system user mode right and we will want to change it in future. But maybe we can try it like this first and see how it works.

[mdeguzis]

ok, i'll update the package tonight and you can report back to me how it handles. Updated package files will appear here in my packaging repo. There is no point in using the systemd service if using single user mode. Just start if via the command line. Check out the udev rules from single user mode as well. I won't include them right away.

If you are going to be starting moltengamepad.service anyway in some sense, manually, just fork it to the background:

<COMMAND> &

If you see a use case for the systemd service file still, let me know. There is probably a reason why upstream didn't include that in singleuser installations.

Edit: updated

brewmaster|main|amd64: moltengamepad 1.1.0+git+bsos-1
brewmaster|main|source: moltengamepad 1.1.0+git+bsos-1

[oolongbrothers]

Great, thanks! No hurry though, I'm out of town until Saturday. So I will only be able to test if out then anyway.

On 17 May 2017 03:10:42 CEST, "Michael T. DeGuzis" notifications@github.com wrote:

ok, i'll update the package tonight and you can report back to me how it handles. Updated package files will appear here in my packaging repo.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mdeguzis/SteamOS-Tools/issues/169#issuecomment-301957064

[oolongbrothers]

Hi, sorry for the long delay. I didn't manage with this in between two journeys abroad, so I only now had the chance to look at this.

Thank you very much for uploading the package. I tested it now and here are my comments:

• My WiiMote worked well with the newer package.
• Permissions were correctly set.
• With the Steam Controller support compiled in, it is impossible to continue using the Steam controller natively in Steam. Which is a no-go for me at least, since you lose the controller UI and per-game configuration support for the Steam controller. You could configure the Steam controller using the moltengamepad configuration files, this is flawed, however, since:
• Steam sees all moltengamepad controllers as the same type of controller. Which means that you can not have different mappings in Steam for MiiMotes and Steam controllers.

My conclusions:

• Since using moltengamepad with multiple controller types together with Steam is broken, we should maybe only support one controller type by default? It would be great to be able to switch what controller type to support on runtime (different MG binaries?), but if it's not relatively easy to achieve this, it's probably not worth it. Maybe the package should simply only ship with support for WiiMotes for now.

Cheers, oolongbrothers

[mdeguzis]

What I could do, is fall back to the default of not baking in the plugins, and provide them as loadable plugins you can issue yourself. What would you suggest? I'll look when I get home from work.

On May 31, 2017 9:48:25 AM EDT, Oolong Brothers notifications@github.com wrote:

Hi, sorry for the long delay. I didn't manage with this in between two journeys abroad, so I only now had the chance to look at this.

Thank you very much for uploading the package. I tested it now and here are my comments:

• My WiiMote worked well with the newer package.
• Permissions were correctly set.
• With the Steam Controller support compiled in, it is impossible to continue using the Steam controller natively in Steam. Which is a no-go for me at least, since you lose the controller UI and per-game configuration support for the Steam controller. You could configure the Steam controller using the moltengamepad configuration files, this is flawed, however, since:
• Steam sees all moltengamepad controllers as the same type of controller. Which means that you can not have different mappings in Steam for MiiMotes and Steam controllers.

My conclusions:

• Since using moltengamepad with multiple controller types together with Steam is broken, we should maybe only support one controller type by default? It would be great to be able to switch what controller type to support on runtime (different MG binaries?), but if it's not relatively easy to achieve this, it's probably not worth it. Maybe the package should simply only ship with support for WiiMotes for now.

Cheers, oolongbrothers

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/mdeguzis/SteamOS-Tools/issues/169#issuecomment-305191975

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[oolongbrothers]

The loadable plugin way would of course provide maximum flexibility to the user to utilise MG in just the way they want. So if it's not a big hassle that would be awesome.

[mdeguzis]

Ok, I'll load up a new version without them baked in. I'll distribute the plugins in /usr/lib/moltengamepad if I can.

[mdeguzis]

moltengamepad_1.1.0+git+bsos-1_amd64.deb updated

[mikeyd@archboxmtd build-moltengamepad-tmp]$ tree usr/
usr/
├── bin
│   └── moltengamepad
├── lib
│   └── moltengamepad
│       ├── example.so
│       ├── joycon.so
│       ├── steamcontroller.so
│       └── wiimote.so
└── share
    └── doc
        └── moltengamepad
            ├── changelog.Debian.amd64.gz
            ├── changelog.gz
            ├── copyright
            ├── LICENSE
            └── README.md.gz

[oolongbrothers]

Awesome, I think I'll have the chance to test this out tomorrow.

About the systemd service file: I'm undecided. On one hand it could be nice to include a sane default behaviour (WiiMote support) that people can then change. However, the possible use cases for MG are rather different. An alternative could be that I just write up some documentation about configuring MG via a systemd service for the SteamOS-Tools wiki. What do you think?

[mdeguzis]

Sure, sounds good. Just reference the files upstream and how you changed them if so.

[oolongbrothers]

I've been testing out your latest package today.

One thing I realised is that the paths of the permissions files are off: Read: actual path => desired path /etc/profile.d/sdl2-gamecontroller-moltengamepad.sh/profile-sdl2.sh => /etc/profile.d/sdl2-gamecontroller-moltengamepad.sh /etc/udev/rules.d/90-moltengamepad.rules/udev.rules => /etc/udev/rules.d/90-moltengamepad.rules

About the plugins. Upsteam says:

These plugins will need to be moved to a plugins folder inside MG's config directory in order to be found and loaded. (Plugins will only be loaded if MG is started with the --load-plugins option).

So to load plugins, I create a moltengamepad config folder at /etc/moltengamepad, link the /usr/lib/moltengamepad folder (or specific plugin libraries) to a plugins subfolder and run moltengamepad with the --load-plugins and --config-folder=/etc/moltengamepad. Once set up, that seems to work just fine. Maybe we should have some default configuration in place as part of the package to make it easier for the user to get started. Let me first test this out a bit more though, as to if this really is the best way to go. At least that way the user has full control as to what plugins they want to have loaded with MG.

Generally, I started to get some trouble now with how MG exposes the gamepads. Not sure yet what piece of the puzzle changed here. However, Steam now automatically sees them as devices that support its Steam controller-type per-game mapping (while all relevant Steam settings being disabled). This should generally be a good thing, but I've been having trouble getting the controller recognized in games and software like that. I'm looking more into this before a final verdict.

[oolongbrothers]

All right, back again. Sorry for being slow, please bear with me. I've had lot of trouble with controllers in SteamOS in the last weeks ...and the good weather outside did not help either, you don't get that too often here in Sweden :P

After a factory reset of my Alienware Steam Machine I can say: Both the latest SteamOS stable update and the Steam client's new controller handling have regressed from the near flawless behaviour I had before. I'm going to report upsteam the ones I can reasonably reproduce. Most importantly though: None of these problems seem to be caused by the MoltenGamepad package, since I have them even before installing it in the first place.

So I think once we solve the issues I mentioned in my last post, the package is golden :) At long last.

Plugin loading The method where I'm linking in the MG plugins into /etc/moltengamepad/plugins seems to work fine, is Linux-typical and I simply can't come up with anything better. Would you be interested in providing this in the package? I'd prefer linking the plugins individually, but linking the whole of /usr/lib/moltengamepad into /etc/moltengamepad/plugins would be fine too.

Permission files As described above. Should easy to fix?

Read: current installation path in package => desired installation path /etc/profile.d/sdl2-gamecontroller-moltengamepad.sh/profile-sdl2.sh => /etc/profile.d/sdl2-gamecontroller-moltengamepad.sh /etc/udev/rules.d/90-moltengamepad.rules/udev.rules => /etc/udev/rules.d/90-moltengamepad.rules

Service file I have one working with single user mode and dynamic plugin loading. You can either include it in the package or I just document it in the Wiki, your call.

There's light at the end of the tunnel here. I'm immensely thankful to you putting all this work in to help me out with this!

[mdeguzis]

The plugins are libs, (*.so), so they should be in /usr/lib. I push those to the lib dir, not etc. What requires /etc/moltengamepad? I will fix the permission files today, easy there. For the service file, I'd prefer to just document your findings and we can go from there.

You can add notes to:

https://github.com/mdeguzis/SteamOS-Tools/wiki/Moltengamepad

I will tidy up things if need be (table of contents, for one).

And sure, np! As long as people have patients with things, I usually am open to most requests.

On Wed, Jun 14, 2017 at 10:53 AM, Oolong Brothers notifications@github.com wrote:

All right, back again. Sorry for being slow, please bear with me. I've had lot of trouble with controllers in SteamOS in the last weeks ...and the good weather outside did not help either, you don't get that too often here in Sweden :P

After a factory reset of my Alienware Steam Machine I can say: Both the latest SteamOS stable update and the Steam client's new controller handling have regressed from the near flawless behaviour I had before. I'm going to report upsteam the ones I can reasonably reproduce. Most importantly though: None of these problems seem to be caused by the MoltenGamepad package, since I have them even before installing it in the first place.

So I think once we solve the two issues I mentioned in my last post, the package is golden :) At long last.

Plugin loading The method where I'm linking in the MG plugins into /etc/moltengamepad seems to work fine, is Linux-typical and I simply can't come up with anything better. Would you be interested in providing this in the package? I'd prefer linking the plugins individually, but linking the whole of /usr/lib/moltengamepad into /etc/moltengamepad/plugins would be fine too.

Permission files As described above. Easy to fix.

Read: current installation path in package => desired installation path /etc/profile.d/sdl2-gamecontroller-moltengamepad.sh/profile-sdl2.sh => /etc/profile.d/sdl2-gamecontroller-moltengamepad.sh /etc/udev/rules.d/90-moltengamepad.rules/udev.rules => /etc/udev/rules.d/90-moltengamepad.rules

Service file I have one working with single user mode and dynamic plugin loading. You can either include it in the package or I just document it in the Wiki, your call.

There's light at the end of the tunnel here. I'm immensely thankful to you putting all this work in to help me out with this!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mdeguzis/SteamOS-Tools/issues/169#issuecomment-308456746, or mute the thread https://github.com/notifications/unsubscribe-auth/ADv_DQAwOwf0ml4TdDccEmEpQMk_bMMmks5sD_PqgaJpZM4NaCuW .

-- Michael DeGuzis Email: mdeguzis@gmail.com Website: http://www.libregeek.org Linked In Resume/Profile http://www.linkedin.com/profile/view?id=124915388&trk=nav_responsive_tab_profile Projects: GitHub Projects https://github.com/mdeguzis

[oolongbrothers]

I agree about the plugins, MG seems to be a bit weird like that. Quote from their README (emphasis added by me):

Plugins can also be set to be built as external plugins. These plugins will need to be moved to a plugins folder inside MG's config directory in order to be found and loaded.

Setting the config path to /lib/moltengamepad does not make sense either (would also require to put plugins into plugins subfolder), since one will also put configuration files and profiles into the config folder, which in turn should not be in /usr/lib.

So the best workaround that I can come up with would be to have the plugins stay in /usr/lib/moltengamepad and link them into the configuration folder /etc/xdg/moltengamepad/plugins. So you "enable" plugins by linking them into the config folder. Kinda like how Apache module loading works. Anyone wants to write an mgenplug tool? ;P

One correction to what I said before: The config folder should be /etc/xdg/moltengamepad, mind the xdg there! This is the default config folder that MG falls back to if nothing is overridden (see https://github.com/jgeumlek/MoltenGamepad/blob/ad9cbbee7a708880399ade93eaaedd7a486a1ffe/source/core/moltengamepad.cpp#L67) That way we avoid needing to manually specify where MG should look for it's config and plugins.

No problem, after we end up with a "final" package, I'll cook up some nice documentation about how to run/configure MG incl. a systemd service section with references to upstream and everything :)

Yeah, no worries, no rush at all!

[oolongbrothers]

I laid some ground work for the Wiki page, barring how to actually run and configure MG.

[mdeguzis]

Great! Thanks. I'll update the package tonight with the above I mentioned.

On June 14, 2017 1:05:46 PM EDT, Oolong Brothers notifications@github.com wrote:

I laid some ground work for the Wiki page, barring how to actually run and configure MG.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/mdeguzis/SteamOS-Tools/issues/169#issuecomment-308495998

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[oolongbrothers]

Are you planning on adding the creation of an /etc/xdg/moltengamepad folder and the linking of plugin files form /usr/lib/moltengamepad into /etc/xdg/moltengamepad/plugins to the package? Or would you rather have it that the user does this?

[mdeguzis]

I don't mind linking /usr/lib/moltengamepad to the configuration folder, /etc/xdg/moltengamepad/plugins. /etc/ should always be for configuration files from all prior experience. Libraries always go in a lib folder. That is done with a simple definition in debian/links.

Beyond that, what else needs done? I am fixing the installation of the files you noted above.

# Read: current installation path in package => desired installation path

/etc/profile.d/sdl2-gamecontroller-moltengamepad.sh/profile-sdl2.sh => /etc/profile.d/sdl2-gamecontroller-moltengamepad.sh

/etc/udev/rules.d/90-moltengamepad.rules/udev.rules => /etc/udev/rules.d/90-moltengamepad.rules

[mdeguzis]

Package updated:

brewmaster|main|amd64: moltengamepad 1.1.0+git+bsos-3

[oolongbrothers]

Awesome, thanks. Tested it and it works great.

I added a How to run, How to configure and Known problems section to the Wiki page. Are you still missing anything there, anything I should improve?

[mdeguzis]

The documentation is well done, I don't see anything at the moment. I'll let this open for a week or so in case you discover any new things to tweak. If not, i'll continue to update the page when I remember :)

[oolongbrothers]

I do feel some level of ownership over the wiki page and the package now, so I'll also try to update the wiki page when I come across changes or new information. Let's see how it goes :stuck_out_tongue:

Thanks for all your effort! I think you can close this issue now :smile:

[mdeguzis]

Thanks and no!