Clobbering of MT slots

[mapinguari]

As per discussion on #1437.

I have made changes to return an fd on device open and to pass the fd that generated the event as part of the lua table returned.

Having made these changes I think it probably is unnecessary to pass the fd with EVERY event as ultimately the main loop in waitForInput only returns a table of event tables for one device at a time, so could have waitForInput return a triple instead. hypothetically.

---

This change is 

[Frenzie]

nit, I think clang-format will take care of it by itself?

[Frenzie]

same nit

[Frenzie]

Double nit

[Frenzie]

lgtm besides the formatting nits (spaces for indentation, space after comma), but as I said, clang-format. ^_^

[mapinguari]

ugh sorry, stupid of me. Ok, those should be updated

[NiLuJe]

I'm gonna go with "Not good enough" for now, sorry. (This is just a quick veto to merging this as-is, until I have more than a shower's worth of time to think about it).

In decreasing order of importance:

• This breaks initial state handling (I alluded to this in the other thread). The only way I could think of to avoid that would be to:
• Pass the same info along during the openInputDevice code, so that front's init has it on init, so it can tweak the initial state appropriately.
• That would probably imply using the inputfds index instead of the fd number, because this would allow us to make sure initial state only applies only to the touch-screen (which is importanty on devices with wonky initial state, because they only have a single iunput device: the scree,).
• That would require making sure we always open the touchscreen device first, which should be easy enough, if that's not already the case (because otherwise, we'd need to do some kinds of cap checks on open to discriminate screen from pen, and that way lies madness, especially on older kernels).
• This should probably be using a small-ish seed value in addition to the fd number, because that may be low enough to be lower than the maximum touch points of the input device, which could still leave room for conflicts.
• I like the idea of passing the info along in w<aitForInput... as long is it doesn't make the frontend code that much more horrible ;).
• I'd like to see the matching frontend changes before merging this ;).

[NiLuJe]

I did it wrong, see above ;p.

(This is just to generate a big red cross to avoid drive-by merges).

[mapinguari]

Ok, points taken.

I will close this for the moment on my end.

[Frenzie]

Pass the same info along during the openInputDevice code, so that front's init has it on init, so it can tweak the initial state appropriately.

I thought that was implied by this PR btw.

[mapinguari]

I think my lack of clarity didn't aid this PR.

I was thinking that the fd would just be passed between the C and the lua so that frontend can deal with it as it sees appropriate. Not that the ABS_MT_SLOT values would be automatically converted to ABS_MT_SLOT + fd (this would obviously cause major differences with handling gestures and the inited state [not that I fully understand what they would be at this point :)]).

This confusion aside however I totally take that the lack of changes on the lua side makes this a bit futile at this point and adds a not insignificant amount to the size of the tables being sent back to lua. So I am happy for this to sit quietly until I have made some changes on the front that either make this PR worthwhile, or change the PR to reduce overhead and satisfy you guys and myself that it isn't going to cause some pernicious issues in the gesture detecting.