Using device-tree to configure GPIO - basic questions

[procount]

Thanks for catching my stupid error on function ordering. Doh!

goodix_request_input_dev is clearly registering more input types than cypress_request_input_dev,

I'm being really stupid now - Where? because I can't see it. (I must be going blind!)
Yes, I agree it adds these 2 events;

Code: Select all

	input_set_abs_params(ts->input_dev, ABS_MT_WIDTH_MAJOR, 0, 255, 0, 0);
	input_set_abs_params(ts->input_dev, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0);

(I have no need for those, and even when I added them, it only added those 2 events)

It also adds:

Code: Select all

input_set_capability(ts->input_dev, EV_KEY, KEY_LEFTMETA);

But that's for a Windows Home key, that I'm not using.

Where is it adding, for example:

Code: Select all

 
     Event code 0 (ABS_X)
     Event code 1 (ABS_Y)
     Event code 47 (ABS_MT_SLOT)
     Event code 57 (ABS_MT_TRACKING_ID)

?

And is the fact that /dev/input/mouse0 does not exist a consequence of those missing capabilities?

[procount]

@PhilE - Many thanks . It was just the configuration ordering that was causing it.

Spoke too soon. I first have to test it with the correct touchscreen fitted.

[procount]

And with the correct touchscreen fitted, it works like a charm!
Many thanks @PhilE for being my extra pair of eyes!

[procount]

Just one more question if I may:
Is it acceptable to create a composite device driver that would initialise the LCD screen AND control the touchscreen, or is that considered bad form?

[PhilE]

Upstream (i.e. the Linux kernel maintainers) would probably want a driver for each, especially if they really are separately addressable bits of hardware.

[procount]

That sounds vague enough that it's ok if I want to use it for PINN, but to release it upstream a separate driver would be required.

Currently, the LCD screen and touchscreen driver are separate userland programs. I don't know how to detect the LCD screen on it's own, but I can detect the touchscreen and infer that the LCD screen is also fitted (since they're on the same PCB) and hence initialise it.
This makes it much easier to autodetect different screens and initialise them in one go (since the driver is only loaded when the H/W is detected), otherwise it means switching the userland programs around depending on which touchscreen is detected. I still have the issue of the user having to change the overlay and other settings in config.txt, but it's a little easier.