It is rather confusing at this point.
The first step is getting the remote control signals from the remote control receiver. This is done by a Linux kernel driver. For many popular remotes, this was done by one of the out-of-tree LIRC
lirc_* drivers. In the case of your remote, it was done by the lirc_mceusb driver.
The second step is translating remote control signals into Linux input events (i.e. KEY_* and BTN_* input events). For the out-of-tree lirc_* drivers, this was done in user space using the lircd
daemon. For mapping the remote control signals to Linux input events, the lircd daemon relies on the /etc/lircd.conf file.
However, as part of including the lirc_* drivers in the kernel tree, translating remote control signals into Linux input events is being done in kernel space. This is the case for your remote, because it is using the mainline kernel mceusb driver now. These ported drivers convert the remote control signals to input event scan codes. These scan codes are then mapped to key codes. This scan code to key code mapping can be changed using the ir-keytable command, which is included in MiniMyth. However, I have not integrated into MiniMyth's init system yet, so using it to change mapping would be somewhat cumbersome at this point. Besides, it is not likely required because it is likely that all the scan codes are mapped to key codes, just not the ones that you want.
The third step is converting the Linux input event devices into an lircd socket. This could be done using the lircd daemon. However, for added flexibility in doing the conversion,I wrote the eventlircd
daemon, which is what MiniMyth uses. The eventlircd daemon is capable of mapping key codes to other key codes. This is integrated into the MiniMyth init system. MiniMyth stores the mapping files in /etc/eventlircd.d. The mapping files are named <BUS_ID>_<VENDOR_ID>_<DEVICE_ID>.evmap.
The fourth step is mapping the key codes sent through the lircd socket to application behaviors, this is configured using the /etc/lircrc configuration file. Therefore, /etc/lircrc is still used. Also, since /etc/lircrc files maps key codes to application behaviors, as long the remote button you want to map produces a key code.
Since irexec is just another application that listens for events on the lircd socket, is still works.
Because the lircd daemon is not longer used to translate remote control signals to Linux input events for your remote, your /etc/lircd.conf file will do nothing. However, as mentioned above, if all of your remote buttons map to some key code, then you can add the file /etc/eventlircd.d/03_2304_0225.evmap to do the mapping or you can change /etc/lircrc to do the mapping. To find out whether or not all your remote buttons map to some key code, stop X, run the command irw and press each remote button. If all the buttons produce a key code then create file called 03_2304_0225.evmap (you can find example files in /etc/eventlircd.d) with mappings that match the mappings in your /etc/lircd.conf file, put it your MiniMyth read-only configuration directory, and add MM_LIRC_EVENTLIRCD_FILE_EVMAP_ADD
='03_2304_0225.evmap' to your minimyth.conf file.
I will need to look into why resume from S3 is not working. What hardware do you have? If is VIA do you have MiniMyth stopping X before suspending?