Fix socket poll events values

[DaniElectra]

The write flags for poll events were wrong, 0x8 is used for POLLWRNORM / POLLOUT and 0x10 means POLLWRBAND. These values closely resemble the Wii sockets, though not all values are the same. The reverse engineered sysmodule shows that flags 0x4, 0x40 and 0x80 aren't returned in any code path, even though the sysmodule sets 0x40 and 0x80 along with 0x20 on the input events, which should mean error flags.

The values have been verified when reverse engineering the socket sysmodule, and has been tested with various applications:

• mbedtls
• curl
• Luma3DS (gdb stub)
• ftpd

[mtheall]

This doesn't work for POLLPRI
When data comes over OOB then 0x01 and 0x02 are triggered but not 0x4

This means it breaks ftpd's transfer cancellation mechanism

The wiki says:
POLLPRI: Urgent data can be read.
but I have verified that 0x2 is triggered (not 0x4) when the TCP message has the URGENT flag set

0x08 and 0x10 are both set when the socket is writable, so I will assume those are POLLWRNORM(POLLOUT) and POLLWRBAND respectively as you have written

I haven't been able to find any situation that triggers 0x04, 0x20, 0x40, or 0x80

If 0x80 truly is POLLNVAL then libctru should totally prevent that because of the newlib/ctru fd translation. If it's not a valid ctru socket descriptor then it will fail to translate and return ENODEVICE (the whole poll() fails)

[mtheall]

I think it would probably be acceptable if

#define POLLPRI (POLLRDBAND | 0x04)

[DaniElectra]

Upon further inspection I can't find any path in the code that can trigger 0x04, 0x40, or 0x80. POLLNVAL is also 0x20 indeed, that is my bad.

The write flags are probably right, since when flag 0x10 is set, flag 0x8 is always set too. And on UDP the only revents returned are either 0x1 (POLLIN) or 0x9 (POLLIN | POLLWRBAND)

Surprisingly, the module adds 0xE0 on the input event flags even though there doesn't seem to be a path to trigger 0x40 or 0x80