I’m writing a video driver for SDL2 which supports Linux framebuffer
access with tslib support. This feaure was removed in SDL2 but I think
it is very useful for embedded systems. Not all of these systems have
opengl. I know there is DirectFB but this is too complicated for a small
system and cross compiling is a libtool hell. I tried a cross
compilation and it was totally broken. So is there anyone out there who
needs the old tslib and framebuffer support in SDL2?
So is there anyone out there who needs the old tslib
I had a request a few months ago to restore fbcon support, but I hadn’t gotten around to it yet.
Most embedded things either offer fbcon, an X server (!), or some sort of EGL, so I think it’s worth adding.
What does tslib add over talking to /dev/fb directly?
–ryan.
2014-03-05 12:06 GMT-03:00 Ryan C. Gordon :
So is there anyone out there who needs the old tslib
I had a request a few months ago to restore fbcon support, but I hadn’t
gotten around to it yet.Most embedded things either offer fbcon, an X server (!), or some sort of
EGL, so I think it’s worth adding.What does tslib add over talking to /dev/fb directly?
–ryan.
FWIW, I haven’t tried this, but Mesa docs indicate that their EGL
implementation supports fbdev (http://www.mesa3d.org/egl.html ), so it may
be possible to get SDL/OpenGL* (software emulated) running on top of
EGL/fbdev with very minor changes to the Raspberry Pi backend (probably
just the native window handler passed to EGL needs to change)–
Gabriel.
So is there anyone out there who needs the old tslib
I had a request a few months ago to restore fbcon support, but I hadn’t gotten around to it yet.
The lack of fbcon support is the only reason I have not switched from SDL1.2 to SDL2.
Most embedded things either offer fbcon, an X server (!), or some sort of EGL, so I think it’s worth adding.
I use SDL1.2 on an embedded iMX35 ARM SoC board. SDL1.2 works great on this with just a BusyBox based
filesystem created by Buildroot. No X server or other heavyweight front end needed. I have also used
SDL1.2 on an EP9307 ARM SoC board with the same success.
What does tslib add over talking to /dev/fb directly?
Calibration of the touchscreen mainly.
I’m using a USB touchscreen LCD (800x480) with the iMX35. The raw touchscreen events are almost
unusable. If I remember correctly, the X and Y axis are swapped and one of them is inverted. Using
tslib you just need to run the calibration utility and everything then works perfectly.
Regards,
HartleyOn Wednesday, March 05, 2014 8:06 AM, Ryan C. Gordon wrote:
I’m using a USB touchscreen LCD (800x480) with the iMX35. The raw touchscreen events are almost
unusable. If I remember correctly, the X and Y axis are swapped and one of them is inverted. Using
tslib you just need to run the calibration utility and everything then works perfectly.
Tslib has a lot of Filters. I agree with that. Resistive touchpanels in noisy environments are unusable without filtering. Unfiltered raw touch coordinates have a lot of jitter. SDL2 is great but I think dropping framebuffer support was a wrong decision. Sometimes you get a chip with a gpu and a patched kernel to handle this gpu. This patch was made for a kernel version I can not use but the patch is very difficult to port. So the only option is to use the Linux framebuffer. I know its a very special case.
FWIW, I haven’t tried this, but Mesa docs indicate that their EGL
implementation supports fbdev (http://www.mesa3d.org/egl.html ), so it
may be possible to get SDL/OpenGL* (software emulated) running on top
of EGL/fbdev with very minor changes to the Raspberry Pi backend
(probably just the native window handler passed to EGL needs to change)
Thank you I’ll give it a try.