What’s the best way to get patches applied / stuff fixed ?
attached is a preliminary patch. It’s a little hackish, but it works so far.
I added a few FIXMEs to the code.
How to map touch coords to event coords if the window is not
fullscreen? Can’t test it here.
Support SDL’s touch interface - but I’m not even sure how to
interpret the float value (if it’s not fullscreen).
Use multiple SDL mice/devices/w/e for multiple EVDEVs.
Other thoughts: the current EVDEV code is broken by design, imho:
- The code should keep track of values and only act upon SYN,0
(possibly drop for SYN,3).
For a touch, the old code would result in:
- Mouse/finger down
- Mouse/finger move X (= drag right/left)
- Mouse/finger move Y (= drag up/down)
- Mouse/finger up
The correct behaviour would be:
- Store finger=1
- Store x=value
- Store y=value
- at SYN: Move to x,y and mouse/finger down (correct order is obvious)
- Store finger=0
- at SYN: Mouse/finger up
My hack just moves mouse/finger down to the end (SYN) and keeps the rest
Same goes for keyboards: events should be emitted or dropped at SYN.
EVDEV may send modifier+key in any order between 2 SYNs, SDL would act
incorrectly in 1 of 2 cases.
- Because of possibly too low buffer size, polling udev should be done
async, if timing can’t be guaranteed. For my app, this is done using
PumpEvents() at random code points, but I don’t really see why SDL
doesn’t pthread_start an “event worker”.
Andreas LauschOn 2015-09-29 22:18, Andreas Lausch / TBT wrote:
I have to move from SDL1.x to 2.0 because rapid keystrokes (e.g.
automatically generated ones) won’t work with 1.x branch for linux/Xorg.
Since the target is a raspberry pi (2), I can’t use X anymore with 2.0
branch, which means the events have to be fetched using evdev directly.
Problem is: the udev code only selects ID_INPUT_KEYBOARD and
ID_INPUT_MOUSE but neither ID_INPUT_TOUCHSCREEN nor ID_INPUT_KEY (so
touch events (ABS) from a keyboard would work but not from a touch
Where ID_INPUT_TOUCHSCREEN is obvious and ID_INPUT_KEY would be for
GPIOs mapped into userspace (e.g. gpio-keys module).
Is there any chance that the file’s author/maintainer might have time
to fix this?
Btw. is there any chance that the performance regression using X on
raspberry will be fixed? Rendering to a “texture” (uint32_t*) and
presenting it using the xorg driver results in 0.5 FPS. The very same
code rendering (directly) to an SDL_Surface and flipping it ran with
20FPS (SW Limit) at <10% Load for SDL1.2 when only flipping or >10FPS
(at ~100%) when completely redrawing it.
I’d love to use X, because the “box” will also run X anyway (for other
programs) and allowing to use a/the same Xorg.conf for both programs
would be nice.
Best regards and
thanks for the great project
SDL mailing list
SDL at lists.libsdl.org
-------------- next part --------------
A non-text attachment was scrubbed…
Size: 8211 bytes
Desc: not available