Linux input subsystem touchscreen support

[lentinj]

Hello,

I'm looking at using uGFX to an i.MX233 board. The MXS framebuffer works fine once I hack LLDCOLOR_BITS to include an extra dummy byte for an (unused) alpha channel.

The touchscreen is available via. /dev/input/event0, but I can't see any driver to use. This thread talks about an unfinished input subsystem driver, is there a complete version somewhere now, or is this something we'd have to develop?

[Joel Bodenmann]

Hello and welcome to the community!

Currently there is no official GINPUT driver for for the Linux (event) system in the repository. However, as you mentioned there is a working solution:

We never got to try it ourselves but we know of several people which claim that it works well just out of the box. If you could try that driver and leave us some feedback we can look into integrating it into the official repository fort he upcoming release of µGFX 2.7.

 

[lentinj]

You're right, copied the files into drivers/ginput/touch/LINUX_EVENT/ and boards/base/Linux-Framebuffer-Event respectively and was able to build and run the modules/gwin/widgets demo fine. Didn't need to modify any code. Shouldn't have heeded the not-complete warnings in that thread!

I think it'd be a very useful addition if you could include it.

[Joel Bodenmann]

Thank you very much for testing it. We are happy to hear that you were able to get it running without any problems at all.
We will include this in the official repository within the following days. Keep an eye on the blog to stay up to date about this.

[Joel Bodenmann]

3 hours ago, lentinj said:

The MXS framebuffer works fine once I hack LLDCOLOR_BITS to include an extra dummy byte for an (unused) alpha channel.

May I ask what hack you had to apply?

[lentinj]

mxsfb.c expects bits_per_pixel set to either 16 or 32 (i.e. RGBA, even though the "A" is completely ignored):

http://lxr.free-electrons.com/source/drivers/video/fbdev/mxsfb.c#L449

...but ugfx requests a video mode of 24 bits-per-pixel (i.e. RGB) when using GDISP_PIXELFORMAT_RGB888. I've not dug around enough to decide where the bug really is. However, one terrible bodge later:

Index: git/src/gdisp/gdisp_driver.h
===================================================================
--- git.orig/src/gdisp/gdisp_driver.h
+++ git/src/gdisp/gdisp_driver.h
@@ -820,7 +820,7 @@ typedef struct GDISPVMT {
 		#define LLDCOLOR_BITS_R			((GDISP_LLD_PIXELFORMAT>>8) & 0x0F)
 		#define LLDCOLOR_BITS_G			((GDISP_LLD_PIXELFORMAT>>4) & 0x0F)
 		#define LLDCOLOR_BITS_B			((GDISP_LLD_PIXELFORMAT>>0) & 0x0F)
-		#define LLDCOLOR_BITS			(LLDCOLOR_BITS_R + LLDCOLOR_BITS_G + LLDCOLOR_BITS_B)
+		#define LLDCOLOR_BITS			(LLDCOLOR_BITS_R + LLDCOLOR_BITS_G + LLDCOLOR_BITS_B + LLDCOLOR_BITS_B)
 
 		// From the number of bits determine COLOR_TYPE, COLOR_TYPE_BITS and masking
 		#if LLDCOLOR_BITS <= 8

...and I was on my way. uGFX seems to work fine, but this obviously isn't production-quality code

[Joel Bodenmann]

7 hours ago, lentinj said:

...but ugfx requests a video mode of 24 bits-per-pixel (i.e. RGB) when using GDISP_PIXELFORMAT_RGB888.

Thank you for bringing this to our attention. We will take a look into it and take the necessary measures to fix this problem.

In the meantime: We have cleaned-up and added the Linux event system touch/mouse input driver to the repository. Can you please pull the latest master and give it a try? You should be able to just use the new Linux-Framebuffer-Touch board file. It pulls the original Linux-Framebuffer files internally.

 

[Joel Bodenmann]

We fixed the issue with the color formats. You should be able to run an unmodified version of the latest µGFX library (master branch of the repository) on your system.
Thank you for bringing this to our attention.

 

[lentinj]

Excellent. I can now build and run modules/gwin/widgets without any modifications with GFXBOAD=Linux-Framebuffer-Touch 

Thanks for your help.